targets/android/build-binary : hook to call external script for signing

[ghost]

Hi,

I have a little script for signing android apks which I would prefer to use instead of the method in build-binary. Mostly for paranoia reasons - I am afraid that whatever I enter in PROFILE ( or anywhere within the git tree) could become public by some accident. Hence I use a script in ~/bin which has access to all the secrets.. would you mind adding a hook for this?

[mgorges]

There are few ways to achieve what you'd like to do. The easiest for your specific use case might be this:

Add a line with OVERLAY_PATH=/home/jdoe/satellite_fw to your SETUP file. This folder is, where the android keystore file and the PROFILE file are located. Then you can than do the typical configure and make pieces as usual because the make.sh find these for you. This is partially described in Satelite-Framework in the Wiki. Note that you can have more than one overlay, so you could have one location for only the keystore and PROFILE, with another holding your code, which works as long as the directory structure is maintained.

Another alternative is to use the method as described in System-wide-installation, which I personally use. The second repository is where I host the personal apps, modules, SETUP and PROFILE file. For me, this is another git repository but it doesn't have to be.

Only if both of these don't work for you, you could locally patch your build-binary to call some other piece to sign your apps. However, I wouldn't want to include this in the framework, given that two working alternatives exist.

[ghost]

thanks for your suggestions, I can make good use both.

I still have to call my install/test script after building it so it would be very helpfull if the build-binary script would return the name of the built package (signed or not) so I can use it directly as input to this script.

Another alternative is to use the method as described in System-wide-installation, which I personally use. The second repository is where I host the personal apps, modules, SETUP and PROFILE file. For me, this is another git repository but it doesn't have to be.

Looking at the wiki page, the start is a bit sketchy. I assume I should create something like /usr/lib/lambdanative, compile the stuff there and then copy the customised lambdanative script to /usr/bin ?

I assume it would work very similarly if I copy the lambdanative script to ~/bin ?

[mgorges]

For the system-wide installation, it doesn't have to be anywhere specific, so the title is maybe a bit of a misnomer. It was designed for cases where LambdaNative was shipped with a Linux distribution, and you only have read-only access to its folder, and thus each user needed a separate place for their apps/modules and SETUP/PROFILE files that they can write to.

I actually have them sitting in two parallel folders (~/Documents/Programming/parts for the private stuff and ~/Documents/Programming/lambdanative for the build environment). I configure and compile in the parts one which pulls in the required pieces from the lambdanative one. The scripts/lambdanative sets up the configure and makescripts in your personal folder in a way they simply work out of the box.

[mgorges]

As for your other comment - post building automated testing would be something that makes sense to add. There is a bit of such infrastructure in existence already (make smoke, I believe builds every app in the repository, runs them and see which ones crash) but this certainly can be expanded.

Finally, the make script already displays the name of the final packages file built at the end, so we should also be able to simply return it. - However, testing if this falls through the respective pieces will need to be done.

[ghost]

in PROFILE.template the android.keystore should be mentioned, also the fact that "$SYS_ORGTLD.$SYS_ORGSLD" is used as keyalias and storepass must be same as keypass.

[mgorges]

Added in fbcd674. If you'd like to suggest a modification for that, please submit a pull request.