... | ... | @@ -192,4 +192,33 @@ You can work around this by skipping the version code check. To do so, edit your |
|
|
novcheck: yes
|
|
|
```
|
|
|
|
|
|
This is generally discouraged (even more so in the actual build recipe on F-Droid) as it takes away a useful level of sanity checking. However, in some setups it is the easiest way to get a working F-Droid build when you cannot supply the correct version codes. |
|
|
\ No newline at end of file |
|
|
This is generally discouraged (even more so in the actual build recipe on F-Droid) as it takes away a useful level of sanity checking. However, in some setups it is the easiest way to get a working F-Droid build when you cannot supply the correct version codes.
|
|
|
|
|
|
## Signing artifacts
|
|
|
|
|
|
The above workflow will generate an unsigned release APK, which cannot be installed directly on an Android system, as Android requires APKs to be signed. However, you can sign the APK after F-Droid finishes, allowing it to be installed.
|
|
|
|
|
|
Although the APK is a release one, nothing prevents you from signing it with a debug key. On your local machine, a debug keystore is created automatically the first time you build and install a debug version of an Android app. The F-Droid CI setup does not do this for you, hence you will need to create the debug keystore manually. Also, you need to make sure your CI caches it between runs so each build is signed with the same key as the previous one.
|
|
|
|
|
|
The Android toolchain will create the debug keystore in `$HOME/.android/debug.keystore`. However, some CI environments restrict caching to certain directories (for example, GitLab CI will not cache anything outside the project directory), so you may need to adjust the path.
|
|
|
|
|
|
If you use a debug keystore for other CI workflows as well, you may want to ensure they all use the same path. If needed, simply modify the path to `debug.keystore` to whatever you are already using in your CI environment.
|
|
|
|
|
|
You need to test if a keystore is already present and create one if necessary. Then you need to sign the APK generated by F-Droid. Signing is done in place (i.e. modifying the APK), which may not always be desirable – if necessary, simply create a copy and sign that.
|
|
|
|
|
|
Add the following commands to your CI script to do all of that (create a keystore in your project dir if needed, create a copy of the unsigned APK and sign it):
|
|
|
|
|
|
```
|
|
|
# create a keystore if we don’t have one
|
|
|
ls .android || mkdir .android
|
|
|
ls .android/debug.keystore || keytool -genkey -v -keystore .android/debug.keystore -storepass android -alias androiddebugkey -keypass android -keyalg RSA -keysize 2048 -validity 10000 -dname "C=US, O=Android, CN=Android Debug"
|
|
|
# sign the apk
|
|
|
cp -R unsigned signed
|
|
|
jarsigner -verbose -keystore .android/debug.keystore -storepass android -keypass android signed/*.apk androiddebugkey
|
|
|
```
|
|
|
|
|
|
Then, ensure `.android` is cached between sessions (on GitLab CI, you would just need to add `.android` to your cache paths).
|
|
|
|
|
|
Run CI twice and watch the output: both runs should generate a signed APK; a fresh keystore should get generated during the first run but not during the second.
|
|
|
|
|
|
In theory, the same procedure would work for a release signature as well. However, you would need to find a way for the CI workflow to securely access your release keystore, and modify commands to use the correct keystore. |
|
|
\ No newline at end of file |