Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make app F-Droid ready #212

Merged
merged 18 commits into from
Jan 2, 2021
Merged

Make app F-Droid ready #212

merged 18 commits into from
Jan 2, 2021

Conversation

Ch4t4r
Copy link
Contributor

@Ch4t4r Ch4t4r commented Jan 1, 2021

This PR aims to remove closed-source dependencies (or pre-compiled binaries from non-approved sources) to make this app ready for F-Droid.
I like to share my progress early as a PR to show progress and get feedback.

Right now this PR removes the play-services-core library from the assembled app and only includes it when an .apk file compiled from ./gradlew assemblePlayRelease is used. For other, non-play builds it uses the server for checking for updates. This way folks at F-Droid could compile without the proprietary library bundled.

Things left to do:

  • Compile & test app
    • Verify both updaters are called properly
  • Extract other dependencies
  • fix copyright header
  • refactor

@Ch4t4r Ch4t4r mentioned this pull request Jan 1, 2021
Copy link
Collaborator

@ignoramous ignoramous left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! :D

cc: @hussainmohd-a

checkForBlockListUpdate()
} else {
Log.i(LOG_TAG, "App update check not initiated")
}
}
}

fun checkForUpdate(userInitiation:Boolean = false) {
if (persistentState.downloadSource == Constants.DOWNLOAD_SOURCE_PLAY_STORE) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this stay? With this PR the G-Play update check is only done for apps installed from G-Play, other builds (F-Droid in the future, from website) won't even contain the dependency for it and always use the web updater.
Currently I left this check in here for users who use the G-Play version but did not download from G-Play.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this shared pref value or check anymore.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ch4t4r Hussain says, this check isn't required (we won't distribute PlayStore flavoured builds from anywhere else). But... PlayStore mirrors like ApkMirror and others might distribute that flavour... In which case, we would need to fallback on the web-updater, right, and not the PlayStore update checks? Or... How is this ideally supposed to work?

Today, RethinkDNS distributed from the website and PlayStore are signed with the same keys.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the mirrors in mind as well. You can't know whether the play services are present on those devices in advance -- you could test at runtime though and fallback to the web updater if they aren't.

Copy link
Collaborator

@ignoramous ignoramous Jan 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I guess we need to check for presence of Play Services too (which, if absent, would skip update-checks and show an error toast on Play flavoured builds):

https://github.com/googlesamples/google-services/blob/7cbe0486697a/android/gcm/app/src/main/java/gcm/play/android/samples/com/gcmquickstart/MainActivity.java#L103-L117

@Ch4t4r
Copy link
Contributor Author

Ch4t4r commented Jan 1, 2021

I couldn't find any other proprietary dependencies. I checked that it runs the web updater on fdroid-flavored builds (./gradlew installFdroidDebug) or play-flavored builds (./gradlew installPlayDebug) not actually installed from G-Play. On play-flavored builds installed from G-Play it calls the play service updater.

The web updater works as intended (checks in the background; shows dialog when up-to-date/check failed only when user clicked on check for app updates).
The gplay updater is called correctly but I could only verify the negative-case (no update availabe). You might want to test it using internal app sharing as described here.

@Ch4t4r
Copy link
Contributor Author

Ch4t4r commented Jan 1, 2021

I'm not sure whether the prebuilt tun2socks is okay. Open-source dependencies on a private binary repository would not be okay as only a handful of repos are approved for F-Droid apps. In this case the library is included in the git repo however, which might be fine? Anyone could verify the included binary in the git repo is compiled from the commit mentioned.

@Ch4t4r
Copy link
Contributor Author

Ch4t4r commented Jan 1, 2021

If a prebuilt tun2socks would not be okay a more complex config file would have to be created in the F-Droid RFP repo which first builts the library and then copies it over, using the prebuilt directive (something like here https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/chat.rocket.android.yml#L141)

@Ch4t4r Ch4t4r changed the title [WIP] Make app F-Droid ready Make app F-Droid ready Jan 1, 2021
@ignoramous
Copy link
Collaborator

ignoramous commented Jan 1, 2021

I'm not sure whether the prebuilt tun2socks is okay.

Apart from outline-go-tun2socks, isn't the guava lib embedded as a binary (jar) as well, which would also be a special-case as far as F-Droid builds are concerned? #198

We should ideally build outline-go-tun2socks with RethinkDNS. May be git submodules is worth a shot: github/working-with-submodules

@Ch4t4r
Copy link
Contributor Author

Ch4t4r commented Jan 1, 2021

I totally missed the guava dep. Is there any reason why it is not pulled from maven?

@ignoramous
Copy link
Collaborator

ignoramous commented Jan 1, 2021

I totally missed the guava dep. Is there any reason why it is not pulled from maven?

May be an artifact of Intra's early beginnings: Jigsaw-Code/Intra@c20b993

May be guava can simply be fetched from maven-central without fuss and both those jars in the app/lib folder can be rid.

Copy link
Collaborator

@ignoramous ignoramous left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, this PR is good to merge. Thanks for your time and effort, Daniel.

Note: Re: F-Droid, at least two more changes required:

  1. Fetch guava from maven central.
  2. Move outline-go-tun2socks in as a git submodule.

@Ch4t4r
Copy link
Contributor Author

Ch4t4r commented Jan 1, 2021

I removed the file dependency and added the maven one. App still compiles and country flags (that is what it is used for, right?) still show properly in query log.

@Ch4t4r
Copy link
Contributor Author

Ch4t4r commented Jan 1, 2021

2. Move `outline-go-tun2socks` in as a `git submodule`.

Would having a monorepo (subfolder/module for tun2socks) also be fine for you? That would be simpler and we could just depend on it using pure gradle (and wouldn't have to init/pull the submodule all the time).
I'm not sure whether Android projects can have non-Android modules though.

@hussainmohd-a
Copy link
Collaborator

Including guava along with firebase was having an known issue Duplicate class com.google.common.util.concurrent exception. That's the reason in Intra it was included as part of lib.
https://stackoverflow.com/questions/56639529/duplicate-class-com-google-common-util-concurrent-listenablefuture-found-in-modu

As we are not using any firebase dependency I think we can add as maven.

@ignoramous
Copy link
Collaborator

2. Move `outline-go-tun2socks` in as a `git submodule`.

Would having a monorepo (subfolder/module for tun2socks) also be fine for you? That would be simpler and we could just depend on it using pure gradle (and wouldn't have to init/pull the submodule all the time).
I'm not sure whether Android projects can have non-Android modules though.

We are going to include WireGuard in this project at some point, too: Prefer that it comes in as a git-module. I am mostly basing it off of on how Orchid handles external but critical (security sensitive) cross langauge deps: https://github.com/OrchidTechnologies/orchid/blob/master/.gitmodules

I take, your concern is that gradle process won't be straight-forward? That is, Android Studio build integration would be convoluted more than necessary?

Copy link
Collaborator

@hussainmohd-a hussainmohd-a left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good for me.

@ignoramous ignoramous merged commit 46da627 into celzero:master Jan 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants