Upcoming change to the Android build pipeline

#1

Android Application Bundles (AAB files)
We recently added support for Android Application Bundles (.aab files). This is the new and recommended way for app distribution on Google Play. AAB files can not be directly installed on an Android device and must before installation be converted into an APK file. This is handled automatically by Google Play. Using AAB files has several advantages:

  • Google Play optimizes the APK for the target device before installation. This usually results in a slightly smaller install for the end-user.
  • The maximum size of an AAB file is 150 MB, as opposed to 100 MB for an APK.

Android Package Kit (APK file)
For local development you still want to use APK files as those can be installed directly onto a device. Defold has up until now had its own build pipeline for APK files with a custom tool for signing the APK. The problem with the old pipeline is that APKs were signed using an old APK signature scheme. The old signature scheme is less secure and it prevents development of things such as Google Play Instant application.

Unified build pipeline
With the AAB signing in place in Defold we will migrate from our old custom build pipeline to solve the issue with the old signature scheme. Starting with Defold 1.2.173 we will generate APK files using the same build pipeline as we use for AAB files. When you build an APK using the editor or bob.jar we will first create an AAB file and from the AAB file generate a universal APK suitable for installation on any supported Android device.

What does this mean for you?
This change will have one implication for you as a developer when it comes to signing your applications. You will no longer be able to sign your applications using a certificate (.pem file) and key (.pk8 file). Signing applications must be done using a Java keystore file (*.jks file). This has been the standard way of signing Android applications for a long time and with this change to the Android build pipeline we finally have to adapt and start using keystore files.

You can convert your .pem and .pk8 file into a keystore file using a script, like this:

#!/usr/bin/env bash

KEY=$1		# .pk8
CERT=$2		# .pem
PASS=$3
ALIAS=$4

if [ -z ${KEY} ]; then echo "You must provide a pk8 key"; exit 1; fi
if [ -z ${CERT} ]; then echo "You must provide a pem certificate"; exit 1; fi
if [ -z ${PASS} ]; then echo "You must provide a keystore password"; exit 1; fi
if [ -z ${ALIAS} ]; then echo "You must provide a keystore alias"; exit 1; fi

KEYSTORE=generated.jks
rm -f ${KEYSTORE}

echo "Creating ${KEYSTORE}"

# convert binary key.pk8 to key.pem
openssl pkcs8 -inform DER -nocrypt -in ${KEY} -out key.pem

# bundle key and cert into a pkcs12 file
openssl pkcs12 -export -in ${CERT} -inkey key.pem -out cert.p12 -password pass:${PASS} -name ${ALIAS}

# import pkcs12 file into a keystore
keytool -importkeystore -deststorepass ${PASS} -destkeystore ${KEYSTORE} -srckeystore cert.p12 -srcstoretype PKCS12 -srcstorepass ${PASS}

# cleanup
rm key.pem
rm cert.p12

echo "Done!"

Example:

$ > convert.sh defold_key.pk8 defold_cert.pem MySeCrEtPaSsWoRd defold

This will create a keystore named generated.jks containing the provided key and certificate. The key and certificate will be associated with the alias defold and protected by the password MySeCrEtPaSsWoRd.

When you bundle your application in Defold using 1.2.173 (using editor or bob.jar) you need to provide the keystore (*.jks file) and a text file containing the the keystore password.

22 Likes

Defold 1.2.173 has been released
Defold 1.2.173 has been released
pinned globally #2
0 Likes

#3

It should be mentioned here that the editor (on Mac at least) allows you to select the exported .jks file but will display “Invalid keystore” and not allow a build. For it to work the file must be named *.keystore.

0 Likes

#4

This is a bug. Thank you for spotting it!

1 Like