Please add it to F-Droid

[ale5000-git]

Could you please add it to F-Droid?

F-Droid require that everything is compiled from sources and no pre-compiled binary is used.

[stevesoltys]

The main reason I haven't considered this is because I'm not aware of any way that the user can install F-Droid applications as system apps.

Do you know of any way to bundle system apps with whitelisted permissions / services in F-Droid?

[ale5000-git]

See one example: F-Droid Privileged Extension

It has 2 separate packages:

• The normal app to update it when it is alread installed: https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/
• The OTA package for the first installation: https://f-droid.org/en/packages/org.fdroid.fdroid.privileged.ota/

In the OTA zip you can probably place the whitelist files.

[stevesoltys]

Ah, I see. Alright, I will look into doing this when I get some time.

[stevesoltys]

I think the first goal would be to have Travis build and sign OTA zips like Yalp Store does during releases.

I've opened #9 to track that task.

[ale5000-git]

Look at my script to compress and sign an OTA zip: https://github.com/micro5k/microg-unofficial-installer/blob/master/build.sh
It use zipsigner (in java for all OS) to sign the zip that you can found here: https://github.com/micro5k/microg-unofficial-installer/tree/master/tools

You can run a shell script in Travis to automatize.

[beerisgood]

Any updates?

[stevesoltys]

@beerisgood lots of features are being planned since the CalyxOS team is contributing significantly: https://gitlab.com/calyxos/calyxos/issues/21

I'll be holding off on this until we're ready for the next release.

[grote]

Unfortunately, it looks like a backup app not only needs the system-only backup permission, but also needs to access hidden APIs. Google has been cracking down on their usage and the only way I have found to still use them is to sign the backup application with the platform private key.

This means that simply flashing a backup app on the system partition won't work unless you have access to the private platform key used by your ROM. So making this available in F-Droid (at least for Android Pie and later) would be pointless.

[ildar]

Does that true also for older Android releases? like 4.x and 5? maybe 6 and 7? If not that still makes lot of sense for older Android users.

[grote]

The app needs at least API version 26 and accessing the hidden APIs might still work up to API 27, but I am personally only targeting API 28 during development.

[ildar]

minSDK → Android 8.0? Oops, signing out.

[stevesoltys]

This app focuses on building against the latest API version and since this would only be possible for 26 and 27, I don't see a good enough reason to pursue it. The next breaking change upstream would also mean no updates for these users.

Closing for the above reasons.

[ale5000-git]

@stevesoltys: You could have different builds with different min sdk versions, F-Droid allow it.

[thestinger]

That means continuing to develop, maintain and test it for old API versions and part of the idea behind the project is focusing on providing a robust and secure alternative to traditional backup mechanisms which largely implies running an up-to-date OS.

[ildar]

is focusing on providing a robust and secure alternative to traditional backup mechanisms which largely implies running an up-to-date OS.

Sorry i don't catch the way of conclusion: How the former implies the latter?

…

[thestinger]

Each major OS version receives 3 years of security updates, so 2 years after the next major release of the OS it isn't supported anymore and it's required to have moved over already.

In each major version, there are substantial privacy and security improvements. It has been drastically improving in these areas and that will continue. If you're using an older version, you have far less privacy and security at the OS level.

Similarly, in practice, devices are only supported with full security updates for a couple years. Once that stops, there is no way to feasibly provide them. It doesn't matter if people keep backporting the latest AOSP security patches or even major OS versions. Those aren't full security updates without updates to the firmware and device-specific code (kernel drivers, userspace drivers / services / libraries and so on) and migrating to newer supported LTS branches of the kernel.

In general, since this project is aiming to do things right with a focus on privacy/security, it doesn't fit with using an old version of the OS.

[thestinger]

Also, as I mentioned and @stevesoltys implied, continuing to support older API versions requires dedicating development, testing and debugging time to it. It will complicate the code and hold it back on newer versions by taking away resources from them along with the ability to modernize the code and approach. You can see this kind of damage impacting many other apps. The further back they try to support, the worse they are on an up-to-date version of the OS due to the resources spent on this and the baggage that comes with it holding back development.

People being stuck on older versions of the OS is a major problem. It's not a problem that this app is in a position to address and I don't think it makes much sense to go out of the way to support something so inherently problematic when the whole point of providing a robust, secure, modern and minimalist approach to this. It has a major incentive to quickly move over to new APIs offering better approaches even when it isn't immediately forced to do it. Achieving the goals this app has aren't easy. It's still not at a v1 release suitable for production release and trying to support old OS versions would just hold it back from getting there and moving on from there.

[ildar]

Sorry i don't catch the way of conclusion: How the former implies the latter?

Yes, guys, thanks a lot for detailed answers. I just found that I got wrong the initial statement. Sorry, English isn't my first language.

…

[IzzySoft]

the only way I have found to still use them is to sign the backup application with the platform private key.

Wouldn't that make it a candidate for inclusion/integration with the microG builds of LOS? Anything planned along that road? Updates then could ship via the microG F-Droid repo as well maybe.

[grote]

AFAIK LineageOS is currently looking into adding it, so microG builds of LOS would get it automatically.

[grote]

Also note that we re-opened #9 which could get added to F-Droid, if one wanted to.

[IzzySoft]

AFAIK LineageOS is currently looking into adding it, so microG builds of LOS would get it automatically.

Oh, that's excellent news, thanks! And yes, having updates even if LOS stops support for a device (I have one that started out with official support and now that's gone) would not really hurt…

[grote]

having updates even if LOS stops support for a device (I have one that started out with official support and now that's gone) would not really hurt…

Somebody would just have to step up to package those OTA zip packages. I can do #58, but #9 and this ticket would have to be done by someone else.

[chirayudesai]

F-Droid isn't really the place to host OTA zips, and while it is used for the privext ota zip it isn't ideal and doesn't work on newer versions anyways due to data being encrypted.

Since this still needs to be a system app platform key or not, it may be signed by different keys depending on who bundles it, and we shouldn't put this into the main F-Droid repo as that wouldn't really be useful for anyone. What key would that app even be signed with?

[seniorm0ment]

What about selfhosting a fdroid repo?

[breversa]

AFAIK LineageOS is currently looking into adding it, so microG builds of LOS would get it automatically.

Confirmed : https://lineageos.org/Changelog-25/ :-)