5 ms·

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 buil

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.

zozbot234 6y ago
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.
- enos_feedler 6y ago
  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!
  - quickthrower2 6y ago
    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.
    - enos_feedler 6y ago
      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.
- pjmlp 6y ago
  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.
  - enos_feedler 6y ago
    +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.
pjmlp 6y ago
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.
- jstimpfle 6y ago
  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)
  - pjmlp 6y ago
    You can pack it as PWA, https://whatwebcando.today/ https://whatwebcando.today/ https://whatpwacando.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-activity 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/ https://developer.microsoft.com/en-us/windows/pwa/ I expect the ongoing Edge Chrome efforts to eventually improve the TWA experience.
  - enos_feedler 6y ago
    WebGL/WASM sounds like a good approach to solve fragmentation. Things will get even better once WebGPU is supported as a Vulkan substitute.
    - pjmlp 6y ago

zozbot234 6y ago

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.

enos_feedler 6y ago
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!
- quickthrower2 6y ago
  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.
  - enos_feedler 6y ago
    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.
pjmlp 6y ago
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.
- enos_feedler 6y ago
  +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.

pjmlp 6y ago

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.

jstimpfle 6y ago
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)
- pjmlp 6y ago
  You can pack it as PWA, https://whatwebcando.today/ https://whatwebcando.today/ https://whatpwacando.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-activity 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/ https://developer.microsoft.com/en-us/windows/pwa/ I expect the ongoing Edge Chrome efforts to eventually improve the TWA experience.
- enos_feedler 6y ago
  WebGL/WASM sounds like a good approach to solve fragmentation. Things will get even better once WebGPU is supported as a Vulkan substitute.
  - pjmlp 6y ago