Hacker News Reader

Comment by matchbok | Hacker News Reader

The lack of quality control in the Android SDK is pretty impressive. It is by far the worst SDK I've ever used. Hell, even simple think like hiding/showing a keyboard requires a ton of code and checks. In 2020.

View on HN

It is out of control.

I actually think between the HAL layer, OEMs, chipsets and 3P ecosystem it is very difficult to dig out of the hole that Android has built. Too much was put into short term thinking on annual releases and gap closing with Apple. While Apple planned APIs years out for end to end products, Android had to blindly copy APIs and everything is far less elegant. Android isn't working. It isn't capturing the smartwatch ecosystem well (Fitbit) and it isn't capturing the TV ecosystem well (Roku).

The net impact is harmful to developers. We don't get the reach and compatibility we were promised. We have very fragmented ecosystem to develop for. We have specific device SDKs we have to use to tap into novel hardware. I can't complain enough.

Android had a huge opportunity to define the next evolution of compute platforms on top of the linux kernel and it has kind of blown it.

I think there are even signs Google leadership sees this and is investing in a portfolio of strategies such as CameraX, Pixel, Flutter/Fuschia.

With the Huawei situation too, I think the general health of the Android ecosystem is some of the worst it has been. Globally I think we are going to see even more fragmentation.

We need something that ties this all together. It's not going to be a full blown OS layer, but something to manage the madness for 3P devs.

I find so tragic that Android is worse than J2ME in regards to fragmentation, worse than Symbian/iOS/Windows/Maemo/Jolla in C++ support, at every Google IO we get the best practices rebooted.

Oboe and Vulkan are very good examples how clunky everything is.

Here we have two API that are supposed to be relevant for the platform (real time audio C++ framework) and next generation 3D API support, for which we get told to clone github repos, compile everything from scratch and do the integration with the applications ourselves.

Comparing this with iOS SDK and XCode templates is just feels like having to nuke it all.

I have been moving away from NDK to WebGL 2.0 / WebAssembly, as it is good enough for my interactive demos and Chrome team at least seems to be a bit more sane.

Exactly this. Imagine you are trying to build some kind of camera app that involves layering on effects or filters. You've got to have fine grain control over all the camera sensors, the gpus for rendering and compute, and potentially neural accelerators for some inferencing. How do you begin to do this on Android? Vulkan itself is hard enough. Now try adding Android NN API, and Camera 1/2/X with it's image processors. Now make it work across more than a single OEM hardware device. None of this is as simple as iOS side with a clean API that works together across GPU, NN and camera, in native code.

I've made some WebGL/WASM experiments, too - getting my UI and 3D to the browser. Any references for running this on Android smartphones? (I want to make an app, not a website)

You can pack it as PWA,

https://whatwebcando.today/

https://whatpwacando.today/

Or if you need more low level access to the host OS, as TWA,

https://developers.google.com/web/android/trusted-web-activi...

As sidenote, the TWA idea started originally at Microsoft, where packaged PWAs get access to Windows APIs without you having to write your own wrappers.

https://developer.microsoft.com/en-us/windows/pwa/

I expect the ongoing Edge Chrome efforts to eventually improve the TWA experience.

WebGL/WASM sounds like a good approach to solve fragmentation. Things will get even better once WebGPU is supported as a Vulkan substitute.

The irony of WebGPU, is that we will be able to get it via Chrome and frameworks like BabylonJS, while the Android team is not willing to provide something similar to Java/Kotlin devs.

Sceneform seems to be dead, and Filament is nothing more than a tech demo.

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.

I use mostly the NDK, and as incredible as it may sound, I occasionally do miss Symbian even with its clunky Symbian C++.

At least Symbian had a proper C++ API, not a bunch of C wrappers to Java and C++ code, expecting everyone to write their own wrappers and cloning half maintained github repos released by someone on the Android team.

> even simple think like hiding/showing a keyboard requires a ton of code and checks

To be fair, I have had the same experience while doing iOS development.

I think Android SDK was made with something else in mind, I did read it was made for digital cameras, ironically Android have very bad camera api too, the concept of activity and fragment is just weird... I can say everything there is weird, but definitely not the worst SDK.

You're right. It was never designed as a mobile OS with a soft keyboard. Hell, it's 2020 and rotating the device still doesn't work as it should.

> rotating the device still doesn't work as it should.

What exactly is the issue?! Been using Android for about a decade now and can rotate the device just fine.

Yeah so it works, but from a developer perspective it's about 10x more complicated than iOS. It's also a source of bugs and crashes because of how Android manages the state change.

Rotating the phone restarts the app and it is the developer's job to restore it somehow.

For me, a lot of apps lose various state, e.g. text written in input fields, when rotating.

No wonder, rotating the phone restarts the app and it is the developer's job to restore it somehow.

I've heard there will finally be an api for keyboard state change.. not sure if that's added to the upcoming android version

Reply on news.ycombinator.com