1.) Majority of the apps with NDK code will ship x86 binaries as well. It's very rarely a problem.

2.) For those that don't, libhoudini does an ok job even on slower phones. On faster chromebooks that shouldn't be an issue at all.

This does, however mean that

1. This depends on closed-source code (libhoudini is Intel code, and it's not open, last I heard). I guess it's not the first piece of closed-source code in Chromebooks, but it's a crucial piece.

2. This code is still not portable, it just runs on 2 archs, unless someone writes a libhoudini for all other archs as well.

What "other archs"? Android only supports 3 ARM architectures (all of them will load armeabi binaries), x86 and MIPS (with 0 MIPS devices or phones being on the market).

Chromebooks run only ARM or x86.

Again, this is an issue that's relevant to a tiny minority of the applications since vast majority do not ship native binaries.

Even if no official Android devices use MIPS today, that could change tomorrow. And there are lots of Android forks, I would be very surprised if none of them use MIPS.

I don't think it's a major blocker, qemu already let's you emulate any arch that you need. Replacing libhoudini with a qemu based version would likely be straightforward.

"In reality, we expect about one quarter of the apps to not have Intel [x86] binaries," Hornung told Ars

http://arstechnica.com/gadgets/2016/05/the-play-store-comes-...

Hopefully that means we'll see a lot more ARM-based Chromebooks as well going forward. No need for an Intel monopoly in the architecture agnostic Chrome OS world, so I hope Google and its partners will stop encouraging that monopoly going forward.

Cortex A72/Snapdragon 820 have Core M-level performance. If Core M is good enough for a $400 Chromebook, then those are also good for a $300 touch-enabled Chromebook.

I'm not an expert in this field, but I did want to say that I had an Asus Zenfone 2 (x86 phone) for a brief time, and app compatibility was never an issue. I ran into 0 apps that I couldn't run.

I had the Zenfone 2 as well, and the notable exception to that was Snapchat. About six months ago, they stopped making x86 versions of the app, and video was pretty pitiful.

Have you had a chance to compare that to the performance of their non-x86 app? I'm curious because I've found SnapChat to perform exceptionally poorly on every Android device I've tried.

Yes. No issue with the Nexus 5. Recording video with the Zenfone 2 was pretty poor -- totally choppy.

Most apps ship with multiple binaries for the appropriate architecture. For those apps that don't have the necessary binaries the native code will be translated on the fly to the host architecture instruction set. Since Chromebook's are significantly faster than smartphones the small performance hit shouldn't be noticeable.

There are also many Arm Chromebooks.

Are there?

They are pretty well split.

Many x86 Chromebooks offer several tiers that obfuscate the data, but in terms of product line releases, they're about 50/50.

Both Samsung Chromebooks, ASUS Chromebook Flip, HP Chromebook 14 G3, Haier and Hisense's both as well, for example, are ARM devices.

Ah, the list of x-86 Chromebooks easily out number the ARM ones available.

Source? On Android and under ARC you're SOL if an NDK app doesn't provide binaries for your architecture. This is rarely an issue though, as most apps just opt to ship with binaries compiled for every supported ABI.

https://developer.android.com/ndk/guides/abis.html

That's not really true - x86 devices mostly come with libhoudini layer which can load and translate ARMv7 binaries on the fly. Hence if the app ships armeabi code you're pretty much set.

ARC is dead. The Android Framework in ChromeOS is now a container.

"For those apps that don't have the necessary binaries the native code will be translated on the fly to the host architecture instruction set"

How would this happen?

Via an ARM/Android emulator? There's already one in the android development suite.

Thanks god no :) That would be really slow and painful. It is a translation layer, not an emulator.

binary translation.