3 ms·

If Google makes it easier for manufacturers to make phones that can be updated OTA by Google than phones that can not (custom Android builds) most of them would

If Google makes it easier for manufacturers to make phones that can be updated OTA by Google than phones that can not (custom Android builds) most of them would probably do so. Have a hardware layer, an Android system layer, an OEM layer, and have a clear interface between them so they can be updated independently. Then Google should push updates themselves, they can't leave that to phone manufacturers or carriers, like you said, there's no incentives for them to do so. Of course, this has been an issue for Android since day one, so I wont hold my breath. Are there any work done on a system similar to the one on PC, where software can enumerate available hardware? We have advanced computers in our pockets, but they can't be updated to a new OS version as easy as a 15 year old PC. It's ridiculous.

0xFFC 9y ago
I am more optimistic than you two, i think for mide range and high range devices, there is incentive: competition. But i have to agree, for low end devices, even from famous companies i dont think they will update their phone even with this.
izacus 9y ago
But "ease" isn't the problem - the issues OEMs have are because they literally go hack and fork the AOSP source itself (making upstream merges hard or impossible) for sometimes really dumb reasons. This is also the source of constant headaches for us app developers (like the recent case where Realm found out that Samsung broke memmove() on their devices!). The other issue is that there's zero (0, no) incentive to update the devices. No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated. For each of the (literaly!) 100 devices they churn out per year they need to get new drivers from the SoC manufaturer (and Qualcomm pretty much does not give a crap about SoCs of the previous year, especially lower end ones - which makes this process stop there), update the kernel and move all their specific hacks to it. I don't see how these changes Google did will change incentives. The only way we might see a change in this field is by a few class action suites from users being left without updates or regulators putting down the punitive damages hammer. Everything else is just Google kindly hoping OEMs will stop being dicks from the goodness of their heart. In car industry we have strong regulation which demands that your car is serviceable at least 5 years since last unit was sold (and that their security issues are fixed by recalls). We need that for arguably the most important electronic devices in our lives as well.
- throwaway47861 9y ago
  You pretty much made the entire thread superfluous. Very well articulated and I fully agree, the suits don't care if you reduce their expense if they can skip the expense whatsoever.
- dragonwriter 9y ago
  > No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated Treble removes much of the cause for forking, and removes the cost for OEMs that follow it's design.
- ViViDboarder 9y ago
  Google can leverage a lot of control using Play Services. If, as gp suggests, they also create an OEM layer so the OEM doesn't have to fork Android and instead just builds on top of safe APIs, allowing Google to take over updates entirely, then Google can force OEMs to use it.
chiefalchemist 9y ago
This is a bit above my pay grade so forgive me if I'm way off target but... To some extent doesn't this make a case for (say) HTML# and browser based apps? That is the browser is a known sandbox of sorts. It's interface with the device (e.g., Phone app) is a known, and fixed. It has no care about what's on the other side of that wall. And the device OS more or less exists to run and support the browser. But when the applications interface directly with the device, and there are countless device and OS, etc. combos there will always be a mess. Too many variables. Too many chefs in the kitchen if you will. I realize I probably oversimplified. (Sorry.) I'm also outside my knowledge sweet spot, but am curious enough to want to learn. Please don't hurt me. Thank you.
- CyberDildonics 9y ago
  It absolutely does. If webasm works out this is how I see things going. Android is already running things through a JIT. I don't think users want dozens of apps installed on their phone, each with the possibility to be using up bandwidth, hogging resources, stalling programs and draining battery life, not to mention abusing permissions. If most apps can be done with webasm (and I don't see why the majority of apps can't be) then the only things that need to run in a more native context would be apps that use special features.
  - pjmlp 9y ago
    It also does AOT compilation with PGO gathered from the JIT. Unless the browsers offer APIs at the same feature level as native OS APIs, web applications will always be a second class experience.
    - CyberDildonics 9y ago
      Only for apps that need those native features.
      - pjmlp 9y ago
        Which means any app that respects its users by providing a suitable UI/UX using the best features of the OS running on the device they paid for.

0xFFC 9y ago

I am more optimistic than you two, i think for mide range and high range devices, there is incentive: competition. But i have to agree, for low end devices, even from famous companies i dont think they will update their phone even with this.

izacus 9y ago

But "ease" isn't the problem - the issues OEMs have are because they literally go hack and fork the AOSP source itself (making upstream merges hard or impossible) for sometimes really dumb reasons. This is also the source of constant headaches for us app developers (like the recent case where Realm found out that Samsung broke memmove() on their devices!). The other issue is that there's zero (0, no) incentive to update the devices. No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated. For each of the (literaly!) 100 devices they churn out per year they need to get new drivers from the SoC manufaturer (and Qualcomm pretty much does not give a crap about SoCs of the previous year, especially lower end ones - which makes this process stop there), update the kernel and move all their specific hacks to it. I don't see how these changes Google did will change incentives. The only way we might see a change in this field is by a few class action suites from users being left without updates or regulators putting down the punitive damages hammer. Everything else is just Google kindly hoping OEMs will stop being dicks from the goodness of their heart. In car industry we have strong regulation which demands that your car is serviceable at least 5 years since last unit was sold (and that their security issues are fixed by recalls). We need that for arguably the most important electronic devices in our lives as well.

throwaway47861 9y ago
You pretty much made the entire thread superfluous. Very well articulated and I fully agree, the suits don't care if you reduce their expense if they can skip the expense whatsoever.
dragonwriter 9y ago
> No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated Treble removes much of the cause for forking, and removes the cost for OEMs that follow it's design.
ViViDboarder 9y ago
Google can leverage a lot of control using Play Services. If, as gp suggests, they also create an OEM layer so the OEM doesn't have to fork Android and instead just builds on top of safe APIs, allowing Google to take over updates entirely, then Google can force OEMs to use it.

chiefalchemist 9y ago

This is a bit above my pay grade so forgive me if I'm way off target but... To some extent doesn't this make a case for (say) HTML# and browser based apps? That is the browser is a known sandbox of sorts. It's interface with the device (e.g., Phone app) is a known, and fixed. It has no care about what's on the other side of that wall. And the device OS more or less exists to run and support the browser. But when the applications interface directly with the device, and there are countless device and OS, etc. combos there will always be a mess. Too many variables. Too many chefs in the kitchen if you will. I realize I probably oversimplified. (Sorry.) I'm also outside my knowledge sweet spot, but am curious enough to want to learn. Please don't hurt me. Thank you.

CyberDildonics 9y ago
It absolutely does. If webasm works out this is how I see things going. Android is already running things through a JIT. I don't think users want dozens of apps installed on their phone, each with the possibility to be using up bandwidth, hogging resources, stalling programs and draining battery life, not to mention abusing permissions. If most apps can be done with webasm (and I don't see why the majority of apps can't be) then the only things that need to run in a more native context would be apps that use special features.
- pjmlp 9y ago
  It also does AOT compilation with PGO gathered from the JIT. Unless the browsers offer APIs at the same feature level as native OS APIs, web applications will always be a second class experience.
  - CyberDildonics 9y ago
    Only for apps that need those native features.
    - pjmlp 9y ago
      Which means any app that respects its users by providing a suitable UI/UX using the best features of the OS running on the device they paid for.