You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Support Linux ARM64 Host -> Android target Flutter development #75864
Android Studio IDE being JetBrains product, should be straightfoward. IntelliJ CE / Ultimate work mostly fine on aarch64 for example (found that jdk8 is incompatible on aarch64, jdk11+ can be used with the IDEs however).
Unless there are specific plugins bundled with Android Studio relying on x86/x86_64 code, the IDE itself shouldn't be a problem.
The android sdk build tools on the other hand, are problematic in comparison. There are a few blog posts for compiling debian arm versions of the tools but the process can't be described as easy or straight forward.
The android sdk build tools on the other hand, are problematic in comparison. There are a few blog posts for compiling debian arm versions of the tools but the process can't be described as easy or straight forward.
Unfortunately, Flutter would require both the Android SDK and JDK 8 to build android apps.
I don't know if the JDK 8 behaviour I've observed with JetBrains IDEs on aarch64 would affect Android SDK as well.
Experimentation results with Android SDK compiled for aarch64 will be preferable.
There are versions of the android build tools for Termux as far I am aware but haven't tested in Linux environment on SBC.
If the Android SDK can be compiled and used successfully with Linux aarch64 host, how would this fit in the Flutter infrastructure? I haven't checked if the Android sdk is being built or just fetched thus far.
If the Android SDK can be compiled and used successfully with Linux aarch64 host, how would this fit in the Flutter infrastructure? I haven't checked if the Android sdk is being built or just fetched thus far.
We depend on the user bringing their own Android SDK, via Android Studio. We don't technically need the full Android Studio to build a Flutter android app, however we list it as an official requirement because it's the easiest way for the Flutter CLI tool to determine that the user has (and where they are) the AVD Manager and JDK 8.
I don't think the Flutter team wants the maintenance and CI/storage overhead of pre-building an ARM Android SDK, but if people in the community built it, you could provide the ANDROID_SDK_ROOT environment variable and the Flutter tool would pick it up.
Reacted by PakoSt, Jay Freeman (saurik), Can Kolay, ncdm-stldr and Francesco Iapicca
Everything is on track, I can only build a debug app. I tried to build a release app unfortunately I couldn't. I even tried to build an app for android-arm64 only everything seems to be successful but when opening it crashes and says: vm. Must be able to initialize the VM.
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.
Update: relanding the AOT engine support that was reverted in #186693, this time via cross-compile from the existing linux-x64 bot pool — no new arm64 bots, no dependency on the Android SDK CIPD package getting a linux-arm64 build.
Validated end-to-end on native linux-x64 hardware (Debian 12 Docker, real Intel x86_64, no QEMU). Original validation 2026-05-29 against c7f49fe0 produced linux-arm64.zip (1.77 MB) — the exact artifact whose absence broke flutter precache --all last time. Fresh re-validation 2026-06-04 against 14c05c42 (then-current main) confirmed the cross-compiled gen_snapshot is a valid ELF aarch64 PIE linked against glibc, not Android bionic.
Reland PR is now open: #187591. End-to-end runtime smoke on real arm64 Linux passes (binary loads, runs, produces a valid Android arm64 AOT snapshot). Framework changes (the flutter_tools cache/artifact-path side that closes this issue end-user-side) will follow once the new builder has emitted artifacts to GCS for at least one release — the sequencing is what was missing the first time around.
To see what this means for Flutter, I built a debug APK from current master on native arm64 Linux, in an environment that cannot run x86-64 binaries, using AGP 9.5.0-alpha08 and Gradle 9.6.0. The build succeeded, and tracing every process it started showed one remaining x86-64 dependency: AGP calls the NDK's llvm-strip, which is still x86-64 only, so the native libraries were packaged unstripped. Profile and release builds would also need gen_snapshot for linux-arm64, which is what #187591 provided.
@jtmcdole, is this enough to revisit #187591, or would you prefer to wait for a stable AGP release and NDK r31?
Activity
psstoyanov commentedon Feb 18, 2021
Android Studio IDE being JetBrains product, should be straightfoward. IntelliJ CE / Ultimate work mostly fine on aarch64 for example (found that jdk8 is incompatible on aarch64, jdk11+ can be used with the IDEs however).
Unless there are specific plugins bundled with Android Studio relying on x86/x86_64 code, the IDE itself shouldn't be a problem.
The android sdk build tools on the other hand, are problematic in comparison. There are a few blog posts for compiling debian arm versions of the tools but the process can't be described as easy or straight forward.
christopherfujino commentedon Feb 18, 2021
Unfortunately, Flutter would require both the Android SDK and JDK 8 to build android apps.
psstoyanov commentedon Feb 18, 2021
I don't know if the JDK 8 behaviour I've observed with JetBrains IDEs on aarch64 would affect Android SDK as well.
Experimentation results with Android SDK compiled for aarch64 will be preferable.
There are versions of the android build tools for Termux as far I am aware but haven't tested in Linux environment on SBC.
If the Android SDK can be compiled and used successfully with Linux aarch64 host, how would this fit in the Flutter infrastructure? I haven't checked if the Android sdk is being built or just fetched thus far.
christopherfujino commentedon Feb 18, 2021
We depend on the user bringing their own Android SDK, via Android Studio. We don't technically need the full Android Studio to build a Flutter android app, however we list it as an official requirement because it's the easiest way for the Flutter CLI tool to determine that the user has (and where they are) the AVD Manager and JDK 8.
I don't think the Flutter team wants the maintenance and CI/storage overhead of pre-building an ARM Android SDK, but if people in the community built it, you could provide the
ANDROID_SDK_ROOTenvironment variable and the Flutter tool would pick it up.bdloser404 commentedon Sep 16, 2023
Termux support Flutter SDK
for those who need android host support for termux.
Well , Flutter SDK already support Linux_arm64
now, we can use
ld-linux-aarch64.so.1for compile flutter SDK in Termux .ld-linux-aarch64.so.1from gpkg-dev (install usingpacmanbootstrap)for for information check:
https://github.com/bdloser404/Fluttermux/blob/main/fluttermux (open source)
Hassen-Alsayadi commentedon Oct 1, 2023
Everything is on track, I can only build a debug app. I tried to build a release app unfortunately I couldn't. I even tried to build an app for android-arm64 only everything seems to be successful but when opening it crashes and says: vm. Must be able to initialize the VM.
15 remaining items
Ship gen_snapshot for linux-arm64 hosts targeting Android (flutter#18…
github-actions commentedon May 13, 2026
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 -vand a minimal reproduction of the issue.Revert "Ship gen_snapshot for linux-arm64 hosts targeting Android" (f…
jtmcdole commentedon May 20, 2026
Re-open: We revered the change that closed this
Revert "Ship gen_snapshot for linux-arm64 hosts targeting Android" (f…
[beta ] Revert "Ship gen_snapshot for linux-arm64 hosts targeting And…
Revert "Ship gen_snapshot for linux-arm64 hosts targeting Android" (f…
dbebawy commentedon Jun 5, 2026
Update: relanding the AOT engine support that was reverted in #186693, this time via cross-compile from the existing linux-x64 bot pool — no new arm64 bots, no dependency on the Android SDK CIPD package getting a linux-arm64 build.
Validated end-to-end on native linux-x64 hardware (Debian 12 Docker, real Intel x86_64, no QEMU). Original validation 2026-05-29 against
c7f49fe0producedlinux-arm64.zip(1.77 MB) — the exact artifact whose absence brokeflutter precache --alllast time. Fresh re-validation 2026-06-04 against14c05c42(then-currentmain) confirmed the cross-compiledgen_snapshotis a validELF aarch64 PIElinked against glibc, not Android bionic.Reland PR is now open: #187591. End-to-end runtime smoke on real arm64 Linux passes (binary loads, runs, produces a valid Android arm64 AOT snapshot). Framework changes (the
flutter_toolscache/artifact-path side that closes this issue end-user-side) will follow once the new builder has emitted artifacts to GCS for at least one release — the sequencing is what was missing the first time around.Reland: Ship gen_snapshot for linux-arm64 hosts targeting Android
Revert "Ship gen_snapshot for linux-arm64 hosts targeting Android" (f…
jtmcdole commentedon Jul 2, 2026
This is blocked on Android not provide tooling for arm64 Linux hosts.
dbebawy commentedon Oct 5, 2026
Google has started publishing official Linux arm64 Android tooling. aapt2 9.5.0-alpha08 ships a native
linux_arm64build, and AGP 9.5.0-alpha08 selects it automatically on arm64 Linux hosts (https://android.googlesource.com/platform/tools/base/+/01d0a095a18edfd00b367e6b2665fe3d04aea65b). The NDK maintainers have also said that a linux/arm64 NDK is coming in r31 (android/ndk#1752 (comment)).To see what this means for Flutter, I built a debug APK from current master on native arm64 Linux, in an environment that cannot run x86-64 binaries, using AGP 9.5.0-alpha08 and Gradle 9.6.0. The build succeeded, and tracing every process it started showed one remaining x86-64 dependency: AGP calls the NDK's llvm-strip, which is still x86-64 only, so the native libraries were packaged unstripped. Profile and release builds would also need gen_snapshot for linux-arm64, which is what #187591 provided.
@jtmcdole, is this enough to revisit #187591, or would you prefer to wait for a stable AGP release and NDK r31?