Support API levels for SDK extensions and add missing targets for automotive and desktop.

[TimoPtr]

Fixes #429.

This action is missing some targets. I am currently working into using this action into https://github.com/home-assistant/android/ and I need the android-automotive target. I've added all the targets that I found missing.
I don't have the opportunity to test them on Github Action yet.

---

Added targets:

• android-automotive
• android-automotive-playstore
• android-desktop

Also added system-image-api-level to support specifying different api-levels for platform and system images as they aren't always aligned for sdk extensions.

Removed input validation on api-level so SDK extensions e.g. android-35-ext15 and preview API levels e.g. android-Baklava are supported.

[TimoPtr]

This PR fix this issue #429

[TimoPtr]

@ychescale9 Should I update the changelog too?

[ychescale9]

@TimoPtr Thanks for the contribution!

Is it possible to add the sdk extension in a separate PR or is it related to these new targets?

I'll take a closer look at your changes on the weekend.

[TimoPtr]

It can be two PR if you prefer. But for instance both changes are needed for the latest version of android-automotive to work.

[ychescale9]

In that case let's do both in this PR.

[TimoPtr]

Just found out that the platforms might not be the same ...
that is why the test fail platforms;android-34-ext9 fail but platforms;android-34-ext10 exist. Does it make sense to split sdk-extension in two? One for the platforms and a second one for the image?

[ychescale9]

Well that's annoying 😅 .

At this point I'm a bit tempted to give up on validating api-level and just let users provide any arbitrary strings. This means we don't need to make such assumption on the api-level naming convention - ${apiLevel}-ext${sdkExtension}, and users can start using preview version of the SDK e.g. android-Baklava without having to wait for us to update the allowlist ['Tiramisu', 'UpsideDownCake', 'VanillaIceCream', 'Baklava'] we maintain.

So the SDK platform we use would remain platforms;android-${api-level}.

We can then add an optional system-image-api-level which defaults to api-level if not provided, where you can override the api-level used for system-images.

E.g.

api-level: 35-ext14
system-image-api-level: 35-ext15
target: android-wear
arch: x86_64

Please let me know what you think.

[TimoPtr]

For sure that solve the issue and it easier when Google is going to introduce something new again.

[TimoPtr]

@ychescale9 I've made the modification

[ychescale9]

Obviously out of scope for this change, but a better way to validate the api-level, target, and arch is to download the XML files on the fly from these URLs and parse them to check whether the requested combination exists:

This would also save people a lot of time figuring out why the emulator doesn't run when they've requested for a system image that doesn't exist.

[ychescale9]

@TimoPtr I just checked the output of sdkmanager --list again and looks like the same -ext version for both platforms and system-images are now available?

[TimoPtr]

@TimoPtr I just checked the output of sdkmanager --list again and looks like the same -ext version for both platforms and system-images are now available?

That's weird on my side I don't have platforms;android-34-ext9 but I have -ext10, 11, 12 ... I think it's safer to let the user of the action pick the versions it wants. It seems that the versions are not released together.

[ychescale9]

@TimoPtr I just checked the output of sdkmanager --list again and looks like the same -ext version for both platforms and system-images are now available?

That's weird on my side I don't have platforms;android-34-ext9 but I have -ext10, 11, 12 ... I think it's safer to let the user of the action pick the versions it wants. It seems that the versions are not released together.

Yeah you're right, but at least the latest ext version is aligned now which definitely wasn't the cast last week.

[ychescale9]

Thanks again for your contribution!