|
|
|
|
|
by lnanek2
3642 days ago
|
|
Working at a company that ships an embedded Android product, I know Android sometimes costs us far more than it helps us. It took us months to figure out how to route some audio from incoming A2DP Sink Bluetooth profile to the speakers, for example. Fighting with patches, and Android app Java code, and Bluetooth app Java code, and JNI glue, and CPP Android services, and C Bluedroid stack. Meanwhile anyone on the team could have gotten it working in a day on Linux running BlueZ. Then we constantly have the same issues working with the display. We output ARGB for an augmented reality product, but Android is not designed to output anything but RGB to the final LCD. So similarly, if we were just dealing with a Linux frame buffer, we'd have had a much easier time doing the customization than fighting all of Android's various SurfaceFlinger and other layers between the app and the display. |
|
Maybe for your type of work it looks different, but from app developer perspective, they could replace the kernel with something totally different, keep the constrained set of official NDK libraries and no one would notice the kernel wasn't Linux any longer.