Android images: a JDK, not an SDK
The android class image carries a JDK and no Android SDK, why that will not change, and the permission class written against a default SDK install.
For whoever writes a permission class for Android work.
After reading it you can say what the android image can and cannot run, and grant the Android tools at the paths a default install actually uses.
The image carries a JDK and no Android SDK
⚠ sdkmanager, adb, gradle and kotlinc are not in the android class image, and there is no
SDK directory in it. Its contents are the same as the Java class: a JDK, plus the class label.
⛔ This is not going to change. Android Studio and the Android SDK may not be redistributed — their licence terms are yours to accept, not ours to accept on your behalf.
The consequence to know before you write a permission class
A class that allows the Android build tools will allow commands this image cannot run. The permission is granted and the binary is absent, so the failure arrives at run time as a missing tool rather than as a refusal you can read.
⇒ Either install the SDK into your own layer on top of the image, or write the class against what the image actually carries.
The grant we can get right: a default install
The SDK is yours to install. The permission class that matches a default install is ours to get right, and the paths below are the ones a default install actually produces:
| tool | where a default install puts it |
|---|---|
adb, fastboot | the SDK's platform-tools/ |
sdkmanager, avdmanager | the SDK's cmdline-tools/latest/bin/ |
aapt2, d8, apksigner, zipalign | the SDK's build-tools/<version>/ — versioned, so a grant must glob it |
emulator | the SDK's emulator/ |
java, javac, keytool, jar | /usr/bin/ — already in the image |
gradle | your project's own wrapper, or wherever you installed one |
kotlinc | wherever you installed it — it is not part of the SDK |
⛔ A grant copied from elsewhere is worth checking against that table. An earlier one pointed almost every entry at a single directory, which assumed somebody had linked the whole SDK into one place. On a default install nothing is there, so every absolute-path entry missed — and the tools were absent from the image anyway, so nothing revealed the mismatch until a run needed one.
⇒ Install the SDK into your own layer on any class image — the android class already has the JDK — and grant the tools at the paths above.
Adding a vendor CLI to an image
Four ready build files, the three properties they all share, and what each CLI does behind a proxy — because two of the four ignore the variable most people reach for first.
Datastores
What the product stores, what it brings with it, and the two stores you supply when you outgrow the default.