BetterBatteryStats on Fdroid / Gradle based build

[Bubu]

I wanted to bring back BetterBatteryStats back to Fdroid as there is currently only a seriously out of date version available.

I struggled with the current ant based build system and was not able to successfully build BBS that way.
However I was able to convert the build to using gradle without too much effort.

Now integrating this into the Fdroid's automated build system poses a few challenges and I'd like to ask your opinion on how to proceed.

1. I can provide grade build files which you can merge additionally to the current system. This would have to be done for both BetterBatteryStats and AndroidCommon.
2. You switch to gradle altogether. I don't know how disruptive that would be for you, but gradle is clearly the more modern and more advanced build system. I can provide a pull request for this too.
3. I work from a personal fork on github where I can adapt the project structure myself. Fdroid builds from that fork but I would have to manually merge every update back into that fork.

I think all three solutions (but probably mostly 1. and 2.) improve how easy it is for people to not only look at the source but download and build it themselves and maybe sent back improvements to you.

[asksven]

Please not that while the source code is open source the artwork and the name are not.
Regarding porting bbs to android studio: this is something that I plan to do but I currently lack time. Did the process - including libs - go straight forward or did it require some major stunts / refactoring?

[Bubu]

No major hiccups. No code refactoring required. You can either restructure your repository to conform to the gradle standards. Or you can leave it as it is and have the non default setup in your build.gradle.

The AndroidManifest.xml needs minor adjustments because of a stricter merging process.
As for the libraries: AndroidCommon and LocalePluginLib need exactly the same treatment. All other libraries can just be included from jcenter/maven with gradle. (Excluding RootTools but you can just keep the .jar file you already have.)

Should I open a PR so you can take a look at the new structure?

[Bubu]

Regarding fdroid and licenses: Would you be interested in making this app available on fdroid besides the xda-forum and google play?
I think fdroid is a better alternative to manually distributing apks:
There are update notifications and it's easy to verify that the distributed app corresponds to the available source code. Both are important security aspects.

Regarding the artwork license, I think you are talking about the icon and three widget previews or did I miss anything?
It is not a hard requirement that these are under a free license (see F-Droid inclusion policy) as long as you allow the distribution with your app.

[asksven]

I did a quick conversion to android studio yesterday. I don't really like the structure created by the wizard and may rebuild the project from scratch one day.
Right I am stuck at one point that you may help me with:
during conversion AndroidCommon is copied into the project as a module and that is a no-go as I don't want to have multiple copies of a lib other projects depend on. What I need is a reference to an external project so I migrated AndroidCommon first, migrated bbs second, removed the module and the dependencies and added the dependency to the external project back in. So far so good but now I am confronted with obscure gradle errors on AS 2.0B3 and Google is of no help. Does your project setup handle this or did you stick with the module with a copy of AndroidCommon?

[Bubu]

I added AndroidCommon as a git submodule. I don't know if you can tell gradle to look outside the project root. But symlinks definitely work

Otherwise what gradle errors are you getting? I had to do something special with/ because of the jackson dependency.

On 12 February 2016 17:43:50 CET, asksven notifications@github.com wrote:

I did a quick conversion to android studio yesterday. I don't really
like the structure created by the wizard and may rebuild the project
from scratch one day.
Right I am stuck at one point that you may help me with:
during conversion AndroidCommon is copied into the project as a module
and that is a no-go as I don't want to have multiple copies of a lib
other projects depend on. What I need is a reference to an external
project so I migrated AndroidCommon first, migrated bbs second, removed
the module and the dependencies and added the dependency to the
external project back in. So far so good but now I am confronted with
obscure gradle errors on AS 2.0B3 and Google is of no help. Does your
project setup handle this or did you stick with the module with a copy
of AndroidCommon?

---

Reply to this email directly or view it on GitHub:
#761 (comment)

[asksven]

build.gradle
dependencies {
compile project(':androidCommon')

settings.gradle
include ':androidCommon'
project(':androidCommon').projectDir = new File(settingsDir, '../AndroidCommon')

error:
cannot evaluate module androidCommon: configuration with name 'default' not found

[Bubu]

Seems like he can't find the build.gradle file from AndroidCommon.
I found that: http://stackoverflow.com/a/19303545/1634837
The Syntax used there is a bit different.

[Bubu]

Any progress?
Btw. you haven't commented on the FDroid situation? Can you share your thoughts on that?

[jagguli]

Is this going on fdroid? Correct me if I'm mistaken but google play is a binary repo, where as fdroid builds from repo source?

[Perflyst]

Any updates?

[dimqua]

No? :-/

[ildar]

please reopen. This is important.

[licaon-kter]

I am sorry but I am not the maintainer of the F-Droid entry and this entry was added without my consent.

It's true that F-Droid goes the extra mile and asks for the developer to consent even if the license permits it, yes.
Not sure how BBS was treated back in 2013 when included though.

If you want to stay current on BBS development I recommend google play of XDA since I maintain these sources

As said before since there are no Tags it's hard for F-Droid to detect new versions, else it would be up to date. Eg. we are manually updating it for the last 10 years already, like I just did: https://gitlab.com/fdroid/fdroiddata/-/commit/676958e15273f438790ad6f6672c0a0c29b3b336

I have moved to branches instead of tags a while ago

Looks like that got obsolete too in the meantime.

Anyway, what would it take for you @asksven to consent with the inclusion? (no, we can't pickup APKs from XDA 😄)

[asksven]

It would take a few things: 1. I do not appreciate that the google play entry was copied 1:1 to F-Droid, driving all the support effort to me without me having any visibility into the result built and served by f-droid: what keys has it signed with, how is the supply chain guaranteed (you may have noticed that my commits are signed with GPG, what about the integrity of the end-product? Who is the person for me to contact if there are issues addressed to me and where the build-process is at fault? 2. We need an agreement about the use of the brand and the icon: these are excluded from the apache license and so not open source Don’t get me wrong: I want to support open source and this is the whole reason why I chose the license. On the other hand I need to find a way to make it worth the while: I was able to do that with a dual distribution (free on xdc, paid on g-play) for the last 10 years, and I just want to be in control of the chain, or at least visibility into it: - what signature makes sure that the supply chain can prove integrity of my code: if you put my name in there I need that to agree - releases published:what do we need to agree upon to ensure a hand-over that has traceability: I am happy to tag if you provide me visibility into the build process and chain to release Another idea: I’d be happy to publish to f-droid instead of the current indirect and obscure (to me) way of handling: want APIs do you provide for me to take-over the whole f-droid store story including supply chain? That would include you handing over the keys used for singing to avoid breaking the experience of any user having to un-install Any thoughts. Also happy to setup a call if mail going-pong is not suitable. Cheers Sven

…

On 29. Jun 2023, at 12:39, Licaon_Kter ***@***.***> wrote: I am sorry but I am not the maintainer of the F-Droid entry and this entry was added without my consent. It's true that F-Droid goes the extra mile and asks for the developer to consent even if the license permits it, yes. Not sure how BBS was treated back in 2013 when included though. If you want to stay current on BBS development I recommend google play of XDA since I maintain these sources As said before <#859> since there are no Tags it's hard for F-Droid to detect new versions, else it would be up to date. Eg. we are manually updating it for the last 10 years already, like I just did: https://gitlab.com/fdroid/fdroiddata/-/commit/676958e15273f438790ad6f6672c0a0c29b3b336 I have moved to branches instead of tags a while ago Looks like that got obsolete too in the meantime. Anyway, what would it take for you @asksven <https://github.com/asksven> to consent with the inclusion? (no, we can't pickup APKs from XDA 😄) — Reply to this email directly, view it on GitHub <#761 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGZUX4W7JP3B4H6SLYRUFTXNVLNVANCNFSM4B2WGYVQ>. You are receiving this because you were mentioned.

[licaon-kter]

I do not appreciate that the google play entry was copied 1:1 to F-Droid

You mean description? I guess it was copied to have it as correct as possible, it's way behind now.

what keys has it signed with

Now it is signed with F-Droid's one.

Is the app build reproducible? If yes, we might be able to switch it to your keys, but that means you'll need to host the APKs (eg. here https://github.com/asksven/BetterBatteryStats/tags or elsewhere)

how is the supply chain guaranteed (you may have noticed that my commits are signed with GPG, what about the integrity of the end-product?

@eighthave ping and https://gitlab.com/fdroid/wiki/-/wikis/FAQ#how-exactly-does-the-building-process-work

Who is the person for me to contact if there are issues addressed to me and where the build-process is at fault?

https://gitlab.com/fdroid/fdroiddata/-/issues/

We need an agreement about the use of the brand and the icon: these are excluded from the apache license and so not open source

We can flag them as "NonFreeAssets", but indeed F-Droid might need your explicit agreement. Else someone would need to fork the app and replace them.

what do we need to agree upon to ensure a hand-over that has traceability: I am happy to tag if you provide me visibility into the build process and chain to release

Not sure what you want to see, that's not in https://gitlab.com/fdroid/fdroiddata/-/commits/master?ref_type=heads and https://monitor.f-droid.org/builds already

I’d be happy to publish to f-droid instead of the current indirect and obscure (to me) way of handling

No, F-Droid needs to build it itself, but as said above if the app is build reproducible then F-Droid just verifies it and serves your signed APK.

...avoid breaking the experience of any user having to un-install

On a signer switch there's no upgrade path without the user un/re/installing :(

[eighthave]

Is the app build reproducible <https://f-droid.org/docs/Reproducible_Builds>? If yes, we might be able to switch it to your keys, but that means you'll need to host the APKs (eg. here https://github.com/asksven/BetterBatteryStats/tags <https://github.com/asksven/BetterBatteryStats/tags> or elsewhere) how is the supply chain guaranteed (you may have noticed that my commits are signed with GPG, what about the integrity of the end-product? @eighthave <https://github.com/eighthave> ping and https://gitlab.com/fdroid/wiki/-/wikis/FAQ#how-exactly-does-the-building-process-work <https://gitlab.com/fdroid/wiki/-/wikis/FAQ#how-exactly-does-the-building-process-work>

Right now, new releases are verified by git commit ID fetched via HTTPS: https://gitlab.com/fdroid/fdroiddata/-/blob/373517aceaa9f63dce1d99dd7d43ad5a88bebbfd/metadata/com.asksven.betterbatterystats.yml#L198 There is a prototype of verifying by GPG-signed commits and tags: https://gitlab.com/fdroid/fdroidserver/-/merge_requests/989 We welcome contributions there.