Some of this complexity is unavoidable. pmOS is based on the ordinary Linux stack, but even then it has a lot of trouble with supporting basic features like phone calls, etc. At least Android works as a daily driver, even in its basic AOSP version.
The way NDK is managed, which took the pressure of game devs to actually fix it (see GDC 2020 Google talks) has nothing to do with unavoidable complexity, specially given how other platforms do it.
Same applies to rebooting frameworks every year, or half baked support for Java.
Latest examples being the c, naturally created as answer to Flutter, while they are still "selling" latest improvements on GUI tooling for Constraint and Motion Layout, which are going to be legacy when Jetpack Composer happens to be finally released as stable.
Speaking of which, all stable releases have regressions. There is hardly a stable release that isn't followed up by regression complaints on Android developer channels.
+1 to all this. Android needs to take a deep breath that might need a couple of annual releases. Fix native code experience, fix the core APIs. Fix the things that are going to be around for as long as Android exists and fix them for good. The issue is the phone is just evolving too quickly. Requirements are aggressively being pushed from both the OEM side and 3P app side.
I think there are two kinds of complexity with Android. One is given from the nature of the ecosystem and the pace at which smartphone platforms have evolved. There is no fault of Android developers here. However, there is some responsibility to design the frameworks and HAL interfaces to gracefully expand into future requirements. It seems there are lots of "oh shit" APIs where they needed to be reworked. Camera.. just kidding! camera2.. just kidding CameraX!
Maybe we should treat Android API like an x86 processor (no one writes x86 assembly except compiler writers) and let the "compilers" like React Native reduce the mental strain.
There is no need to wrap the Android API in yet another Android API. This effort is already happening with AndroidX (Jetpack aka support library). The goal here is to reduce fragmentation and perform higher level functions easier. React Native solves a different thing (cross platform compatibility).
Jetpack may be a good temporary solution, but there is no reason why the core APIs, the ones that sit between the hardware and 3P apps, can't just be better.
