> We started to log the installer package name in our crashes and quickly figured out that, yes, users were installing the app from various sources, and each new UnsatisfiedLinkError was coming from a manually installed app where the user mistakenly installed the wrong flavor for their device’s architecture.
It is probably still blamable on bad design from Android, that it's possible to successfully install and launch an app that can only possibly use some of the code it requires (or maybe the app devs need to do something to indicate the native libraries are absolutely required?)
Security vulnerabilities and bugs happen regularly in every major operating system. Windows, Mac OS X, Linux, iOS, Windows Mobile, Android, etc. Most of the time these bugs are patched in a timely fashion due to the fact that the publisher can release a bug fix directly to the end user's device. This applies to everything except most Android devices.
When a major bug is discovered in Android, first, Google fixes it and published the code. This is usually done quickly. Second, the phone manufacturers take that fix and incorporate it into their own Android build process with all their extra layers (HTC Sense, Samsung TouchWiz, etc). This second step takes anywhere from a few weeks to infinity (aka it never happens). Third, the carrier takes the manufacturers build and adds their own cruft to it, maybe tests it, and then pushes it out to their customers as an over the air (OTA) update. This third step takes anywhere from a month to infinity (aka it never happens).
Due to the interference of manufacturers and carriers, I would not recommend using Android on anything other than a Nexus device purchased directly from Google or a retail/online store. Even a Nexus, when purchased from a carrier, won't get updates as quickly as it should (speaking from experience with my Nexus 6 and T-Mobile).
When Texas Instruments exited, it's likely neither Google nor anyone else had the proper legal agreements in place to force the release or licensing of the appropriate code/patents to ensure continued updates. After this rather large debacle which affected numerous manufacturers in the mobile industry, I'd wager that's now part of all of them.
Don't forget that even without an exit, sometimes OEMs don't update drivers, leaving manufacturers to drop support far earlier than they should in the lifespan of a product. Case in point, the 2008 Apple Macbook. It only had 32-bit graphics drivers. So, that meant it couldn't run the 64-bit-only OS X Mountain Lion released just 4 years later in 2012. I found this all out firsthand supporting my girlfriend's problematic 2008 Macbook (which also had notoriously bad connections to the LCD panel).
Sure, and bugs happen and Google often fixes them, but the fixes don't reliably end up in the hands of users before devices eventually die and are replaced. It's hard for me to believe this is still an issue this many years into Android's existence, but here we are.
> We started to log the installer package name in our crashes and quickly figured out that, yes, users were installing the app from various sources, and each new UnsatisfiedLinkError was coming from a manually installed app where the user mistakenly installed the wrong flavor for their device’s architecture.
It is probably still blamable on bad design from Android, that it's possible to successfully install and launch an app that can only possibly use some of the code it requires (or maybe the app devs need to do something to indicate the native libraries are absolutely required?)