At a technical level, APEX has been compared to Magisk, which works by mounting folders into the system partition at boot, rather than modifying the system partition directly (which is detectable). APEX appears to extend that same functionality over into core Android packages, separating out things like the Android Runtime into their own packages, separate from the system partition. That means they can be individually and separately updated from the system image.
It’s possible that modularized OEM modifications could then be distributed on top of a Google-maintained system image – basically meaning the version of Android itself on a given phone could potentially be updated by Google, but the bits responsible for an OEM skin could be present, updated, and maintained as separate components. That’s not to mention how it could ease ROM development, as Treble has.
It’s good to see Google working to go beyond Treble, because the cold and harsh facts are that Treble hasn’t made any serious dent in the update problem at all. The problem is as big as it’s ever been.
Treble only applies to the past ~year of phones produced. These improvements will only gather speed as people buy phones new enough to use them.
Treble was meant to solve the highly embarrassing problem of Google Pixel phones receiving a paltry 2 years of upgrades by providing a workaround to Qualcomm’s driver support policy. Essentially it defines an API version for the HAL, so as long as Google sticks to a certain version they can push upgrades to the Pixel 3 even if Qualcomm doesn’t release new drivers.
It still leaves the distribution of the upgrade (and update) to the manufacturer, so it wasn’t meant to force OEMs to do anything. And since most of the OEM’s work is skinning work (the driver comes from the SoC vendor), it wasn’t as much help to OEMs as claimed.
And yes, people like the stuff those skins add more than upgrades.
Edited 2018-11-10 13:26 UTC