- Kotlin, the successor, still faces lots of tooling issues, regarding incremental builds, code completion, thin APKs,...
- NDK users keep being neglected, after 10 years there is still no alternative to manually write JNI boilerplate, handle native libraries, a proper C++ API in the NDK, the ones that exist like Oboe are either plain code dumps on GitHub, or use Blaze, which isn't part of the standard SDK tooling, IDE tools if they get added always feel like an afterthought to their Java/Kotlin counterparts
- Stable support library and Android Studio releases have as much bugs as canary ones
- Android Studio feels like it needs a rendering workstation to work properly
The last two points have escalated so high that they finally created Project Marble to improve the current state of affairs.
Building performant UIs has become a lost art across the entire industry. As a junior engineer I was given a hard time if any screen did not load in 250ms saying that was the cliff beyond which humans perceive things as slow. Now I have had multiple bugs I filed for a web based tool being too slow (> 30s load times) closed because the tool is working as intended.
- Android J++
- Kotlin, the successor, still faces lots of tooling issues, regarding incremental builds, code completion, thin APKs,...
- NDK users keep being neglected, after 10 years there is still no alternative to manually write JNI boilerplate, handle native libraries, a proper C++ API in the NDK, the ones that exist like Oboe are either plain code dumps on GitHub, or use Blaze, which isn't part of the standard SDK tooling, IDE tools if they get added always feel like an afterthought to their Java/Kotlin counterparts
- Stable support library and Android Studio releases have as much bugs as canary ones
- Android Studio feels like it needs a rendering workstation to work properly
The last two points have escalated so high that they finally created Project Marble to improve the current state of affairs.
OEMs love Android only because it is free beer.