Draft: Android module which can generate apks

[sp1ritCS]

@jpakkane talked about wanting this some time ago. At the time I was very much against this, as the format google requires you to use is fundamentally incompatible with letting meson generate anything else but shared libraries. While this still holds true, I've come around to accepting that in certain cases (stuff like testsuites etc., that aren't going to be deployed anywhere) split-apks as generated by meson can actually be useful, as it allows not having to deal with gradle, which is a great benefit cause gradle is awful.

---

As building java 8 source/class targets has been deprecated in new JDKs, its possible to build with -source/-target 11 nowadays. This however also requires passing a system image to javac. While the SDK contains the assets necessary to create a fitting image, there are still several steps needed in order to create an image from them. As this a one-time thing I didn't want to do this per-target. Instead, the creation mechanism right now creates the necessary targets in meson-private/android{SDK}_image. This is almost certainly the wrong place for them, but I'm unsure where to put them.

I wonder if it wouldn't be a good idea to instead of only using this system image for the plain java files passed into generate_apk, but as part of the host_machine java compiler if the host_machine is android. In this case however, the target_sdk would probably have to be project-level option (like, c_std, etc.) instead of an argument to generate_apk.

Additionally, the image generation mechanism right now is CustomTarget slop, where there a bunch of CustomTargets, whose output edge is the single (relevant) input edge of the next CustomTarget. It might be beneficial to put all these in a single command - however that'd require passing multiple Programs into it and I'd rather avoid having to do like [--begin-javac-invoc, *tools.javac.exelist, '--end-javac-invoc', '--begin-jlink-invoc, tools.linking.jlink, '--end-jlink-invoc', ...]. Is there a better mechanism for passing Programs / Compiler exelists into scripts?

---

Other limitations right now are, that:

a) It doesn't support including native code. It fundamentally isn't a hard thing to add (just extend the merge target to not just include classes.dex in the zip, but also the libs intolib/<arm64-v8a,x86_64>) but I think if I just were to take the libs from the build dir naïvely, they'd still have their build-dir specific rpath attached, which would confuse the linker.

b) No dependency support. The only java dependencies which meson supports right now are other jar targets, which can be passed to link_with of another jar target (#348, #5709). This will have to be looked into, as pretty much all android applications at the very least depend on something from androidx.

[jpakkane]

It's not particularly clear from the documentation what this would be used for. It says that it should not be used for new things or native code. What is the main advantage of adding support for a bundle format that is not even supported by Google any more?

Is it really possible to not use Gradle? Because the last time I looked most of the things needed to get things runningc can even not be obtained without Gradle (or whatever the thing is that Gradle runs to do the download).

[sp1ritCS]

a bundle format that is not even supported by Google

It's not not supported by Google, it's just that if you want to do Play Publishing, Google has the infrastructure to generate to APK from the AAB for the particular device that is going to be downloading it (just libs for native architecture, only translations for device locale, correct assets for screen resultion, etc.)

it should not be used for new things or native code

The lack of being able to include native library is a limitation I'd like to address, it's a matter of figuring out how to get rid of the rpath that meson includes for libraries in the builddir but not once they are installed.

Not quite sure what you mean with "new things". I've only warned against using in in "production applications", due to the AAB issue. Being able to have meson generate APKs for non-production applications (where you have more control over the execution environment) however is highly useful, as any minute not having to deal with gradle is a minute well spent.

Can even not be obtained without Gradle (or whatever the thing is that Gradle runs to do the download)

I believe you should be able to obtain everything from sdkmanager (which works well outside of gradle too) and dependencies via maven.

[jpakkane]

t's a matter of figuring out how to get rid of the rpath that meson includes for libraries in the builddir but not once they are installed.

Sorry for the delay, but the only way to get this done is via meson install.