• Development

  • How much has Treble and the like eased upgrades for GOS?

Over recent years AOSP has tried to increasingly abstract the hardware/firmware away from OS, such as Project Treble in order to make updating the OS version easier.

I had thought with newer initiatives such as Generic System Images (GSIs) and General Kernel Images (GKIs) we'd now be at a stage where updating a phone to the latest Android can be done within a week.

I understand that a big part of the delay is that OS developers need to check their own custom apps and system changes work on the new version. I was wondering if we could get an estimated breakdown of how much time is allocated to what particular aspect of upgrade work.

Is there say two weeks for testing GOS-specific apps, and two for system changes? Is there another three allocated to creating new tests?, etc. I'm basically trying to get a gauge on how difficult it is for OS developers to upgrade versions, what are the exact issues they face and if there are ways that AOSP can be further improved to aid this.

GKI has meant we ship a newer kernel than even Google on 6th generation Pixel devices, meaning we are closing the patch gap drastically for those devices, but that's not relevant to major version migrations. We use the upstream AOSP tags and the content present in the stock OS (userspace libraries, firmware etc). We have to use the same AOSP tags as the stock OS otherwise things will break and we run the risk of missing or being unable to apply security patches fully. GSI's aren't relevant to us.

The key delay when it comes to a major Android version move stems from us only getting source code on the day the AOSP tags go public. So we have a very small window of time to port all our OS level features over. Whilst we have always ported it over within days of the tags being public, it's a huge strain on the team due to the amount of rapid development effort which is required. Ideally we would be getting AOSP source code early, before it's released to the public, so we could begin porting now, months before the public release. This would mean we avoid running into any pain in life and would drastically reduce our workload. As for time scales, it might take 1-2 days to port devices fully over and a few more days to port OS level changes. Google publishes the beta Linux kernels publicly for upcoming Android versions, so we are currently porting changes to that in order to save time, as usually they are quite similar or even the same kernels deployed when the tags are publicly released.

    flawedworld thanks for the info, I'm glad at least the GKI aspect has helped speed things up. In those 1-2 days to port devices fully over, what kind of tasks are involved? I had thought the devices themselves are mostly abstracted away by all these AOSP changes.

    The few more days to port OS level changes on the other hand makes sense to me, what with all the different customisations that GOS makes.

      AOSP has first class support for Pixel phones, but it's incomplete, and we use the adevtool project to extract libraries/firmware etc which aren't buildable by AOSP from the stock OS. We need to redo the rules and configurations we use for this every major version at least.