3 ms·

We often hear about all the great engineers at Google, but their project managers must be some of the worst in the industry. So many half baked and forgotten pr

We often hear about all the great engineers at Google, but their project managers must be some of the worst in the industry. So many half baked and forgotten projects that wasn't good enough when they came out, left with few and slow upgrades, and then killed off. How many messaging apps have Google launched and killed? How many WearOS watches have they sold? How's the Android tablet ecosystem? How did the Nexus rebranding to Pixel go? They seem to lack any interest in polish and usability, beyond removing features and adding whitespace and larger margins. You would have to be crazy to adapt any new service from them, be it Messages, Stadia, or buying last year's phone for this year's price.

pjmlp 7y ago
The state of NDK is a good example. It appeared that the Android team was kind of forced to support C++ for game developers, and they did an half baked release with Android 2.0. Using headers and toolchains different than what regular Android (internal Google teams) were using, thus took them all the way up to release 14 to actually provide unified headers. Bionic wasn't fully ISO C compliant and has been being improved throughout all the NDK and Android releases. Back when they decided to drop Eclipse there wasn't a roadmap for C++ support going forward, and they were kind of rescued after JetBrains decided to create CLion, which they took up to integrate into Android Studio, almost two years later. There were two reboots for new build system tools, until they decided to keep ndk-build around and settle with CMake as alternative. Even though the NDK APIs are written in C++ (or C++ wrappers over JNI calls), they are exposed as extern "C" to userspace, thus being more prone to unsafe coding pratices. Only now they are starting to think about supporting NDK package management, so far each Android NDK developer using AARs had to come up with in-house solutions to package NDK libraries across projects. Small rant, plenty of other stuff to complain about. However I would also like to add that the (apparently) small NDK team has improved the experience a lot, when comparing with what the Android 2.0 NDK state started from.

pjmlp 7y ago

The state of NDK is a good example. It appeared that the Android team was kind of forced to support C++ for game developers, and they did an half baked release with Android 2.0. Using headers and toolchains different than what regular Android (internal Google teams) were using, thus took them all the way up to release 14 to actually provide unified headers. Bionic wasn't fully ISO C compliant and has been being improved throughout all the NDK and Android releases. Back when they decided to drop Eclipse there wasn't a roadmap for C++ support going forward, and they were kind of rescued after JetBrains decided to create CLion, which they took up to integrate into Android Studio, almost two years later. There were two reboots for new build system tools, until they decided to keep ndk-build around and settle with CMake as alternative. Even though the NDK APIs are written in C++ (or C++ wrappers over JNI calls), they are exposed as extern "C" to userspace, thus being more prone to unsafe coding pratices. Only now they are starting to think about supporting NDK package management, so far each Android NDK developer using AARs had to come up with in-house solutions to package NDK libraries across projects. Small rant, plenty of other stuff to complain about. However I would also like to add that the (apparently) small NDK team has improved the experience a lot, when comparing with what the Android 2.0 NDK state started from.