As someone that has done on and off Android programming as hobby since NDK was introduced in Android 2.2, and regularly follows ADB Podcast, I doubt it.
Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.
Yeah man, I don't get it. There are shitty parts of android development, and there are great parts of android development, but android studio is fine. (I didn't say great, I said fine. Perfectly adequate.)
NDK programming still sucks, although it's been slowly getting better. Android's activity/fragment lifecycle/state restart is a bugfuck. There are legitimate grievances to be had here, but this guy isn't hip enough to the system to make them.
I don't mean it is going away. What I mean is this attitude:
"The NDK is not appropriate for most novice Android programmers, and has little value for many types of Android apps."
"Squeeze extra performance out of a device for computationally intensive applications like games or physics simulations."
"Reuse your own or other developers' C or C++ libraries."
Versus the Windows Phone and iOS that allow full use of the OS APIs via their Objective-C++ and C++/CX, instead of a thin set of libraries + JNI boilerplate.
Then we have the way the whole Eclipse CDT -> Android Studio process has been handled and Gradle still cannot handle the majority of ndk builds.
I am also glad it is there, it is also where I spend most of my Android coding time.
My point is that the way Android team deals with NDK users seems like the NDK was imposed on the team, and they don't spend much developer time on it, looking from the set of open issues, outdated documentation where ndk-build is still used instead of cmake, integration with aar is still in progress, and set of available APIs.
The way Android NDK and AGK experience works, I always have the feeling it is maintained as a 20% project and none of the developers has ever used anything from the competition.
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.
The "stability" of Android Studio stable releases, how much Android build system requires as developer workstation (Google employees must all use gaming rigs), the artisanal tooling on the NDK front, lack of easier JNI integration after 10+ years,...
So easy for anyone that has suffered throught Android development.
Starting with Eclipse, then rebooting the whole development environment just because some management guys happened to be InteliJ users.
Several years later there are still Eclipse based tools, like the graphical manifest editor, that haven't been replicated in Studio.
NDK is treated as a 20% project, done by an handfull of engineers.
Devs were left in the cold when the migration away from Eclipse was decided. It was only due to the coincidence of Clion being developed, that Studio eventually got C++ support.
The amount of cruft on NDK build tools is a joke, already with 4 official variations.
The decision to use Gradle has made "how to optimize builds" a recorrent topic in any major Android conference.
Google teams like Android development build tools so much that they rather use blaze, throwing yet another build tool into the mix.
There isn't a single release of Android Studio or the Support Library, that isn't followed by bug related complaints on online forums, despite being several weeks, months, in testing phase.
Their initial emulator implementations was so lousy, that it required the public shame of Genymotion and Microsoft doing a better job for Google actually improving theirs.
There was so much more to rant about, but this is already quite long.
Had you been through the trouble of installing it, and tried the NDK, you would have found a primitive development experience requiring devs to manually copy code from GitHub to use NDK frameworks.
How after 10 years Google thinks that is a good development experience baffles me.
I do audio programming, among other things. This sadly requires a familiarity with low level mobile development that many find.... distasteful.
I would advise anybody listening to stay well away from NDK programming. Here there be dragons. Google has done their absolute best to pretend nobody ever needs to get their hands dirty in android. Which would be nice, if it were true.
It continues to amaze me that as people lay more and more interesting ways to interact with android using the ndk, even from within google itself, the official word on the NDK remains; don't use this unless you really really have to.
- 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.
Every time I am fighting with the Android SDK, and specially with the NDK since they deprecated Eclipse CDT or a new Support Library or Android Studio version comes out, I wonder how many of "the smartest engineers on the planet" do actually work on Android.
I think the problem is that coming from Eclipse, Android Studio is ABSOLUTELY GREAT. It's an order of magnitude better that what we had.
Personally I think it has a few rough edges (memory/CPU usage, designing weirdnesses) but it's mostly fine. It's Android development itself that still has some pointy bits, especially in regards to building and dependencies.
Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.
reply