[georgemcbay]

The Android camera issues you reference reached all the way up to the higher level Java APIs, at least back when I was doing Android development from 2012 until about a year ago. Dunno if it has gotten any better since then.

All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app.

This is kind of a theme in Android (or was... my experience is slightly out of date right now).

As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression.

Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.

[pjmlp]

It still is the same theme.

For Vulkan and real time audio they expect you to checkout GitHub repos and compile from scratch, instead of having the tooling as part of the NDK.

Likewise after 10 years they still expect everyone to manually write JNI bindings, instead of providing another productive way for language interop.

[allo37]

Well, glad to hear it's consistent at least :) Good news is we got a handle on all the little issues and now our code runs well on a wide selection of devices, but yeah, next time around I'd find a library that handles all the gory details.

I find image manipulation works pretty well, though I've only been doing Android dev for 2 years so maybe it's improved. Or I just haven't done anything 'fun' yet...