xiphirx

Hi, author here. If you take a look at the end of the article under the "Acknowledgements" there is a comment from the Chromium source code that describes what the issue was. We did file an issue on AOSP's issue tracker, but nothing was accomplished there...

Hi, author here. This is definitely not a case of using shoddy app stores or installers. The vast majority of the problems stemmed from installations that came from Google Play. The article mentions a tidbit about alternate installation sources as a heads up / piece of advice for people running into the problem because we were still confused as to why it was happening for a small number of people. It just turned out that they were using shoddy app stores / installing manually, and were installing the wrong version for their device.

Hi, author here. I forgot to mention in the article that we distributed an APK that contained all libraries for each architecture for a long time. The problem existed even though the APK had all libraries for all architectures. It was not until much later that we introduced flavors for each architecture. The reason we introduced flavors was to make our app work on the Asus ZenFone. It is an x86 device, however it tries to load ARMv7 libraries (even though x86 libraries are right there in the same installation) and attempts to utilize libhoudini to work, but it just ends up crashing on app start.

Trust me, we've read the documentation surrounding this multiple times.