This commit was built as a revert commit followed by deletion:
* Revert "androidenv: manually (!) delete oldest revision of google
images".
* Delete other revision.
Using `systemImageType = "google_apis_playstore"` (and `abiVersion =
"x86"` and `platformVersion = "28"` - that I expect resolved to
`97d9d4f4a2afa8b0f5d52e90748e19c10406ca93`), the symptom is:
```
Warning: Observed package id 'system-images;android-28;google_ndk_playstore;x86' in inconsistent location '/nix/store/...-androidsdk/libexec/android-sdk/system-images/android-28/google_apis_playstore/x86' (Expected '/nix/store/...-androidsdk/libexec/android-sdk/system-images/android-28/google_ndk_playstore/x86')
...
Error: Package path is not valid. Valid system image paths are:
system-images;android-28;google_ndk_playstore;x86
```
How is the actual image name `google_ndk_playstore` when the fetched
image has id `google_apis_playstore`?
Attempt keeping - of the two images - the one that looks simpler.
For the `"28".google_apis."x86"` images, in the XML the differences
are: more complex license (what is `arm-dbt`?); higher emulator.
Namely:
```
<uses-license ref="android-sdk-license"/>
<dependencies>
<dependency path="patcher;v4"/>
<dependency path="emulator">
<min-revision>
<major>27</major>
<minor>1</minor>
<micro>7</micro>
...
<uses-license ref="android-sdk-arm-dbt-license"/>
<dependencies>
<dependency path="patcher;v4"/>
<dependency path="emulator">
<min-revision>
<major>29</major>
<minor>1</minor>
<micro>12</micro>
```
Analogously for `"28".google_apis_playstore."x86"`.
Symptom:
```
Available Android targets:
----------
id: 1 or "android-28"
Name: Android 9
Type: Platform
API level: 28
Revision: 6
Skins: HVGA, QVGA, WQVGA400, WQVGA432, WSVGA, WVGA800 (default), WVGA854, WXGA720, WXGA800, WXGA800-7in
Tag/ABIs : google_ndk_playstore/x86
...
Error: Invalid --tag google_apis_playstore for the selected target.
```
For creation of AVD, switch from `android` to `avdmanager` as the
latter seems enabling selecting the image with less friction (and is
better documented as not deprecated). This requires using recent
tools - from https://developer.android.com/studio/releases/sdk-tools :
> SDK Tools, Revision 25.3.0 (March 2017)
> ...
> `android avd` command-line functionality replaced with new
> `avdmanager` tool.
For listing of targets, switch from `android` to `avdmanager` as the
`android` command invocation fails in recent tools. Symptom (not
missing `s` as backward incompatibility):
```
Invalid or unsupported command "list targets"
Supported commands are:
android list target
android list avd
android list device
android create avd
android move avd
android delete avd
android list sdk
android update sdk
```
References:
- https://developer.android.com/studio/tools/help/android
- https://developer.android.com/studio/command-line/avdmanager
Move to a known version of the emulator. Each OS has a distinct
version... pick the one on Linux. A better solution would be to let
the user of `emulateApp` overload what the emulator version shall be
(and maybe it is already possible and I do not see it) - without need
to reproduce large portions of `default.nix`.
Using the previous emulator showed the following warning:
```
Your emulator is out of date, please update by launching Android Studio:
```
I am not aware of any reasons for not wanting the latest emulator (as
I expect it shall be compatible usually with more system images - not
less), so bump its default version.
Emulator release notes:
https://developer.android.com/studio/releases/emulator
Updated with fixes for `convertsystemimages.xsl`:
- Use `type-details/codename` if it exists, falling back to
`type-details/api-level`: this results in "Q" rather than "28" for
preview images
- Use `<xsl:text>` elements to control whitespace in the output.
This is extracted from https://github.com/NixOS/nixpkgs PR 58131.
Update generate.sh to run using nix-shell. Also make it fail with
meaningful output instead of writing empty output files.
This is extracted from https://github.com/NixOS/nixpkgs PR 58131.
This relies on the shebang being used.
These derivations just unzip something and maybe do a little patching,
so there's no benefit to sending the zip file off to a build server and
then downloading the unzipped results again.
