Dependence on proprietary components

Issue #53 resolved
Igor Almeida
created an issue

Hello,

I'm a happy Car Report user for quite a while now, and I see the project has come a long way. Because the F-Droid version of your app can no longer include the latest functionalities, I'd like to give it a try and remove the functionalities that depend on proprietary components.

I believe it all started at commit 8d46a9553, so my intention would be to track these down up to current master and see what could be removed. If you could provide me some tips on what actually depends on proprietary parts, things could go a lot smoother.

Thanks for the awesome app!

Comments (20)

  1. Igor Almeida reporter

    ... turns out I did not have to do much. Restoring the backup from a version so far away from master was actually the harder part.

    Anyway, I have a patch and could probably write some instructions for other users. Given you may not want to remove the Drive Sync functionality altogether, would you be willing to provide a separate branch so F-Droid could pick it up in its automated builds?

  2. Jan Kühle repo owner

    Hi Igor, first of all I really would like to support F-Droid user. I just didn't have the time to solve the issue. I see two different solutions here: 1. Use different flavors of the app. I like this idea much more because then the free version of Car Report would receive the same updates as the proprietary. 2. Use just another branch for the free version.

    If you would like to build a flavor for the free version this would be awesome. But I can totally understand, when you don't want to invest so much of your time. That's why I'm also fine of just having another branch for the free version.

    What do I need to do exactly to get this working?

  3. Igor Almeida reporter

    Jan, thanks for the response. Here's what I had to do to get it running on my phone: https://bitbucket.org/igoralmeida/car-report/branch/playfree_imported You could probably just cherry-pick commit cadd38c since the other one seems to be Android Studio doing sneaky stuff.

    Like I said, the difficult part was actually migrating my data. I had to rename and manually edit carreport_export_refueling.csv (or something) to match what the new version expects. Since I never had a complicated database, it wasn't as difficult as it could be.

    So, going forward, I think we could setup a second gradle buildType and use some extra variables to enable/disable compilation of GoogleDriveSyncProvider (and related variables). This would be the best scenario in my opinion, since you could keep it all in one branch.

    The idea of a second branch is fine with me as well, but I lack enough android skills to fix the most hairy compilation scenarios, so I'd have to rely on your vigilance to make sure things are working the way you intend them to work.

    So, if I had only one thing to ask of you right now, it would be to think of a migration scenario between 2.9.1 (the current F-Droid version) and 3.6.2. I got some sqlite exceptions while trying this since the fields and tables were no longer the same. This would allow a seamless update for F-Droid users once the repository picks up a new version :)

  4. Jan Kühle repo owner

    Thanks for finding the correct commit. I will have a short look at flavors and think again what solution makes the most sense here. And of course I will have a look at the update path from 2.9.1 to the latest version.

  5. Jan Kühle repo owner

    Hi Igor, I created a build flavor in the branch "foss-flavor", in which I removed all code parts you mentioned in your commit. This was really easy. Now I just need to inform F-Droid somehow to pick this flavor for its builds. If you have any idea here please let me know.

  6. Jan Kühle repo owner

    Update: I just removed Dropbox *.jar file and added the source code as a separate module instead. I guess tomorrow I will play with the F-Droid metadata file. I'll give an update again, when this works.

  7. Jan Kühle repo owner

    Hi Igor, actually I need to do a little more to get this working on F-Droid:

    1. I need to get rid of the ChartLib.jar file. For this my plan is to migrate to the HelloCharts library, which is on maven and looks very promising. I don't want to spend more time to put ChartLib (my own chart library, which has its flaws) on a maven repository.
    2. I need to fix F-Droids gradle flavor implementation. F-Droid has a "usual suspects" check, which checks for often used proprietary libraries like the google play services. This check does not take flavor specific dependencies into account. So, although Car Report only includes the play services in the "full" flavor, it does not build with F-Droid.

    I will try to do both things on the weekend. But I don't know if I will have enough time to finish both.

  8. Igor Almeida reporter

    Jan,

    I can confirm things are working. Of course, I had to comment out the fullCompile lines to make gradle happy, but other than that nothing blew up in my face.

    I tried taking a look at the Chartlib/HelloCharts migration, but that quickly went way beyond my skills! So maybe I can help testing the 2.9.1 -> 3.6.2 update functionality, since you've committed some code for that already. I should be able to install a parallel 2.9.1 version, import the data from the f-droid installation and then update to 3.6.2 to see if any errors show up. Let me know if you want something specific tested there.

  9. Jan Kühle repo owner

    Hi Igor, don't worry, changing the chart library can wait. I think we can except the pull request for the gradle support in F-Droid to be merged soon.

  10. Jan Kühle repo owner

    Ok, some updates:

    1. The merge request for gradle flavor support in F-Droid has been merged.
    2. I submitted a merge request now for the Car Report metadata (here).
    3. I added build instructions to the README file.

    @Micha_Btz Is this enough for you? Actually I don't know if anything else is needed other then running gradle.

  11. Igor Almeida reporter

    If you don't have the proprietary libraries, 'gradle assembleFossRelease' will fail. You can, however, just delete the fullCompile lines in app/build.gradle before trying assemble*:

    diff --git a/app/build.gradle b/app/build.gradle
    index 1bdac6a..982203a 100644
    --- a/app/build.gradle
    +++ b/app/build.gradle
    @@ -50,20 +50,6 @@ dependencies {
         compile 'com.android.support:recyclerview-v7:22.2.1'
         compile 'com.android.support:design:22.2.1'
    
    -    // Play Services: for Google Drive
    -    fullCompile 'com.google.android.gms:play-services-plus:7.5.0'
    -    fullCompile 'com.google.android.gms:play-services-drive:7.5.0'
    -
    -    // The new Android Drive API, which is included in the play services, has caching bugs and does
    -    // not provide all functionality. Until this is fixed we have to use the old Google API.
    -    fullCompile 'com.google.apis:google-api-services-drive:v2-rev105-1.17.0-rc'
    -    fullCompile('com.google.api-client:google-api-client-android:1.17.0-rc') {
    -        exclude group: 'com.google.android.google-play-services'
    -    }
    -    fullCompile('com.google.http-client:google-http-client-gson:1.17.0-rc') {
    -        exclude module: 'httpclient'
    -    }
    -
         // WebDAV
         compile 'org.apache.jackrabbit:jackrabbit-webdav:2.10.1'
    

    Here, that generates app/build/outputs/apk/app-foss-release-unsigned.apk, which you can then sign (see https://developer.android.com/tools/publishing/app-signing.html for options).

  12. Jan Kühle repo owner

    What do you mean with "if you don't have the proprietary libraries"? Does gradle try to download the play service libraries even though it does not use them for compiling? That is shit. Then I guess the only option is really to delete the fullCompile lines before building. I will add this to the README later.

  13. Igor Almeida reporter

    Yes. I tried to find a way to make gradle ignore dependencies from specific flavors, but either it doesn't exist or I don't know the right search words for it.

  14. Jan Kühle repo owner

    Another update: the merge request for the F-Droid metadata has been merged. As far as I know this means within the next 24 hours the new version should be available in the F-Droid repo.

  15. Igor Almeida reporter

    Tried to install a parallel 2.9.1 version, but after a few errors playing with AndroidManifest.xml I realized it would require me to refactor the entire codebase. With gradle it's so much easier :/

    Guess I'll just wait for the F-Droid build and test there.

  16. Log in to comment