Support FDroid "in-APK" configuration bundle
Presently the Kerplapp bootstrapping process is (roughly) as follows:
- Transfer FDroid client APK from Alice (bootstrapper) to Bob (bootstrapee)
- Have Bob add Alice's Kerplapp repo to their newly installed FDroid client)
In order to reduce this process to 1 step (transferring & installing the FDroid client) we need a way to bundle repo configuration data into the APK that is sent.
It turns out we can inject resources into the META-INF directory of a signed APK without breaking the signature validity or the APK installation process. This Feature has two sides. On the kerplapp sid we need to have the Kerplapp client insert a prop file into the META-INF of the FDroid apk that is used to bootstrap clients. This prop file should contain the connection info & fingerprint for ALL of the repositories that the sending device has information for. There should be a prop setting to indicate which the "default" repo/category is to display. This default should be set to the connection info/fingerprint for the Kerplapp repo in order to display apps from this repo when bootstrapping completes.
On the FDroid client side we will need to write a patch that on app installation checks to see if there is a configuration bundle in the app's own APK's META-INF directory. If the bundle exists we need to load/parse it and add the corresponding information to the FDroid SQLite database. After performing a repo update the 'default' category/repo from the prop bundle should be displayed.
This mechanism will also allow FDroid to easily support "branded" FDroid experiences. By having FDroid repo's include a bootstrapping page with a download link to an FDroid client that has a pre-configured prop bundle for that repo a new user can download FDroid and immediately be viewing the apps from the repo they are interested in. Existing FDroid users can add the repo from the bootstrap page using a QR code or the fdroidrepo(s) URI link.
#2 Updated by pd0x almost 4 years ago
Possible downside to this technique: harder to tell the hash of the authoritative F-droid. Inserting a file into the APK doesn't break the signature but it does change the zip index/contents. We could remove the file again in the F-Droid patch for reading in the prop file but it still wouldn't restore the zip to the identical original hash because timestamps in the zip index have changed. You could theoretically patch those too but that's a great deal of hackery.
Ultimately I think that it isn't a tremendous downside to have new FDroid APK hashes. The sending F-Droid/Kerplapp repo can tell the client the hash to expect and the signature can be used to verify the source of the signed APK contents.
#3 Updated by daithib8 almost 4 years ago
This is laudable, but how far would you intend customisation to go: as far as icons, app names, action bar colors, about screens? These things are needed too and both AOSP and Gradle build systems are quite capable of it.
In any case, other stationary repos should always include a version of the F-Droid client so that users of just than one repo can be kept up-to-date. Of course it doesn't need to include repo configuration as that is always retained by the client between updates.
#5 Updated by hans over 3 years ago
#6 Updated by hans over 3 years ago
The ever helpful Tom Ritter provided some ideas for approaches to this. One is try to put relevant info in the file name, if possible. Here are some other examples: