Skip to content

Re-evaluate on-device Android native_assets tests #170682

Description

@matanlurey

Unless I'm missing something, all of these tests could be replaced/would catch the same issues as tests targeting simulators or emulators.

Simulators and emulators can run on presubmit, while device-based tests cannot (due to capacity).

If true, we should turn these down and just use emulator tests (there are none today) and simulator (there is already one for iOS).

flutter/.ci.yaml

Lines 3093 to 3100 in a33b81c

- name: Linux_pixel_7pro native_assets_android
recipe: devicelab/devicelab_drone
presubmit: false
timeout: 60
properties:
tags: >
["devicelab", "android", "linux", "pixel", "7pro"]
task_name: native_assets_android

flutter/.ci.yaml

Lines 4848 to 4855 in a33b81c

- name: Mac_arm64_mokey native_assets_android
recipe: devicelab/devicelab_drone
presubmit: false
timeout: 60
properties:
tags: >
["devicelab", "android", "mac", "arm64", "mokey"]
task_name: native_assets_android

flutter/.ci.yaml

Lines 5279 to 5286 in a33b81c

- name: Mac_ios native_assets_ios
recipe: devicelab/devicelab_drone
presubmit: false
timeout: 60
properties:
tags: >
["devicelab", "ios", "mac"]
task_name: native_assets_ios

flutter/.ci.yaml

Lines 6893 to 6900 in a33b81c

- name: Windows_mokey native_assets_android
recipe: devicelab/devicelab_drone
presubmit: false
timeout: 60
properties:
tags: >
["devicelab", "android", "windows", "mokey"]
task_name: native_assets_android

/cc @jtmcdole

Activity

  1. added
    platform-androidAndroid applications specifically
    P1High-priority issues at the top of the work list
    c: tech-debtTechnical debt, code quality, testing, etc.
    team-toolOwned by Flutter Tool team
    on Jun 16, 2025
  2. dcharkes commented on Jun 16, 2025

    @dcharkes
    Contributor

    For iOS, we run both device and simulator since correct signing behavior isn't checked in the simulator.

    For Android, the emulators run x64 while the devices run arm64. I believe it should be enough to only run on a physical device for a single host OS. Does it matter capacity-wise which host OS runs on a real device?

    FYI @reidbaker

  3. reidbaker commented on Jun 16, 2025

    @reidbaker
    Contributor

    Unless a test is trying to test exercising tool code it does not matter if the host os is Linux/Mac/Windows. One issue for moving to emulators is that the tests for emulators are currently disabled because of a KVM issue in luci.

  4. matanlurey commented on Jun 16, 2025

    @matanlurey
    ContributorAuthor

    Let's assume KVM will be fixed (it's currently a P0), we won't have emulators turned off forever.

    I am interested in having this fail in presubmit, instead of post-submit. See #169798 as an example.

  5. changed the title [-]Re-evaluate on-device `native_assets` tests[/-] [+]Re-evaluate on-device Android `native_assets` tests[/+] on Jun 16, 2025
  6. matanlurey commented on Jun 16, 2025

    @matanlurey
    ContributorAuthor

    Edited to just be Android - thanks for clarifying.

  7. dcharkes commented on Jun 16, 2025

    @dcharkes
    Contributor

    I am interested in having this fail in presubmit, instead of post-submit. See #169798 as an example.

    Yes, I agree we should have at least one running on the emulator to get presubmit! Thanks for bringing this up @matanlurey!

    I do want coverage of at least one physical device due known and unknown differences. I'd like to cover al host OSes. (It wouldn't be the first time your truly does something that doesn't work on Windows. 😄) But I'm fine with having the host OSes covered with either emulator or device. 👍

    Should we keep the largest pool hostOS device. Is that Linux? And then switch MacOS and Windows to emulators?

    Edit: Or do we have so much emulator capacity that we should make all 3 OSes emulator, and have Linux as device. (So Linux is both device and emulator.)

  8. matanlurey commented on Jun 16, 2025

    @matanlurey
    ContributorAuthor

    Emulator capacity on Linux is the cheapest thing we have, there is no special machine pool.

  9. github-actions commented on Jul 1, 2025

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  10. locked as resolved and limited conversation to collaborators on Jul 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work listc: tech-debtTechnical debt, code quality, testing, etc.platform-androidAndroid applications specificallyteam-toolOwned by Flutter Tool team

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions