From @motorro on Thu Oct 13 2016 08:12:07 GMT-0400 (EDT)
As an android programmer I’m eager to get support for multiple apk builds in Android workflow.
Say I have a multi-variant application or a platform apk split and want them signed and deployed. Let’s take the latter case for example.
When build is performed I have a set of apk (one per platform):
The problem is only the single file is put to variable $BITRISE_APK_PATH (log abstract):
Move apk files...
find "." "-name" "*.apk" "!" "-name" "*-unaligned.apk"
copy ./app/build/outputs/apk/app-x86-release-unsigned.apk to /bitrise/deploy/app-x86-release-unsigned.apk
copy ./app/build/outputs/apk/app-mips-release-unsigned.apk to /bitrise/deploy/app-mips-release-unsigned.apk
copy ./app/build/outputs/apk/app-x86_64-release-unsigned.apk to /bitrise/deploy/app-x86_64-release-unsigned.apk
copy ./app/build/outputs/apk/app-mips64-release-unsigned.apk to /bitrise/deploy/app-mips64-release-unsigned.apk
copy ./app/build/outputs/apk/app-arm64-v8a-release.apk to /bitrise/deploy/app-arm64-v8a-release-unsigned.apk
copy ./app/build/outputs/apk/app-armeabi-v7a-release-unsigned.apk to /bitrise/deploy/app-armeabi-v7a-release-unsigned.apk
copy ./app/build/outputs/apk/app-armeabi-release-unsigned.apk to /bitrise/deploy/app-armeabi-release-unsigned.apk
The apk path is now available in the Environment Variable: $BITRISE_APK_PATH (value: /bitrise/deploy/app-armeabi-release-unsignedapk)
The signing step also uses the single file as an input.
It will be great if some export var from build step could contain just an output directory and signing (and may be other steps) use this dir to iterate apk-files rather than use a single one.
From @viktorbenei on Sun Dec 11 2016 03:58:33 GMT-0500 (EST)
Great idea, we’re just not sure how this should be handled. We already discussed a couple of options, and we’ll definitely try to find “the best solution”.
For now it seems the best would be to use the list of values format, which would work in your case - when you have to perform the same operation on all of the files - but we’re still evaluating this idea, e.g. what happens if you include both signed and unsigned, or debug and release APKs in the list.
Tools can be changed of course, so we might decide to go with this solution and tweak / change all the related steps accordingly, but we have to be sure and explore all possibilities, as these changes take quite some time to implement throughout all the steps.
From @motorro on Tue Dec 13 2016 03:08:20 GMT-0500 (EST)
> For now it seems the best would be to use the list of values format, which would work in your case - when you have to perform the same operation on all of the files - but we’re still evaluating this idea, e.g. what happens if you include both signed and unsigned, or debug and release APKs in the list.
IMHO that seems to be the thing the customer is responsible for as (and you’re telling the same here) you cannot predict the exact build scenario. Like I want both release and debug builds within the single gradle step for storing both artifacts later. Thus I put two tasks to execute in a single gradle step which generates two apk with only one of them to be signed. Imagine I have a per-platform split for release apk then which gives numOfPlatforms + 1 outputs. What I’m saying is you probably won’t produce the right list yourself. So IMHO the already present output filter in a build step APK file exclude filter is enough and those which pass it should go to $BITRISE_APK_LIST.
Then the signing step is the one that is responsible for signing only those that are appropriate - like having a $BITRISE_APK_LIST filtered, signing only those who pass, and adding signed to the original list.
And it is up to customer to properly setup that filter…
From @viktorbenei on Tue Dec 13 2016 09:19:01 GMT-0500 (EST)
> What I’m saying is you probably won’t produce the right list yourself
I completely agree, and I believe @godrei thinks the same - we already added this to our task list, and will update the Gradle and related steps to support the multi APK outputs & inputs.
Thanks for reporting and for your feedback, it helped a lot!
