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. A grant that points every entry at a single directory assumes somebody linked the whole SDK into one place. On a default install nothing is there, so every absolute-path entry misses — and because the tools are absent from the image anyway, nothing reveals the mismatch until a run needs 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.