4 ms·

No. Google is the operating system vendor. They either fix this with all Android phones or they haven't fixed anything at all.

by mdoms 4y ago

Andrex 4y ago
They've been at it for years, but it's been a difficult problem to solve. Tangible progress has been made in the last 2 or so OS updates, however. https://arstechnica.com/gadgets/2018/06/talkin-treble-how-android-engineers-are-winning-the-war-on-fragmentation/ https://arstechnica.com/gadgets/2018/06/talkin-treble-how-an... https://arstechnica.com/gadgets/2020/12/qualcomm-promises-three-years-of-android-updates-for-its-entire-soc-lineup/ https://arstechnica.com/gadgets/2020/12/qualcomm-promises-th... https://arstechnica.com/gadgets/2020/07/android-10-has-the-fastest-update-rate-ever-hits-16-of-users-in-10-months/ https://arstechnica.com/gadgets/2020/07/android-10-has-the-f...
vetinari 4y ago
Google is not operating system vendor for all Android phones. They release a generic template, other vendors then apply platform kits for the SoCs they use and they release the operating system for their devices. Google has no idea what it runs on, or what is needed to make it run on specific devices. It is the vendor's task. Mobile devices have no UEFI, no bus enumeration, so the OS image has to be taylored for each device. It is similar to Raspberry or Odroid or similar SBCs: althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another.
- jiggawatts 4y ago
  That’s the cause of the problem, not the excuse for it.
- my123 4y ago
  (disclaimer: I work at Qualcomm) > Mobile devices have no UEFI Since the Snapdragon 835, Android devices with Qualcomm processors use UEFI all the way to the kernel. However, custom UEFI binaries aren't part of the boot flow, with an Android UEFI boot application running instead. > no bus enumeration It's device tree instead of ACPI, but apart from that the situation isn't _that_ different from PCs today. We aren't in the ATAGS era anymore. The reflashing interface nowadays is standardised through fastboot too. > so the OS image has to be taylored for each device Thankfully a lot of progress has been done on that. Since Treble, the BSP proper has been untied from Android releases. Since devices shipping with Android 12, a Google-built kernel with a stable kernel module ABI has been shipping (for a given major kernel + Android version release combo). This allows kernel security updates to be identical across the whole ecosystem. > althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another That used to be true, but across the whole Android device fleet (even between SoC vendors) it's not true anymore. However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. More info on generic system images: https://developer.android.com/topic/generic-system-image https://developer.android.com/topic/generic-system-image. This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so.
  - danielEM 4y ago
    Hey @my123 > However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. > This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so. So assuming my bootloader is unlocked, have a GSI compliant phone, what is the remaining work I would need to have done in order to get it working under linux (and by working I mean all devices - including cameras and etc)?
    - my123 4y ago
      > what is the remaining work I would need to have done in order to get it working under A good chunk of the Linux community on phones didn't want to have to rely on binary drivers for non-technical reasons, and that's one of the reasons why it isn't exactly well taken care of today. For Ubuntu Touch specifically: https://docs.ubports.com/en/latest/porting/introduction/Intro.html https://docs.ubports.com/en/latest/porting/introduction/Intr... for Ubuntu Touch. https://github.com/ubports/porting-notes/wiki/Generic-System-image-(GSI) https://github.com/ubports/porting-notes/wiki/Generic-System... An upgraded Halium (https://github.com/Halium https://github.com/Halium) image on a can work unmodified across the whole ecosystem of Android devices. However, the latest currently developed experimental Halium works on an Android 11 base at most, so that devices launched with Android 12 might be using drivers too new for it at this point in time. (https://gitlab.com/ubports/community-ports/jenkins-ci/generic_arm64/-/pipelines https://gitlab.com/ubports/community-ports/jenkins-ci/generi...) This can be fixed with an engineering effort to do so to make it work on devices launched with Android 12. The Linux on phones community is very small and that causes problems in this case. Together with the unified kernel image (GKIs) on Android 12 which allows to have kernel image binaries built with GNU/Linux-specific features that work across the whole fleet, a full straightforward experience can be made possible. This would fill the last chunk of custom per-device bits. I wonder how big the audience would be for such a project though. :)

No. Google is the operating system vendor. They either fix this with all Android phones or they haven't fixed anything at all.

by mdoms 4y ago

No. Google is the operating system vendor. They either fix this with all Android phones or they haven't fixed anything at all.

Andrex 4y ago

They've been at it for years, but it's been a difficult problem to solve. Tangible progress has been made in the last 2 or so OS updates, however. https://arstechnica.com/gadgets/2018/06/talkin-treble-how-android-engineers-are-winning-the-war-on-fragmentation/ https://arstechnica.com/gadgets/2018/06/talkin-treble-how-an... https://arstechnica.com/gadgets/2020/12/qualcomm-promises-three-years-of-android-updates-for-its-entire-soc-lineup/ https://arstechnica.com/gadgets/2020/12/qualcomm-promises-th... https://arstechnica.com/gadgets/2020/07/android-10-has-the-fastest-update-rate-ever-hits-16-of-users-in-10-months/ https://arstechnica.com/gadgets/2020/07/android-10-has-the-f...

vetinari 4y ago

Google is not operating system vendor for all Android phones. They release a generic template, other vendors then apply platform kits for the SoCs they use and they release the operating system for their devices. Google has no idea what it runs on, or what is needed to make it run on specific devices. It is the vendor's task. Mobile devices have no UEFI, no bus enumeration, so the OS image has to be taylored for each device. It is similar to Raspberry or Odroid or similar SBCs: althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another.

jiggawatts 4y ago
That’s the cause of the problem, not the excuse for it.
my123 4y ago
(disclaimer: I work at Qualcomm) > Mobile devices have no UEFI Since the Snapdragon 835, Android devices with Qualcomm processors use UEFI all the way to the kernel. However, custom UEFI binaries aren't part of the boot flow, with an Android UEFI boot application running instead. > no bus enumeration It's device tree instead of ACPI, but apart from that the situation isn't _that_ different from PCs today. We aren't in the ATAGS era anymore. The reflashing interface nowadays is standardised through fastboot too. > so the OS image has to be taylored for each device Thankfully a lot of progress has been done on that. Since Treble, the BSP proper has been untied from Android releases. Since devices shipping with Android 12, a Google-built kernel with a stable kernel module ABI has been shipping (for a given major kernel + Android version release combo). This allows kernel security updates to be identical across the whole ecosystem. > althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another That used to be true, but across the whole Android device fleet (even between SoC vendors) it's not true anymore. However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. More info on generic system images: https://developer.android.com/topic/generic-system-image https://developer.android.com/topic/generic-system-image. This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so.
- danielEM 4y ago
  Hey @my123 > However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. > This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so. So assuming my bootloader is unlocked, have a GSI compliant phone, what is the remaining work I would need to have done in order to get it working under linux (and by working I mean all devices - including cameras and etc)?
  - my123 4y ago
    > what is the remaining work I would need to have done in order to get it working under A good chunk of the Linux community on phones didn't want to have to rely on binary drivers for non-technical reasons, and that's one of the reasons why it isn't exactly well taken care of today. For Ubuntu Touch specifically: https://docs.ubports.com/en/latest/porting/introduction/Intro.html https://docs.ubports.com/en/latest/porting/introduction/Intr... for Ubuntu Touch. https://github.com/ubports/porting-notes/wiki/Generic-System-image-(GSI) https://github.com/ubports/porting-notes/wiki/Generic-System... An upgraded Halium (https://github.com/Halium https://github.com/Halium) image on a can work unmodified across the whole ecosystem of Android devices. However, the latest currently developed experimental Halium works on an Android 11 base at most, so that devices launched with Android 12 might be using drivers too new for it at this point in time. (https://gitlab.com/ubports/community-ports/jenkins-ci/generic_arm64/-/pipelines https://gitlab.com/ubports/community-ports/jenkins-ci/generi...) This can be fixed with an engineering effort to do so to make it work on devices launched with Android 12. The Linux on phones community is very small and that causes problems in this case. Together with the unified kernel image (GKIs) on Android 12 which allows to have kernel image binaries built with GNU/Linux-specific features that work across the whole fleet, a full straightforward experience can be made possible. This would fill the last chunk of custom per-device bits. I wonder how big the audience would be for such a project though. :)