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
Flutter does not provide prebuilt ARM64 binaries for Android #6715
I suspect there will be some complexity in the tooling w.r.t the AOT snapshotter since the i386 based snapshotter for armv7a wont work when creating snapshots for aarch64 (we could just the same snapshotter that is used for iOS but obviously that is absent on linux hosts).
On the engine side there is nothing to do. ./flutter/tools/gn --android --android-cpu=arm64 should build the appropriate engine.
Estimate: See if it already works and we haven't broken it :)
The buildbot would have to build and upload the assets to the cloud.
Estimate: Maybe a few mins to cook up the patch to build and upload the new artifacts.
The Flutter tools currently assume that Android uses the armv7 engine and iOS the aarch64 engine. Because of this, it defaults to using the i386gen_snapshot for Android targets and the x86_64gen_snapshot for iOS when generating the AOT snapshot. This assumption would no longer hold and the tools would need to select the correct gen_snapshot depending on the Android target CPU. I believe flutter build flx already has a --flavor flag that we can use to communicate the intent to the Android build scripts as well. We already support x86_64 Android target so arm64 should be more of the same kind of variant selection.
Estimate: I am not too familiar with the Flutter tooling side but it can't be more than a few days work at most for someone unfamiliar with that codebase.
On Android, the --flavor option is currently used to specify Android product flavor (e.g. demo version vs full version of the app), not target architecture.
We could repurpose it of course, but we risk confusing Android developers.
Gradle tooling supports building multiple APKs at the same time, each targeting a different density/ABI combination.
flutter build aot
flutter build apk and
flutter build flx
build both the 32 bit and 64 bit flavors always
or
we wire the --target-platform which is currently only supported in 'flutter build aot' to accept android-arm64. This same option would also have to be plumbed into 'flutter build flx' and 'flutter build apk' for consistency.
I think it makes sense to have a --target-platform (with some useful default).
flutter build flx will presumably go away soon.
Ideally flutter install would call flutter build in the same way that flutter run does, picking the right default, so it's only when you actually ship the final app that you have to worry about this.
What does the play store expect? Binaries for every architecture supported?
I think it makes sense to have a --target-platform (with some useful default).
Agreed. Potentially also useful for iOS, depending on how we implement armv7 support, once that makes it higher in the priority list (though I'd imagine the implementation there might be fat binaries most of the time).
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.
Activity
tvolkert commentedon Dec 22, 2017
Per @chinmaygarde:
eseidelGoogle commentedon Jan 4, 2018
This will be required by the Play Store by August 2019:
https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
I expect we'll have it long before then however.
eseidelGoogle commentedon Jan 12, 2018
@chinmaygarde @cbracken @mravn-google @jason-simmons do we have a high-level guesstimate of what work will be required to make this work?
chinmaygarde commentedon Jan 17, 2018
./flutter/tools/gn --android --android-cpu=arm64should build the appropriate engine.armv7engine and iOS theaarch64engine. Because of this, it defaults to using thei386gen_snapshotfor Android targets and thex86_64gen_snapshotfor iOS when generating the AOT snapshot. This assumption would no longer hold and the tools would need to select the correctgen_snapshotdepending on the Android target CPU. I believeflutter build flxalready has a--flavorflag that we can use to communicate the intent to the Android build scripts as well. We already supportx86_64Android target soarm64should be more of the same kind of variant selection.mravn-google commentedon Jan 18, 2018
On Android, the
--flavoroption is currently used to specify Android product flavor (e.g. demo version vs full version of the app), not target architecture.We could repurpose it of course, but we risk confusing Android developers.
Gradle tooling supports building multiple APKs at the same time, each targeting a different density/ABI combination.
a-siva commentedon Jan 30, 2018
We have two options -
build both the 32 bit and 64 bit flavors always
or
we wire the --target-platform which is currently only supported in 'flutter build aot' to accept android-arm64. This same option would also have to be plumbed into 'flutter build flx' and 'flutter build apk' for consistency.
Hixie commentedon Jan 30, 2018
What would
flutter runbuild?Hixie commentedon Jan 30, 2018
I think it makes sense to have a
--target-platform(with some useful default).flutter build flxwill presumably go away soon.Ideally
flutter installwould callflutter buildin the same way thatflutter rundoes, picking the right default, so it's only when you actually ship the final app that you have to worry about this.What does the play store expect? Binaries for every architecture supported?
cbracken commentedon Jan 30, 2018
Agreed. Potentially also useful for iOS, depending on how we implement armv7 support, once that makes it higher in the priority list (though I'd imagine the implementation there might be fat binaries most of the time).
eseidelGoogle commentedon Jan 31, 2018
We had a client need this sooner than expected. @jason-simmons took this on and is almost done.
cbracken commentedon Feb 12, 2018
@jason-simmons is this safe to close?
Hixie commentedon Feb 14, 2018
@jason-simmons says this is fixed!
github-actions commentedon Sep 3, 2021
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.