Extending the Android SDK
android-developers.googleblog.com
android-developers.googleblog.com
Google has been introducing this at multiple levels, resulting in much more secure android devices.
Instead of doing one big system update the way Apple does, they can update small parts of the system which results in much faster updates.
It wouldn't be such a problem, but some posters have extremely poor relation with reality and truth.
This is part of their solution at the app developer level, and has evolves from previous SDK layers that provided compatibility for older OS versions.
At the OS level, Android has been modularized to take parts of the OS out of OEMs' hands to enable Google to add and update features with OEMs' intervention.
OEMs can still opt out from all of this and do as they please with the Android Open Source Project (AOSP). Amazon isn't constrained by Google for their Fire OS, for example, other than by competitive imperatives. It is aimed more at Samsung and other OEMs who have modified Android to make their products distinctive in some ways that make life difficult for Google when Google wants to propagate new Android features into the installed base.
Partly due to their own early decisions (that are difficult to second guess) Google has always had a much more difficult time making Android a consistent end user experience than Apple. It has harmed Android adoption. Google has put in a lot of effort, more or less effectively, in multiple dimensions, to fix that.
I feel like this has to be the seventh or eighth time Google has implemented an entirely new mechanism around their inability to update their own operating system. Heck, most of Play Services originally happened as an attempt to hack around it.
The problem is inevitably the one thing you decided you can't update this way always becomes the blocker for what you need to do.
The "blame and shame the manufacturers" strategy only gets you so far. Google can, effectively, dictate terms to Android OEMs: They have no competing OSes they can start shipping instead, Android is a complete monopoly. Google's not afraid to use this monopoly to do blatantly illegal things like requiring Google Search and Chrome... but they want us to believe they're incapable of requiring control of system updates?
I suspect the problem is that when Windows updates break compatibility, the Windows team has to fix it, and when Android updates break compatibility, they'd much rather the OEM be on the hook for the time and money needed to fix it.
So in fairness, other bottom-of-the-bin complete garbage platforms do also have this problem - there are loads of little embedded boards running around with barely enough hardware to run the hacked up out of tree kernel that they're using. Now to my knowledge, none of those are major platforms pretending to be a real system that people can build on and selling literally $1,000+ phones that still has the same horrible problems at the deepest layers. But it does happen in the cheap junk.
No, it absolutely isn't. Linus also can't push updates to your Linux computer but it has to wait for distributions to pick up the changes and distribute them. Same as Google has to wait for OEMs.
Don't make stuff up.
Google also got fined in both EU and India for forcing OEMs into doing things with Android, so the governments and law themselves do not allow them to force updates.
Google's Android is not Samsung's Android, nor is it OnePlus' Android. They are all forks of the "original" AOSP Android and should be treated as such. Google requires some compatibility for inclusion of their Play services and has used AOSP to build in the core to achieve this, but it includes only very specific parts of the operating system.
Google Play is an application package that's added to another operating system, and an optional one at that. Huawei is still selling phones without GPlay and people are still buying those, even outside China.
There are phones for which your arrangement actually works: the Android One programme has Google set up everything but the drivers and associated libraries for vendors, who can then push updates to end users almost directly from Google.
If you want to get quick updates from Google, vote with your wallet and buy an Android One phone. Most manufacturers prefer to have control over their own stack so they can add distinguishing features to their products, plus there are obviously fees for the OS involved, so the price may be higher for some Android One phones compared to the other products, but you do usually get the updates in the way you describe.
At the end of the day, though, the average end user doesn't care about Android One. The option is still out there if you care.
Since Google rules the OHA (Open Handset Alliance) with an iron fist, there's no way on earth an OEM can brand its devices "Android" without Google's blessing (read: installing Google Apps in the /system partition which no user can get rid without unlocking the bootloader). And more and more of the open source parts of AOSP have been left to rot, in favour of "Pixel-only" apps. How many years has it been since JBQ quit AOSP in protest? And what has changed?
> If you want to get quick updates from Google, vote with your wallet and buy an Android One phone.
Those who voted with their wallets, got into a program which Google all but abandoned. Some OEMs like Nokia (HMD Global), Motorola (Lenovo), and ASUS continue to ship seemingly unbloated Androids (but not as part of Android One). But credit where due: GKI (Android Common Kernels), Treble, APEX, pKVM (microdroid), TEE OS will pay dividends in the coming decade, essentially superseding programs like Android One.
https://source.android.com/docs/core/ota/modular-system
Of course, they could require by contract OEMs to provide updates, like they do for other Google based services.
(Google does a lot of creepy stuff, but HN should also give them credit when they do great things)
I don't see the problem here. As a developer you can implement support for older versions yourself if you want to, all you need to do is write stubs for every API and platform feature to mske them work somewhat consistently on older platforms. I don't see why you'd waste the time if Google has already done so for your, but you can.
I've yet to see anyone belittle that like you did.
Not about version support.
1. Control on top of the Open Source OS. 2. Hollowing out the OS so that OEMs/carriers have reduced controls over updates/lifecycles, etc.
1 is bad, 2 is arguably good.
Realistically, it feels like it will necessarily introduce fence posts in the upgrade cycle such that you either don't even try and run older things, or rely on something like emulation.
My dream would be that we do the emulation route. My expectation is that we just leave the old. :(
You can't just upgrade libraries willy nilly on Android devices for good reason. First it all, Google has no way to know what versions of what libraries are actually modified by the vendor or requires by vendor software. Second, the system image is read only for security and stability reasons, just like it is on many other consumer facing Linux devices. Lastly, these modular upgrades have already been implemented for years for a select subset of the Android API that can safely be updated without causing conflicts.
Having Google update a library on a Samsung phone is like installing an Arch package on Ubuntu. In theory it'll work out fine it's just a newer version, right? In practice you have no idea what's about to happen to the stability of your system.
There's a reason Linux software is actually moving towards the Android way of doing things, packaging all of its dependencies by itself into Flatpaks or AppImages or even Snaps. Externally updated code causes issues across the board, especially in a fragmented space like Linux or Android distributions.
I.e. if WhatsApp wants to use the camera, instead of building its own camera component, could it just invoke the platform camera?
The Samsung camera app has a ton of nice features and instead WhatsApp, Telegram & co just their garbage generic camera apps.
Larger Companies opt for the latter and make a own camera UI to take full control of the experience (and to be able to add features like filters etc)
Google has a project for developers to help unify the experiences across different apps, but it is up to the developer whether he makes use of it or not [1]
Something where you say: open up the default camera app on the system and give me a stack of pixels at the end.
Hopefully the CameraX thing you linked can be used as a base for all Android camera apps.
https://developer.android.com/training/camera/camera-intents
This is the "I want the default camera app to take the photo for me, and I just want my app to be given an image afterwards" approach.
Telegram, WhatsApp, Signal, Google Messages (!!!) don't use this API.
Messenger Lite does, as do Google Keep and Amazon Chime (!!!).
Android doing Android things ¯\_(ツ)_/¯
That's a perfectly valid choice.
App developers of that size have the resources to make their own camera UI, and produce the experience they want to.
Many major apps make their own camera UI, because it allows them to make a bespoke experience that actually feels like something that's part of their own app.
There's always the option to use the standard camera app, but that will feel jarring to most people, as it's just not how the most popular social media apps work.
Yes, the vendors are directly to blame, but this stuff should be enforced.
The main apps I use, WhatsApp and Telegram, don't use it. So for 95% of my use cases, it doesn't exist :-(
Google should crack down more on apps.
Crack down on what?
You seem to seriously misunderstand the situation.
There are two options for an app to take a photo:
1) Using the Camera Intent
2) A custom-designed UI that uses the Camera/Camera2/CameraX APIs
There is no one valid option - both are appropriate to use in different cases, and each has upsides and downsides.
It's generally going to be the case that both developers and users will see option #2 as the better experience - despite what you might think.
The smartphone has a bunch of cameras. They can zoom to different levels. They can use AI to do stuff like auto-detect documents and turn on a very smart document scanning mode.
Then I open up Telegram or WhatsApp and I'm greeted with a barebones camera app that can't really even zoom.
How is that a good user experience?!? In what world?
In the world of Telegram and WhatsApp, where the own vision and strategy of their camera user experience are valued higher than handing off the task of image-taking to the default camera application.
Really, the decision is in the hands of the App developer, the Android platform is offering both paths.
The idea is that CameraX combines a bit of both worlds, with vendors like Samsung integrating features there and App-Developers using this toolbox instead of directly calling the API of the camera hardware.