- Prerequisites
- Building
- Signing
- QA Release
- Production release
- Debug Logs
- Playstore
Prerequisites
Before creating any release artifacts, remember to tag the commit on Github for the codebase version that you'll use to create the release whether:
- Library (aar) or implementation (apk)
- Snapshot or Release version
This is helpful when one wants to revert back or check out the code base that created the specific release(s).
In the tag, add a bullet list summary of the main features/fixes introduced.
If it is a release (as opposed to snapshot), use the Github Draft Release feature. Check out https://help.github.com/en/articles/creating-releases
NB: It is not recommended to do that for the snapshot versions.
Building
In order to create a release APK, all libraries in the OpenSRP chain have to have been built in the release variant. That is, if your application depends on the opensrp-client-core library, the library has to be built in the release variant.
If your implementation uses the opensrp-client-immunization library, that has to be built in the release variant. The immunization library itself depends on opensrp-client-core library, so before building the immunization library variant in release, it has to reference the release variant of the opensrp-client-core library.
For the case of GIZ Malawi for example: The architecture looks like this. Each arrow can be read as "Depends on".
As one can see from above, the child health module depends on 4 libraries which have to be built in release variant before it is itself built in release variant. GIZ Malawi which is the implementation app then imports the release version of the child health module as well as release variants of the other modules requires.
Signing
A release APK must be signed. This is done by selecting the Create Signed APK option from within android studio when building the APK.
QA
OpenSRP general debug key is available but you can create your own if the app is for QA or demo purposes. Remember, if you intend to simulate an upgrade on the next release you will need to sign the APK with the same debug release key.
Production
On an actual production release however, you need to use the existing OpenSRP production/release key to publish the APK. One should always sign the production APK with the same release key.
Debug logs
In production, it is bad practice to have debug logs turned on. They may carry sensitive information that was being logged during development. To ensure that the release APK does not have debug logging, add this snippet to your proguard-rules file (proguard-rules.pro).
-assumenosideeffects class android.util.Log {
public static *** d(...);
}
This strips out debug logs but you can strip out other modes as well.Some information should never be logged using the modes if you don't intend to strip them. For more info, check out https://developer.android.com/reference/android/util/Log
Playstore
Some OpenSRP apps need to be deployed on the Google Playstore. Any such releases should follow the above steps before uploading go Google.
Currently OpenSRP uses the the old signing approach to manage keys however there are plans to shift to the newly recommended upload key + signed key approach described here https://developer.android.com/studio/publish/app-signing
Why build a release version for QA?
Sometimes the process of creating the release which includes shrinking, optimization and obfuscation produces unexpected side effects that may be easily caught in the QA process.
Why follow this release process for production APKs?
Unlike the debug variant, the release variant is highly optimized for size and performance. For more information on this and more checkout this link https://developer.android.com/studio/build/shrink-code.html
NB: For releases, OpenSRP is currently in the process of implementing a regular release schedule for the release variants of the libraries to be upload on maven.