Android sys img picker#2843
Conversation
|
The approach was revised during the PyCon sprint after a discussion with @mhsmith. |
… and no system image.
…rmed versions in list_available_system_images
…e across platforms
|
Are the 3 CI failures pre-existing or am I goofing something here?
I checked recent CI runs on main and found some of these issues crop up there. |
|
Yes, the failures aren't related to this PR, so you don't need to worry about them. Thanks for the updates, I'll look at this in a couple of days. |
| system_image = self.DEFAULT_SYSTEM_IMAGE | ||
| # Get available images, raise an error if none found. | ||
| available_images = self.list_available_system_images( | ||
| min_version=getattr(app, "min_os_version", ANDROID_MIN_OS_VERSION) |
There was a problem hiding this comment.
Recommend factoring out this getattr expression into a function, and using it in output_format_template_context. That would eliminate any risk of the two locations going out of sync.
There was a problem hiding this comment.
Also, although min_os_version is used as an integer in the Gradle template, Briefcase documents it as a string, for consistency with the other platforms. This will probably lead to a TypeError when it's compared to an integer in list_available_system_images. There should be a test to make sure we accept both types.
| skin = self.DEFAULT_DEVICE_SKIN | ||
|
|
||
| # TODO: Provide a list of options for system images. | ||
| system_image = self.DEFAULT_SYSTEM_IMAGE |
There was a problem hiding this comment.
DEFAULT_SYSTEM_IMAGE is still used in one other place, but it should be updated to make sure it's consistent with the default Android version and image type used in this function. This would probably involve creating DEFAULT properties for those two things, and using them in both locations.
|
|
||
| # Create a mock app | ||
| app = MagicMock() | ||
| del app.min_os_version # ensure getattr fallback is used |
There was a problem hiding this comment.
There should be at least one test of the attribute being present.
|
Thanks for the detailed feedback. I'll work through each point. |
|
Digging into the API level sorting here is the current state of the API level selection wizard for feedback: 
I had some questions before going any further.
That brings up another question that may be out of scope for this pr but how do we want to handle default API level selection as the years progress? |
The bottom of the list looks fine to me, since they are the newest versions.
If they have separate SDK packages, then let's show them separately. At some point, I think the package with the codename will disappear, but existing emulators should continue to work.
The ideal solution is probably to make it default to |
|
Sounds good on all three. |
…_api_level logic with gradle.py
|
Still working on this. I have been on a camping/road trip for the past 9 days and won't return until 7/6/26 😅. I should be able to submit something that week. |
|
After hitting an issue with a default selection for the tag, it comes to mind that a similar edge case could occur if |
|
ARM64 and x86_64 are our only supported architectures for the build machine, and we know they are both available for the current hard-coded default API level. So I don't think we need to worry about that now. |
3 participants
Added two step selection flow that fetches all available compatible images from
sdkmanager --list.Hard coded version is set if default is selected.
This enables the user to select an android version when creating a new emulator.
Fixes #737
PR Checklist:
Assisted-by: Claude Sonnet 4.6