Add android_generate_apk_from_aab action

[rynaardb]

What does it do?

Adds a new android_generate_apk_from_aab action to generate an APK from a given AAB.

This action can be useful in cases where you already have an AAB and just need the APK from it without having to build the APK from the source.

Checklist before requesting a review

• Run bundle exec rubocop to test for code style violations and recommendations
• Add Unit Tests (aka specs/*_spec.rb) if applicable
• Run bundle exec rspec to run the whole test suite and ensure all your tests pass
• Make sure you added an entry in the CHANGELOG.md file to describe your changes under the approprioate existing ### subsection of the existing ## Trunk section.

[AliSoftware]

Your implementation is not resilient to paths with spaces and special characters, and spawns a shell interpreter for little benefit, instead of using sh('bundletool', 'arg1', 'arg2') pre-parsed syntax.

Besides, your logic with mv can lead to unwanted destructive action if the caller passes a path to a destination folder instead of a path to the APK.

I've suggested an alternate implementation below. If you adopt it, you'll have to adjust your unit tests accordingly too; I'd suggest you to add some more unit tests as well, to validate various combinations of parameters (like if the user is passing the keystore_path but not the other keystore parameters, or if we provide paths with spaces or $ characters in them, test error handling, etc)

Left some other suggestions to improve the code here and there, feel free to review them.

[AliSoftware]

Now that we decided to not create intermediate folders if they don't exist, we should add a check to ensure the parent dir exists. Otherwise we'd still have the action run bundletool but only fail afterwards while trying to move the file to the destination, instead of failing early.

Suggested change

	),
	verify_block: proc { |p| UI.user_error!('The parent folder for the destination does not exist. Please create it first.') unless p.nil? || File.directory?(File.dirname(p)) }
	),

[AliSoftware]

@rynaardb GitHub doesn't let me add you as reviewer for the PR (likely because you're the PR author and GitHub doesn't allow authors to review and approve their own PRs, I guess), but feel free to review my latest changes addressing what we discussed.

As discussed in Slack, I've ended up taking over Rynaard and fixing the issues raised above myself, so the changes I requested are now all addressed (but just dismissing my review instead of approving the PR, because it doesn't seem fair to self-approve my own changes)

[rynaardb]

@AliSoftware looks good. Once you approve the PR, I'll get it merged, or feel free also to do it.

[rynaardb]

@AliSoftware I've marked the PR as Do Not Merge since there seems to be an issue with the logic that checks whether bundletool is installed. See this build for an example. It only happens on our Android CI build agents, with bundletool obviously installed. The behavior seems to be different when testing locally, as it works as expected. So I'll need a bit more time to investigate why that is and to ensure we haven't missed anything.

[AliSoftware]

Good catch.

Idea (not checked): could the reason for the failure be that bundletool is installed… but not in the $PATH of those agents, and thus not found by command -v bundletool? 🤔

[rynaardb]

Good catch.

Idea (not checked): could the reason for the failure be that bundletool is installed… but not in the $PATH of those agents, and thus not found by command -v bundletool? 🤔

So here's the thing, it does actually finds the path when you run command -v bundletool:

root@buildkite-android-builder-66998c988b-4hnfl:/# command -v bundletool
/usr/local/bin/bundletool

But for some reason, the check reports something else. I've already spent a good amount of time looking at the build agents to ensure we haven't misconfigured something. And so far as I can tell, everything looks fine to me.

[AliSoftware]

Mmmmh… confusing 🤔

Trying to think of something but the only think I could think of would be if the shell context could be different when running command -v bundletool directly in your Terminal vs via fastlane and its sh method?

• Like the Terminal uses one shell (say, bash) and fastlane uses another (say, sh)?
• Or like the code that adds adds bundletool to the PATH is in the wrong RC file (e.g. .bashrc vs .bash_profile) which would explain why it's loaded when in an interactive terminal session but not when invoked directly?

One way of checking that this is due to different context could be to create a dummy lane that runs sh('command -v bundletool') and see if the result differs from when you invoke it in the Terminal. Especially maybe the error you get (and that our code rescue here) is something other than "executable not found" in practice, and not rescuing it in your lane test to let it crash and print will give you more insights as to what might be wrong?

---

Note: the fact that when I used a similar logic to test the presence of bundletool in #365, and that this sh('command', '-v', 'bundletool') call from my fastlane action worked when I tested it in wordpress-mobile/WordPress-Android#16580 (although that was back when we were still using CircleCI, not Buildkite, but still)… makes me think that the reason it doesn't work here is most likely related to something we missed in the agent's setup/config (rather than something wrong in the ruby code logic, since the same logic worked on another runner back then)? 🤔
The big question is what that missing agent configuration is of course… but at least that might help narrowing down the ideas to test? 🤞