24 ms·

Extending the Android SDK

57 points by lawgimenez 4y ago

greatjack613 4y ago
"How to update an os without updating the os itself". Personally I see this model extending to other things as well, the idea that each part of the os is a "package" with a specified interface and that you can replace that package at any time as long you comply with that interface is a very powerful concept. I see this going a lot further then just sdk improvements in the future.
- taeric 4y ago
  I feel like this will work right up til it doesn't. 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. :(
- yjftsjthsd-h 4y ago
  Yeah, give it another decade and perhaps they'll reinvent Linux distros with the ability to upgrade libraries separately from the kernel. (Seriously, though; their examples look a lot like "we figured out how to ship an ad library and xdg-desktop-portal-gtk without upgrading your kernel+libc!")
  - pjmlp 4y ago
    They already did that, and that is what this buids on, say hi to "Modular System Components": https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system
  - jeroenhd 4y ago
    With the competition not being able to update its web browser without a full system upgrade, I'd say Android is actually ahead in this respect. 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.
ocdtrekkie 4y ago
Ah, the subtle art of submarining a spyware feature into an existing OS release. lol. 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.
- deleted 4y ago
  [deleted]
- awill 4y ago
  Rather than yet another workaround for not being able to update devices, I wish they would just solve the actual problem. For updates. Google should be able to do that without changing drivers/kernel. Similar to how Microsoft does it with Windows.
  - ocdtrekkie 4y ago
    Yeah, Google is absolutely unique at this point in building an OS they can't actually update, and placing the blame for it on hardware manufacturers instead. Nobody else has this problem. Including ARM-based platforms. 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.
    - yjftsjthsd-h 4y ago
      > Nobody else has this problem. Including ARM-based platforms. 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.
kramerger 4y ago
I don't understand the negativity here. 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.
- izacus 4y ago
  This site looks to be run over people just wanting to rant at something no matter the topic. It happens in all other topics as well, Google, Apple, you name it. It wouldn't be such a problem, but some posters have extremely poor relation with reality and truth.
- MrDresden 4y ago
  I think this is just the pent up and justified resentment over short support lifecycles in the Android community historically, lashing out.
- pjmlp 4y ago
  The negativity is that Google has the legal means to enforce updates like in any other OS, and which they do as means to access key Android services, and yet decided not to do it.
oblio 4y ago
Semi random question: does Android have a camera API already? 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.
- rickdeckard 4y ago
  Of course Android has a camera API. It is up to the App-Developer if he wants to trigger the default camera application and get a picture returned by it, or talk directly to the camera within the app (using the Android Camera APIs). 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] [1] https://developer.android.com/training/camerax https://developer.android.com/training/camerax
  - oblio 4y ago
    I mean an actual API. 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.
    - daveoc64 4y ago
      Yes. That's what a Camera Intent would do: https://developer.android.com/training/camera/camera-intents 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.
      - oblio 4y ago
        Let's hope Samsung (and all the other Android phone manufacturers) adopt this by 2050 :-)
Zigurd 4y ago
Since Android was first adopted and modified by OEMs, Google has had a problem with keeping the end user experience consistent and up to date. 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.
- Zigurd 4y ago
  I just noticed the above may be confusing. I wrote "with OEMs' intervention" when I meant "without OEMs' intervention."

57 points by lawgimenez 4y ago

"How to update an os without updating the os itself". Personally I see this model extending to other things as well, the idea that each part of the os is a "package" with a specified interface and that you can replace that package at any time as long you comply with that interface is a very powerful concept. I see this going a lot further then just sdk improvements in the future.

taeric 4y ago
I feel like this will work right up til it doesn't. 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. :(
yjftsjthsd-h 4y ago
Yeah, give it another decade and perhaps they'll reinvent Linux distros with the ability to upgrade libraries separately from the kernel. (Seriously, though; their examples look a lot like "we figured out how to ship an ad library and xdg-desktop-portal-gtk without upgrading your kernel+libc!")
- pjmlp 4y ago
  They already did that, and that is what this buids on, say hi to "Modular System Components": https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system
- jeroenhd 4y ago
  With the competition not being able to update its web browser without a full system upgrade, I'd say Android is actually ahead in this respect. 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.

ocdtrekkie 4y ago

Ah, the subtle art of submarining a spyware feature into an existing OS release. lol. 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.

deleted 4y ago
[deleted]
awill 4y ago
Rather than yet another workaround for not being able to update devices, I wish they would just solve the actual problem. For updates. Google should be able to do that without changing drivers/kernel. Similar to how Microsoft does it with Windows.
- ocdtrekkie 4y ago
  Yeah, Google is absolutely unique at this point in building an OS they can't actually update, and placing the blame for it on hardware manufacturers instead. Nobody else has this problem. Including ARM-based platforms. 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.
  - yjftsjthsd-h 4y ago
    > Nobody else has this problem. Including ARM-based platforms. 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.

kramerger 4y ago

I don't understand the negativity here. 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.

izacus 4y ago
This site looks to be run over people just wanting to rant at something no matter the topic. It happens in all other topics as well, Google, Apple, you name it. It wouldn't be such a problem, but some posters have extremely poor relation with reality and truth.
MrDresden 4y ago
I think this is just the pent up and justified resentment over short support lifecycles in the Android community historically, lashing out.
pjmlp 4y ago
The negativity is that Google has the legal means to enforce updates like in any other OS, and which they do as means to access key Android services, and yet decided not to do it.

oblio 4y ago

Semi random question: does Android have a camera API already? 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.

rickdeckard 4y ago
Of course Android has a camera API. It is up to the App-Developer if he wants to trigger the default camera application and get a picture returned by it, or talk directly to the camera within the app (using the Android Camera APIs). 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] [1] https://developer.android.com/training/camerax https://developer.android.com/training/camerax
- oblio 4y ago
  I mean an actual API. 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.
  - daveoc64 4y ago
    Yes. That's what a Camera Intent would do: https://developer.android.com/training/camera/camera-intents 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.
    - oblio 4y ago
      Let's hope Samsung (and all the other Android phone manufacturers) adopt this by 2050 :-)

Zigurd 4y ago

Since Android was first adopted and modified by OEMs, Google has had a problem with keeping the end user experience consistent and up to date. 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.

Zigurd 4y ago
I just noticed the above may be confusing. I wrote "with OEMs' intervention" when I meant "without OEMs' intervention."