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.