I believe it's similar to kernel modules in that they can either be compiled into the kernel or distributed separately. Graphene probably just distributes it as part of the system images. This just means rollouts are coupled. Apex doesn't imply closed source, only that there is a stable surface that allows more modular updates.
APEX modules have their changes released as part of AOSP quarterly and yearly releases. There were also monthly releases with the new features distributed in the monthly mainline updates until recently. GrapheneOS is entirely capable of signing APEX modules with cross-device keys and distributing updates in our App Store, but we have very frequent OS updates and little need for APEX modules. APEX modules require a reboot to kick in so we prefer doing everything via OS releases which already only have to ship changes due to delta (incremental) updates. APEX modules are only relevant to us through how they've made the code more modular and created API boundaries between modules which are stable within major releases. It creates a bit more work for us to maintain some of our changes since we need to change the defined APIs but beyond that it's largely the same as before.
No, all of the standard APEX modules are part of the Android Open Source Project. Only device-specific APEX modules used to distribute driver support aren't part of it.
ART updates are distributed via APEX since Android 12.
So is it stuck in Java 12?
I believe it's similar to kernel modules in that they can either be compiled into the kernel or distributed separately. Graphene probably just distributes it as part of the system images. This just means rollouts are coupled. Apex doesn't imply closed source, only that there is a stable surface that allows more modular updates.
APEX modules have their changes released as part of AOSP quarterly and yearly releases. There were also monthly releases with the new features distributed in the monthly mainline updates until recently. GrapheneOS is entirely capable of signing APEX modules with cross-device keys and distributing updates in our App Store, but we have very frequent OS updates and little need for APEX modules. APEX modules require a reboot to kick in so we prefer doing everything via OS releases which already only have to ship changes due to delta (incremental) updates. APEX modules are only relevant to us through how they've made the code more modular and created API boundaries between modules which are stable within major releases. It creates a bit more work for us to maintain some of our changes since we need to change the defined APIs but beyond that it's largely the same as before.
No, all of the standard APEX modules are part of the Android Open Source Project. Only device-specific APEX modules used to distribute driver support aren't part of it.