New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide x86 Android Release binaries #9253

Open
eseidelGoogle opened this Issue Apr 6, 2017 · 25 comments

Comments

Projects
None yet
@eseidelGoogle
Copy link
Contributor

eseidelGoogle commented Apr 6, 2017

We learned in #2898 that Android x86 accounts for over 1% of Android devices, that's over a million devices.

This bug tracks doing so.

EDIT: See @rmacnak-google comments below. Implementing x86 Android Ahead of Time (AOT) compiled binaries will require a substantial amount of work in the Dart compiler. We could however implement JIT-based --release binaries for x86 with some minor plumbing work if needed.

@eseidelGoogle eseidelGoogle added this to the 3: Make conferences happy milestone Apr 6, 2017

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented Apr 6, 2017

See also #2089 which is a similar bug for iOS about providing more flavors of pre-built binaries.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented Apr 6, 2017

@rmacnak-google Are there any Dart limitations to supporting x86 Android Release binaries (i.e. does AOT work)? If so could you please link to such bugs?

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented Apr 6, 2017

Assuming no Dart limitations, it should be possible to work around us not currently providing these pre-built binaries by building the flutter engine yourself and using the --local-engine option to flutter:
https://github.com/flutter/engine/blob/master/CONTRIBUTING.md

@rmacnak-google

This comment has been minimized.

Copy link
Contributor

rmacnak-google commented Apr 6, 2017

The Dart VM does not support AOT compilation for x86. AOT is supported for x64, ARM, ARM64 and MIPS.

(When targeting x86, we reference constants directly from instructions, but on all other architectures we load them through a constant pool, which allows us to handle their relocation. It is possible to do this on x86 as well, but it is a substantial change.)

The VM does support disabling the vm-service, etc for the JIT just as it does for AOT, so it would be possible to build a release version of the engine for x86 that uses the JIT.

@danilNikolaenko1990

This comment has been minimized.

Copy link

danilNikolaenko1990 commented Jun 12, 2017

when I tried to launch demo application I got the message
Profile and release builds are only supported on ARM targets.
Error running application on ASUS T00J.
It is very sadly that flutter is not for x86, because there are many devices on Intel atom.

@eseidelGoogle eseidelGoogle modified the milestones: 3: Current Milestone, 4: Next milestone Sep 28, 2017

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented Sep 28, 2017

Given the amount of work in the Dart VM, I suspect this is more realistically M4 than M3.

@kirbyfan64

This comment has been minimized.

Copy link

kirbyfan64 commented Oct 15, 2017

So, in the mean time I've been distributing a debug APK...not fun!

I've built Flutter manually in x86 release mode, but when I try to build the app it crashes saying precompilation isn't supported.

Is there a way to make a release build of Flutter with precompilation disabled?

@kirbyfan64

This comment has been minimized.

Copy link

kirbyfan64 commented Nov 2, 2017

So I managed to build it for X86 in release mode with AOT disabled using this patch:

diff --git a/shell/platform/android/BUILD.gn b/shell/platform/android/BUILD.gn
index 517b2a5e4..8800a4450 100644
--- a/shell/platform/android/BUILD.gn
+++ b/shell/platform/android/BUILD.gn
@@ -47,11 +47,11 @@ shared_library("flutter_shell_native") {
     "//garnet/public/lib/fxl",
     "//third_party/skia",
   ]
-  if (flutter_runtime_mode == "debug") {
+  # if (flutter_runtime_mode == "debug") {
     deps += [ "//dart/runtime:libdart_jit" ]
-  } else {
-    deps += [ "//dart/runtime:libdart_precompiled_runtime" ]
-  }
+  # } else {
+    # deps += [ "//dart/runtime:libdart_precompiled_runtime" ]
+  # }
 
   public_configs = [
     "$flutter_root:config",
diff --git a/tools/gn b/tools/gn
index fded2b0c2..30f3729d6 100755
--- a/tools/gn
+++ b/tools/gn
@@ -97,6 +97,7 @@ def to_gn_args(args):
           aot = True
     else:
       aot = False
+    aot = False
 
     if args.runtime_mode == 'debug':
         gn_args['dart_runtime_mode'] = 'develop'

Except, someone tried it, and it's stuck on a black screen. The logcat doesn't mention anything wrong. Is this even possible right now? 😐

@rock3r

This comment has been minimized.

Copy link
Contributor

rock3r commented Jan 17, 2018

Just to chime in to this, I've just had this issue where I needed to ship a new Android build ASAP for a certain app while I was out and about, and I didn't have a USB cable to connect my phone to my computer to smoke test the build. I was counting on being able to use the Android emulator but I found out about this limitation. It was a painful moment but I managed to get a cable from someone and test the build; had I not been at an Android meetup I'd have had some issues, though.

I think it's quite important to get to support Android release builds on emulators. I did not expect this limitation to be there, and I imagine most other devs wouldn't either. It's not a small issue
either in normal flows — why should I not be able to run my app on an emulator? What if I need to run screenshot tests on a CI without physical emulators? Or maybe auto-generate screenshots for the store listing, or any other number of legit workflows in which one needs to be able to install a release build on to an emulator.

@mit-mit

This comment has been minimized.

Copy link
Member

mit-mit commented Mar 6, 2018

Note: when this is eventually fixed, make sure to update the FAQ: https://github.com/flutter/website/pull/856/files

@p30arena

This comment has been minimized.

Copy link

p30arena commented Apr 8, 2018

No news on this?
Aren't you gonna support AOT on x86?

@Hixie Hixie added team and removed team: infra labels Apr 23, 2018

@slightfoot

This comment has been minimized.

Copy link
Member

slightfoot commented May 9, 2018

Could someone from the Flutter team confirm that this issue is required to be action to get Android based Flutter apps running on ChromeOS?

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented May 9, 2018

This ticket should not be required, no. My understanding is most ChromeBooks support ARM emulation.

@ds84182

This comment has been minimized.

Copy link
Contributor

ds84182 commented Sep 7, 2018

On the latest version of Chrome OS Flutter apps start up slowly (e.g. black screen for 30 seconds on first start up, slow animations, etc.) on x86 Chromebooks. It also impacts the ability to use native x86 libraries for other components of the app.

Unfortunately we're considering dropping Flutter (for now) because of this issue... something I really don't want to do but we need things to be as fluid as possible.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented Sep 7, 2018

@jslavitz or @tvolkert seems worth us trying to repro what @ds84182 is seeing on a Chromebook? That may be unrelated to x86 support.

@ds84182

This comment has been minimized.

Copy link
Contributor

ds84182 commented Sep 7, 2018

The Chromebook I tested Flutter Gallery (from Google Play) on is a HP Chromebook 11 G5, which has an Atom CPU. The slowness issues disappear after playing with Gallery for a while, so Chrome OS probably generates slow code for the initial ARM to x86 translation.

Right now I'm trying to see if I can build an x86 release version.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor

eseidelGoogle commented Sep 7, 2018

x86 JIT builds should be possible to build (by modifying the Flutter engine's release build for x86 a little), but x86 AOT does not work currently as discussed in #9253 (comment).

@ds84182

This comment has been minimized.

Copy link
Contributor

ds84182 commented Sep 10, 2018

Messed around with it a bit today and I was able to make a dynamic release build for x86. Required some edits to the flutter tool and gradle, but no changes on the engine side. I can PR the flutter tool + gradle changes, but someone more knowledgeable about engine builds (@chinmaygarde probably?) has to add builds for android-[x86|x64]-dynamic-[profile|release]...

@chinmaygarde

This comment has been minimized.

Copy link
Member

chinmaygarde commented Sep 10, 2018

@ds84182

TL;DR: Rebrand android-x86-debug as android-x86-release and tell the tools that release mode for x86 is JIT not AOT.

Normally, to prepare a release mode APK for Android on x86, you'd need an android-x86-release variant of the engine. Notice the missing dynamic tag. The dynamic tag is for a WIP configuration that allows JIT compiled code to be deployed to an Android target with the ability to be patched post install. This configuration is not yet ready and the exact semantics of its operation are yet to be determined (not to mention that just calling it dynamic is hella confusing). The analogue to the current release variants for Android would be a configuration in which the Android engine can take AOT compiled x86 code and run the same. I am sure the engine can be built to do this just fine. But, as mentioned in this comment, the AOT snapshotter on x86 is currently a no-go. What Ryan suggested in that comment is that instead of using AOT in that configuration, we rebrand the variant that uses JIT code execution to be the new release mode. So, just calling the android-x86-debug mode the android-x86-release mode should suffice. The should be nothing more to do on the engine side.

Of course, the tooling will now have to be told that release mode on x86 is no longer AOT, and that it should generated kernel (JIT) snapshots instead.

Let me know if I have not done an adequate job of explaining the situation. Unfortunately, with the number of permutations of target (x86, x86, armv7, aarch64), OS (iOS, Android), host (Mac, Linux) and build (Debug, Profile, Release and the WIP variant confusingly called Dynamic) variants, it gets hard to keep track of which variant to use and where. I am trying to document this complexity, but, in the meantime, I hope to made the proposed resolution for this issue from the engines perspective clearer. Happy to answer followup questions.

@chinmaygarde

This comment has been minimized.

Copy link
Member

chinmaygarde commented Sep 10, 2018

@ds84182: Just catching up on this thread. It looks like HP Chromebook 11 G5 already supports x64. It is possible that since the Flutter Gallery published to the Play store may not have an x64 variant advertised, the device says the that arm variant is fine to use. Later, this device does a poor job of emulating ARM. Can you build the Flutter gallery locally with the Android x64 variant of the engine and deploy to the device? That should get rid of your performance issues due to emulation.

There is no reason you should have to incur the emulation overhead on this device. This only applied to old x86 only devices.

@chinmaygarde

This comment has been minimized.

Copy link
Member

chinmaygarde commented Sep 10, 2018

@jslavitz & @tvolkert: Can I get an HP Chromebook 11 G5? I want to pull the Flutter Gallery from the store and check to ensure that we are indeed not serving the x64 variant on this device and instead falling back to armv7 with unnecessary emulation overhead.

@eseidelGoogle: Can i get access to the Google Play Store listing for the gallery to check to see how it is configured? We should be publishing architecture specific variants already but I have a suspicion we are not. This might be causing unnecessary emulation overhead on device that may be otherwise capable enough to carry our such emulation.

@ds84182

This comment has been minimized.

Copy link
Contributor

ds84182 commented Sep 10, 2018

@lordgreg

This comment has been minimized.

Copy link

lordgreg commented Dec 12, 2018

Hi. So, this issue is still open and more than 3 months old. Is there anything you're doing on it in the near future?

Regards :)

@tvolkert

This comment has been minimized.

Copy link
Contributor

tvolkert commented Dec 12, 2018

@rmacnak-google @alexmarkov out of curiosity, has there been any change in the last year and a half on support for AOT compilation of x86?

@a-siva

This comment has been minimized.

Copy link
Contributor

a-siva commented Jan 15, 2019

@tvolkert to answer your question above there has been no change on support for AOT compilation of x86.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment