Related
Is anyone working on porting project treble? I would think it would make rom building much easier if this was achieved.
mattlowry said:
Is anyone working on porting project treble? I would think it would make rom building much easier if this was achieved.
Click to expand...
Click to collapse
It wouldn't make much difference per what @invisiblek and @npjohnson stated. We could put the vendor blobs on it's own partition, but it wouldn't make building any easier as we still have to get the blobs. ROMs are already working minus gapps install, LTE for Sprint, selinux rules, and audio recording (camcorder, Skype, VoIP calls on soft phones, etc). There might be smaller issues I don't notice personally.
Uzephi said:
It wouldn't make much difference per what @invisiblek and @npjohnson stated. We could put the vendor blobs on it's own partition, but it wouldn't make building any easier as we still have to get the blobs. ROMs are already working minus gapps install, LTE for Sprint, selinux rules, and audio recording (camcorder, Skype, VoIP calls on soft phones, etc). There might be smaller issues I don't notice personally.
Click to expand...
Click to collapse
Ok I was just doing a bunch of reading on the topic and it appeared that there were generic images that could be flashed when you have treble
mattlowry said:
Ok I was just doing a bunch of reading on the topic and it appeared that there were generic images that could be flashed when you have treble
Click to expand...
Click to collapse
Generic images won't have motomods support. Right now, the greybus driver is built in-line with the kernel and sits in the boot image which would change with a generic image.
Uzephi said:
Generic images won't have motomods support. Right now, the greybus driver is built in-line with the kernel and sits in the boot image which would change with a generic image.
Click to expand...
Click to collapse
No one cares about Moto mods ?
mattlowry said:
No one cares about Moto mods ?
Click to expand...
Click to collapse
? yeah, if only. I get hounded because my AOSP kernel doesn't support motomods due to me building with linaro still and it causes issues with the build of the greybus drivet
if we use the oem partition and created a GSI for the Moto z family then treble could be usable with moto mods built in with the standard gcc toolchain google used, correct me if im mistaken but i think they are still on 4.8. Anyway treble can mean really big thing i bricked my AT&T moto z2 trying to exploit it to gain root (epic fail on to the tmobile unit that works now) on it and have since replaced and started looking into treble as the custom roms i was building had a GSI, so i then wanted to focus on getting a treble system up and running on my z2 force and will post once i have better progress and a repeatable process.
Kaesberg said:
if we use the oem partition and created a GSI for the Moto z family then treble could be usable with moto mods built in with the standard gcc toolchain google used, correct me if im mistaken but i think they are still on 4.8. Anyway treble can mean really big thing i bricked my AT&T moto z2 trying to exploit it to gain root (epic fail on to the tmobile unit that works now) on it and have since replaced and started looking into treble as the custom roms i was building had a GSI, so i then wanted to focus on getting a treble system up and running on my z2 force and will post once i have better progress and a repeatable process.
Click to expand...
Click to collapse
It all would work except for one thing. Motomods. That is in system and kernel. Both are not in the treble images.
Uzephi said:
It all would work except for one thing. Motomods. That is in system and kernel. Both are not in the treble images.
Click to expand...
Click to collapse
sweet so when i rebuild a GSI if it is made to include the files in the image, and maybe a extra zip for a kernel to go with it? i want to build a GSI ROM i can install on the whole Z family, and it sounds like it may need to have an extra package to install after the GSI. this treble thing is a new field for me so i am just trying to see what we can do with it.
Hi guys.
I have some questions about the new android treble feature.
The way it is advertised, it seems to be the END of the fragmentation problem on android. But i dont know if it is over advertised.
1) "The A/B partition system is only for seamless update."
I've read this on the internet and the only difference between A and A/B is that A will update like older androids while A/B will be with the phone turned on with only a reboot being necessary. This shouldn't be something that will make treble more or less useful for the end-users.
2) Why I dont see people talking about system repartitioning the phone to enable A/B partition? Most phones have 32GB, with most being over 20GB in /data. Why not just repartition 1GB to enable A/B partition?
3) "The treble updates will still be released by the phone's manufaturer."
Really? I dont know if the updates are comming from google or phone manufacturer. Can someone confirm?
It does not make any sense to try to stop the fragmentation issue by still leaving the update task on the manufacturer's side...
After some time they will stop updating anyway.
4) "Android treble will be useless if the phone does not come with native treble support."
I really don't understand this. Ive read this in reddit I believe. But installing a custom treble supported rom wouldn't be easier to perform updates on the custom rom?
My thoughts are that the updates are going to be handled by google. By doing so, we could install any custom rom and forget it because "google will update it from now on". This makes sense to me. If treble is not heading to this, then they are doing it wrong...
IMO, I think that treble would be great if users could perform:
Get your old android phone's manufaturer proprietary files;
Save those files in a vendor folder;
Execute them in android 8 and on;
Leading every android device to the latest android version.
(This in a perfect world. I know this option is a dream.)
BUT, I believe this could be an option at least for the devices that received the oreo update (because they received the "updated proprietary files" that would work for the new android treble and by consequence, on all new android versions.
If so is true, the best that could happen is for custom rom devs, create their roms by packing the vendor files, integrating with AOSP and linking the updates from the google server. Done, phone will be "forever updated".
Any comments on those, please?
Thank you.
facsi2 said:
Hi guys.
I have some questions about the new android treble feature.
The way it is advertised, it seems to be the END of the fragmentation problem on android. But i dont know if it is over advertised.
1) "The A/B partition system is only for seamless update."
I've read this on the internet and the only difference between A and A/B is that A will update like older androids while A/B will be with the phone turned on with only a reboot being necessary. This shouldn't be something that will make treble more or less useful for the end-users.
2) Why I dont see people talking about system repartitioning the phone to enable A/B partition? Most phones have 32GB, with most being over 20GB in /data. Why not just repartition 1GB to enable A/B partition?
3) "The treble updates will still be released by the phone's manufaturer."
Really? I dont know if the updates are comming from google or phone manufacturer. Can someone confirm?
It does not make any sense to try to stop the fragmentation issue by still leaving the update task on the manufacturer's side...
After some time they will stop updating anyway.
4) "Android treble will be useless if the phone does not come with native treble support."
I really don't understand this. Ive read this in reddit I believe. But installing a custom treble supported rom wouldn't be easier to perform updates on the custom rom?
My thoughts are that the updates are going to be handled by google. By doing so, we could install any custom rom and forget it because "google will update it from now on". This makes sense to me. If treble is not heading to this, then they are doing it wrong...
IMO, I think that treble would be great if users could perform:
Get your old android phone's manufaturer proprietary files;
Save those files in a vendor folder;
Execute them in android 8 and on;
Leading every android device to the latest android version.
(This in a perfect world. I know this option is a dream.)
BUT, I believe this could be an option at least for the devices that received the oreo update (because they received the "updated proprietary files" that would work for the new android treble and by consequence, on all new android versions.
If so is true, the best that could happen is for custom rom devs, create their roms by packing the vendor files, integrating with AOSP and linking the updates from the google server. Done, phone will be "forever updated".
Any comments on those, please?
Thank you.
Click to expand...
Click to collapse
1) A/B devices also have a thing called "skip_initfs". In older devices, which is indeed A-only, we have the kernel ramdisk in boot partition. But in A/B devices, the boot ramdisk is only for recovery - when booting the system, the system actually contains the initramfs instead and it gets mounted to / (rootfs) instead of /system.
In short, A/B devices have init and ramdisk all in the system partition. This means Treble ROM's for A/B devices can easily have their own initfs, which makes things a little easier.
2) It also needs bootloader (either SBL or ABOOT, can't remember) support for AB, and these are almost never open source.
3) Treble allows OEM's (the hardware, e.g. Qualcomm) and the ODM (the brand, e.g. Xiaomi) to work independently. Treble provides a contract that the ODM and OEM must each pass verification black-box style, allowing independent development without reliance on the other. Best analogy I can think of is how drivers for Windows work - they don't need to know about what edition of Windows or model of PC it is; they just need to follow standards when making their hardware drivers - and if they do they can be sure that it should work with any other software.
Theoretically, Android P GSI should work straight away on a Treble-enabled Oreo phone. Maybe only with minimal changes - still too early to say. But this is the idea of it.
4) Not entirely true. Unofficial Treble (e.g. like we did for Mi A1) allows us to use GSI's thanks to Phh's work. And unlike many other official Treble devices, we have 100% compatibility with GSI's thanks to the fact that that we can fix GSI stuff on our own end. Many Treble devices are not properly "GSI-ready" vendor implementations, a common theme is that they still put essential Camera stuff in their system ROM instead of vendor (Treble verification I guess doesn't care about Camera support, sadly).
Updates from Google directly is a different program entirely; that's only for devices in Android One program.
Treble support with blobs from before Oreo is practically impossible. They need to be either modified and recompiled with the VNDK standards, or a very smart person needs to shim them. Don't ever expect a pre-Oreo device without source code to be Treble compatible - it's a monumental task that basically requires reverse-engineering the proprietary blobs. If you don't find that useful, then those are the breaks - this stuff was only introduced relatively recently. Treble is not a time machine
But again: Treble does NOT mean "updates directly from Google". That's only for official Android One devices.
Maybe one day Google will have an official thing akin to GSI. But not today. As it is, GSI - generic Treble ROM's - are the love child of Phh, there is no such thing as official updates directly from Google outside of Android One (and Pixel ofc).
As for your other speculation, it's mostly redundant - apparently, all devices that launch with Android P are required to have Treble. If I remember correctly. If the pre-P device is popular and open enough, then yeah you will get unofficial Treble (like we did with Mi A1). But that's all up to the device community. But just to reiterate one more time - this does NOT mean updates will come directly from Google.
In case you're wondering why the updates won't come directly from Google (and I predict that this will never be the case, outside of Android One program devices) - simple fact is because Android != Google. Google will never force Android vendors to use Google servers or update channel because Android itself is a very open platform; Treble is an architectural change regarding HAL abstraction - not an enforcement of Google doctrine. It'd be absurd if they did pull a stunt like that; would be like GNU saying "hey Ubuntu, Debian, and all you other guys - you have to use GNU update servers now, all your own servers are not allowed".
Many thanks, Dan. The smart thing to do is hope a new good phone gets released with latest android. Then we can keep if for a longer time thanks to treble. Planned obsolescence sucks.
Just for the curiosity, I own a moto z play and a galaxy s5 (just because of the IR blaster).
facsi2 said:
Many thanks, Dan. The smart thing to do is hope a new good phone gets released with latest android. Then we can keep if for a longer time thanks to treble. Planned obsolescence sucks.
Just for the curiosity, I own a moto z play and a galaxy s5 (just because of the IR blaster).
Click to expand...
Click to collapse
I have to say I am very glad I got the Mi A1. They did take a while to release the source code, but being an Android One device it was already "Treble-ready" - the HAL and vendor files were already binderized, as per requirements for Treble (that's the most difficult part in getting a Treble device).
My next device may be the A2, or a Pixel, it really depends on how long I keep this device (probably a while yet, since it's definitely getting P officially even).
And yeah, being a Xiaomi, they always have IR
CosmicDan said:
In case you're wondering why the updates won't come directly from Google (and I predict that this will never be the case, outside of Android One program devices) - simple fact is because Android != Google. Google will never force Android vendors to use Google servers or update channel because Android itself is a very open platform; Treble is an architectural change regarding HAL abstraction - not an enforcement of Google doctrine. It'd be absurd if they did pull a stunt like that; would be like GNU saying "hey Ubuntu, Debian, and all you other guys - you have to use GNU update servers now, all your own servers are not allowed".
Click to expand...
Click to collapse
I think in google (Android) updates being sent by google itself as it is the one who releases android security patches.
I took a look on Mi A1. it only misses NFC. I might wait another year to change my phone.
thanks
facsi2 said:
I think in google (Android) updates being sent by google itself as it is the one who releases android security patches.
I took a look on Mi A1. it only misses NFC. I might wait another year to change my phone.
thanks
Click to expand...
Click to collapse
What do you mean? Security updates can't be sent directly from Google, because every device is different and usually heavily modified at the source code level.
The whole point of Android One is that they are relatively pure, bit they still need to compile seperate security updates for different devices.
In short, there's no such thing as generic firmware, every firmware and therefore every update is still device-specific. Excluding GSI of course, which is not an official thing remember.
True about NFC, I never used it so forgot.
CosmicDan said:
What do you mean? Security updates can't be sent directly from Google, because every device is different and usually heavily modified at the source code level.
The whole point of Android One is that they are relatively pure, bit they still need to compile seperate security updates for different devices.
In short, there's no such thing as generic firmware, every firmware and therefore every update is still device-specific. Excluding GSI of course, which is not an official thing remember.
True about NFC, I never used it so forgot.
Click to expand...
Click to collapse
Isnt google responsible for those security updates in a general ROM and then manufacturers have to port that update for their devices?
https://source.android.com/security/bulletin/
What I meant was with treble, we could update our android directly from google, without having to wait for the manufacturer. Pretty much as how windows update work.
facsi2 said:
Isnt google responsible for those security updates in a general ROM and then manufacturers have to port that update for their devices?
https://source.android.com/security/bulletin/
What I meant was with treble, we could update our android directly from google, without having to wait for the manufacturer. Pretty much as how windows update work.
Click to expand...
Click to collapse
Yes, that's how they work.
But no, we cannot. As I said multiple times already - there is no such thing as a generic device to Google. GSI is created by Phh. Generic updates simply do not exist.
If Google ever makes an official GSI of some sort, or Phh works with someone to make an OTA system for his GSI's, then it could happen. But I wouldn't hold my breath for either of those things - the first one I already explained why it isn't feasible yet, and the second one costs too much money.
CosmicDan said:
Yes, that's how they work.
But no, we cannot. As I said multiple times already - there is no such thing as a generic device to Google. GSI is created by Phh. Generic updates simply do not exist.
If Google ever makes an official GSI of some sort, or Phh works with someone to make an OTA system for his GSI's, then it could happen. But I wouldn't hold my breath for either of those things - the first one I already explained why it isn't feasible yet, and the second one costs too much money.
Click to expand...
Click to collapse
I am confused. What is android AOSP rom then?
facsi2 said:
I am confused. What is android AOSP rom then?
Click to expand...
Click to collapse
https://en.m.wikipedia.org/wiki/Android_(operating_system)#AOSP
Read the "Development" paragraph. The following "Update schedule" section goes on the explain the history and situation of how updates work, basically the same as what I've already said.
got it. Many thanks.
Treble will be really useful for the users.
Btw, do you know if the source code released for moto z play the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP...
facsi2 said:
got it. Many thanks.
Treble will be really useful for the users.
Btw, do you know if the source code released for moto z play the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP...
Click to expand...
Click to collapse
Useful for users and developers!
I don't know what you mean by that question. By "same update" do you mean repartition for Treble?
CosmicDan said:
Useful for users and developers!
I don't know what you mean by that question. By "same update" do you mean repartition for Treble?
Click to expand...
Click to collapse
I ended up editing the phrase before sending it and I didn't fully checked it:
Do you know if the source code released for moto z play IS the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP
What I am asking is if the source code available for Moto z play have the contents to be able to port treble as you did on mi a1. I don't know by looking the contents on GitHub, if the code available is complete for that job.
Thanks
facsi2 said:
I ended up editing the phrase before sending it and I didn't fully checked it:
Do you know if the source code released for moto z play IS the "same code" available for mi a1? I wonder if it is possible to do the same update you did on A1 on the ZP
What I am asking is if the source code available for Moto z play have the contents to be able to port treble as you did on mi a1. I don't know by looking the contents on GitHub, if the code available is complete for that job.
Thanks
Click to expand...
Click to collapse
To port Treble to a device, these things are needed:
1) All the source code required to build standard AOSP, e.g. device tree and kernel. If you already have custom ROM's working f well for you device, this will likely be true.
2) Binderized vendor HAL. If you have *official* Oreo update from Motorola, this MAY be true. Manual inspection of compatibility_matrix.xml is required here, if everything in there matches the Treble requirements as listed on Android Developers then chances are it is ready.
3) An unused partition of ~500MB or more for Vendor, or the ability to repartition the device (many Qualcomm devices are standard GPT partitioned eMMC these days, if it is then it's possible).
That's a summary of the requirements. Obviously some technical investigation is required. Forward that info to any device developers who are interested in the project.
I read somewhere that device to be even updated to Pie have to have enabled Treble? Oreo required it only for launched devices and Pie require it from ALL devices.
Is it right or not? Unfortunately I cannot find it again
CosmicDan said:
To port Treble to a device, these things are needed:
1) All the source code required to build standard AOSP, e.g. device tree and kernel. If you already have custom ROM's working f well for you device, this will likely be true.
2) Binderized vendor HAL. If you have *official* Oreo update from Motorola, this MAY be true. Manual inspection of compatibility_matrix.xml is required here, if everything in there matches the Treble requirements as listed on Android Developers then chances are it is ready.
3) An unused partition of ~500MB or more for Vendor, or the ability to repartition the device (many Qualcomm devices are standard GPT partitioned eMMC these days, if it is then it's possible).
That's a summary of the requirements. Obviously some technical investigation is required. Forward that info to any device developers who are interested in the project.
Click to expand...
Click to collapse
About re-partitioning android device, is there a tool, command or anything universal to all the phones, like how in linux you can re-partition what and how you want. For example, I never saw a re-partition "mod" for samsung devices (ex. to give more space on /system). There is only one reason I can think of.
If samsung "download mode" is stored on a read-only pre-programmed chip, then re-partition should be no problem. If anything goes wrong, just flash stock firmware with CSC or flash official .PIT file.
If that is the case then there are no risks in re-partitioning a device.
There is a tool that can edit .PIT files, but what if someone wipes the bootloader partition?
Would "download mode" still be there for a roll-back, or would the device be permenantly bricked?
Is re-partition-ing safe?
If it is, then why doesn't any 3rd party recovery have an option for that, kinda like GPARTED. Is it impossible or what?
And if bootloader gets wiped, is there a way to re-program the device to the working order?
Sry for so many questions. Already tried to search but never got a straight-forward answer.
Shadow7107 said:
About re-partitioning android device, is there a tool, command or anything universal to all the phones, like how in linux you can re-partition what and how you want. For example, I never saw a re-partition "mod" for samsung devices (ex. to give more space on /system). There is only one reason I can think of.
If samsung "download mode" is stored on a read-only pre-programmed chip, then re-partition should be no problem. If anything goes wrong, just flash stock firmware with CSC or flash official .PIT file.
If that is the case then there are no risks in re-partitioning a device.
There is a tool that can edit .PIT files, but what if someone wipes the bootloader partition?
Would "download mode" still be there for a roll-back, or would the device be permenantly bricked?
Is re-partition-ing safe?
If it is, then why doesn't any 3rd party recovery have an option for that, kinda like GPARTED. Is it impossible or what?
And if bootloader gets wiped, is there a way to re-program the device to the working order?
Sry for so many questions. Already tried to search but never got a straight-forward answer.
Click to expand...
Click to collapse
No, nothing is standard when it comes to embedded systems (which our devices are). By "standard on Linux", you must mean "Standard on x86-based Linux" - which is mostly all MBR or GPT (but even then there are other less-common standards)
But as I said - many Qualcomm devices are in fact standard GPT, you can just use gdisk (a fork of fdisk which is better choice for GPT partition maps).
Repartitioning is relatively safe on SOME devices because they have an emergency bootloader/downloader which is on it's own EEPROM and not the eMMC or whatever. You will have to research the device for yourself to see if it has any "unbrick" capability. Again, many qualcomm devices have what is called "EDL mode" - EDL mode is still possible even if you "cat /dev/null > /dev/block/mmcblk0" for example - albeit you may need to disassemble the device to access test point to get it to be kicked into there.
Sony has published a configuration with instructions how to compile AOSP from source: https://github.com/sonyxperiadev/device-sony-pdx213
My question is, what would be the expected difference between this vendor configuration, and something like phh-treble?
My understanding is phh-treble is an AOSP generic system image with some fixes applied, while this configuration seems to be literally just that: configuration files.
Of course if you start to compare a more custom GSI to AOSP it has extra features but I'm not so much interested in that, I'm more interested in all the hardware working correctly.
So what's more likely to provide full device functionality, a phh-treble GSI or AOSP based on the vendor configuration?
I'd expect that the vendor image would be the most reliable (as it's from Sony themselves) to take the most advantage of its device-specific hardware. I just checked today and they finally have the image in the "software binaries" that used to have only config files: https://developer.sony.com/file/download/software-binaries-for-aosp-android-11-0-kernel-4-19-lena/
What's actually inside this software binaries image? Is it something you're supposed to flash to your device?
About software binaries (aka vendor image):
https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions/build-aosp-android-android-11-0-0
- Step #7 "Flash vendor image to your device".
Huh interesting. The Lineage GSI is almost 2GB while this image is only 300MB unzipped. So I was like... wait is this really a whole ROM? But uh, I guess so!
I thought maybe it's like... just the kernel or something. I think Lineage also includes other partitions. I wonder what would happen if you take the Lineage GSI and then use this as the OEM partition. Horrible things probably haha
pepijndevos said:
Huh interesting. The Lineage GSI is almost 8GB while this image is only 300MB unzipped. So I was like... wait is this really a whole ROM? But uh, I guess so!
Click to expand...
Click to collapse
Hey, when is the GSI so big? It's supposed to be <3GB, wouldn't fit in your /system otherwise.
Sorry was looking at the wrong one (Raspberry Pi) for my phone was indeed 1.8GB but still.
Looking at the link it seems like they do actually flash the OEM partition, and THEN flash the AOSP image partitions. So maybe it DOES actually make sense to use this OEM partition? But I definitely need to understand better what each partition is for before I brick my phone haha
Okay so reading up a bit, GSI only flashes system as far as I can tell, so besides vbmeta and system, all other partitions are original(?)
The linked binary is just the oem partition. Since I did not touch my oem partition when installing the GSI, it probably still contains the original? So is there really any point in flashing this binary? Is there a way to unpack and inspect it? Disk image mounter doesn't like it.
pepijndevos said:
Sony has published a configuration with instructions how to compile AOSP from source: https://github.com/sonyxperiadev/device-sony-pdx213
My question is, what would be the expected difference between this vendor configuration, and something like phh-treble?
My understanding is phh-treble is an AOSP generic system image with some fixes applied, while this configuration seems to be literally just that: configuration files.
Of course if you start to compare a more custom GSI to AOSP it has extra features but I'm not so much interested in that, I'm more interested in all the hardware working correctly.
So what's more likely to provide full device functionality, a phh-treble GSI or AOSP based on the vendor configuration?
Click to expand...
Click to collapse
Phh-treble is a generic system image ( /system only,concept of treble is to use your vendor implementation witch hardware-specific parts without requiring additionnal Work )
phh gsi fix issue of devices specific hardware from oem ( phh fix headset issue in gsi lena for ex )
SODP ( Sony aosp ) is rom witch only open sources stuff .
I have compiled SODP before and actually its isnt stable in this devices ( bug ril, no sound ... )
Until xperiadev fix all issue, we have stable GSI ( I use in daily for professional use ! I have no Bad surprise) we have pe a12,lineage 19 gsi...
As far as I understand, in A-only GSIs the system partition (the GSI image) just contains the system files (the contents of $TARGET_ROOT_OUT in the build process). This whole partition is then mounted as /system in the OS.
By contrast, A/B GSIs have these same contents in the /system directory within the GSI image/partition. The root of the partition itself is then set as root (i.e. system-as-root, SAR) in the OS. As such, /system is not a mount point anymore, but a normal directory. The root of the image/partition (SAR) contains the init files etc. for booting (which in A-only setups reside on the ramdisk in the boot partition, so they are missing from an A-only GSI).
These are basically the only differences between the two, or rather: the former A-only GSI is for a non-SAR system; the latter A/B GSI is for a SAR-system. It is explained here, that these differences are minor and you can relatively simply convert a GSI image from A-only to A/B or back. (Back to A-only is even easier because you don't need all the root files.) Now, the manner in which /system is stored and where the root files are (SAR or not) does not seem to have anything to do with having a dual slot A/B system (for seamless OTA updates) or a single slot system (A-only). But apparently it does, since the names clearly say A-only and A/B. So let's find out where that comes from.
First of all about the SAR definition: Google's definition differs from what you'd expect. You can read about this in the Android documentation. New Android versions don't use SAR according to Google, as they do not first boot from the system partition. Instead, the new "method C devices" boot from ramdisk and then in a second stage boot the system partition; the older, "method B devices" boot from system directly and hence only those are called SAR by Google.
However, for all intents and purposes, SAR could just as well be defined as the system image/partition being the root partition, regardless if you boot from it in a single stage or not. Then, SAR corresponds to having a system image/partition like is done in A/B GSIs that you download from this forum, as mentioned above in the 2nd paragraph. We uphold this definition therefore, as does the documentation from the utility tool Magisk.
On this documentation page from Magisk it is nicely explained how the booting process and the partition structures evolved over subsequent Android versions. We'll recap a few crucial points, just to understand where A-only and A/B images are meant for:
Android 8 introduced project Treble for the first time and hence some devices should be capable of running GSIs. Booting was done from ramdisk (method A) and SAR was not a thing yet. Hence, devices running Android 8 and below (and possibly also some running Android 9 or even later) that use this boot method need A-only (non-SAR) GSIs (if Treble supported). Seamless updates were not a thing with this method.
Android 9 introduced SAR which was necessary for A/B seamless updating. In the Magisk documentation this is called "legacy SAR" (method B). Hence, devices running Android 9 (and possibly also some running Android 8 or ones upgraded to Android 10 or higher) using this method need A/B (SAR) GSIs (if Treble supported), whether or not seamless updates are supported.
Android 10 introduced the ramdisk again due to support for dynamic partitions. 2SI made SAR possible (method C). Hence, Android 10 or higher devices (and possibly also some running an older version of Android) using this method need A/B (SAR) GSIs (if Treble supported), whether or not seamless updates are supported. Android 10 always uses SAR with method C (but perhaps devices upgraded from lower versions can use Android 10 with non-SAR but method A instead?).
It's clear that having a two slot A/B device (for seamless updates) or a single slot A-only device has little to do with whether you need an A/B or an A-only GSI. The Magisk documentation defines four types of devices. Considering the above, only device type I always needs an "A-only" non-SAR GSI. Type II, III and IV always use "A/B" SAR GSIs, and indeed this means the kind of image needed is independent of whether seamless updates are supported or not (a device with type III does not and neither does a device with type IV with a single slot system).
The reason we apparently still call the GSIs for these old non-SAR devices "A-only" and the SAR ones "A/B" is now also clear: at one time, at the time of Android 7 and 8, many devices did not have seamless updates, which was a new feature (the Pixel was the first two slot device). So devices which had it were required to use method B (and hence legacy SAR), whereas single slot non A/B devices could also use the old method A (non-SAR). Even then, single slot A-only devices were still able to use method B anyway, if implemented that way. However, because then it was mostly true that single slot devices used method A and the dual slot devices used method B, people decided that all method B devices (be it single or dual slot) fall under the A/B denominator and that the A-only name is reserved for method A devices (where the A of course has nothing to do with the A in "A-only"; I hope you can still follow along).
So my question is: why don't we call A-only GSIs non-SAR and A/B GSIs SAR? That seems much less confusing. This forum even has three sub forums for A, A/B and A / A/B GSIs. That seems a bit much considering that there is only a minor difference in partition layout. I think that a single forum could suffice. Indeed, we can see that mostly everyone publishes their GSI in the A / A/B forum. Perhaps it's a good idea to create two forums then, called "GSI development" and "non-SAR (legacy) GSI development". Also, with Android 11 and higher the boot process is similar and compatible to Android 10, so going forward this important distinction will die out anyway and every GSI should work on every phone. (Unless yet another incompatible"method D" comes along.)
What strikes me as odd still, is that even for Android 10 and 11 releases there are "A-only" non-SAR GSIs offered. (To see what I mean look for example here at builds provided by @phhusson.) But I thought that non-SAR images are for older Android versions using method A. So my second question is: can these "A-only" GSIs with recent Android >9 versions even run on non-SAR devices? Is the SAR requirement for Android 10 then not so strict? Are they indeed only meant for the method A / non-SAR devices which can actually boot Android 10 and higher using method A?
As a last note, what I also find weird is that Google itself has a confusing name for its legacy non-SAR build targets: they add the "_ab" suffix. However, this has again nothing to do with seamingless A/B system updates on two-slot devices. I asked about that here. Please post there if you want to give some input on that.
Any thoughts are appreciated, especially regarding the two questions I have.
A-only/AB was used for historical reasons, because it was true on Oreo devices. But since then, Google calls Android 10 devices non-SAR (because they boot on initramfs, even though afterwards yes system is root), and sar property is set to false on those devices. So you can't just go around saying sar/non-sar, it'll a bit more correct, but still not correct. I could have switched to a "SAS" vs "SAR" naming convention (system-as-system VS system-as-root) but well I didn't have time
For your second question, yes that's the whole idea of "A-only GSI". No Android requirement is perfectly strict. Android requirements says you must have an x86 or an ARM, yet there are RISC-V Android. Android is opensource, you do whatever you want with it. Yes they are only meant for "method A" devices.
As for aosp_arm64 vs aosp_arm64_ab, the `_ab` refers to legacy ab devices, which have less requirements wrt properties
Thanks that clears up a whole lot. Except for the _ab part, but I guess we just have to view that just as a suffix for a legacy build target.
OP, this is an exceptional outline and analysis of SAR, the A/B partition scheme, A-only versus A/B, and their individual and collective relevance to GSI enabled devices. I have a question regarding Android 8.x Oreo and the applicability of A/B seamless updates. You stated that Android Oreo did not have seamless updates. I was of the understanding that the A/B seamless updates feature was first introduced with Android 7.0 Nougat, although at the time only Pixel devices actually had the A/B partition scheme. So, did Android 8 Oreo not include seamless updates for a particular reason? Thanks again for the great outline.
@Viva La Android You're right, seamless updates were already there in Android 7. Still Treble started with Android 8 if I'm not mistaken, so GSIs were not relevant before then, so I guess I just went from there. But indeed, my statement that Android 8 did not have seamless updates was just wrong, and poorly worded by me. I changed that paragraph to clear it up. I also put some more "single slot" / "dual slot terminology" in there as well so as to have an alternative naming scheme from "A devices" / "A/B devices". I hope I didn't make a mistake. It's easy to make a mistake with such a confusing naming scheme.
And thanks for the praise, I'm glad it's useful!
Quigley said:
@Viva La Android You're right, seamless updates were already there in Android 7. Still Treble started with Android 8 if I'm not mistaken, so GSIs were not relevant before then, so I guess I just went from there. But indeed, my statement that Android 8 did not have seamless updates was just wrong, and poorly worded by me. I changed that paragraph to clear it up. I also put some more "single slot" / "dual slot terminology" in there as well so as to have an alternative naming scheme from "A devices" / "A/B devices". I hope I didn't make a mistake. It's easy to make a mistake with such a confusing naming scheme.
And thanks for the praise, I'm glad it's useful!
Click to expand...
Click to collapse
You are quite welcome, and thanks again for the detailed and comprehensive outline of such a haphazard set of Android topics. Thank you for your clarification on my question.
I desperately need to get my work profile working on my new OnePlus Nord N200 5G (dre), and I've just discovered that it is apparently impossible to create a new work profile on LineageOS 19.1. It seems, however, that a work profile set up on 18.1 will continue to work after a dirty flash to 19.1. Thus, I'm hoping that I can install 18.1 on my device, setup of the work profile, and immediately dirty flash 19.1. I won't really need a fully functional build of 18.1; just something that will boot up and allow me to create the work profile before I dirty-flash 19.1.
In order to do this, I need to build LineageOS 18.1 for this device. Unfortunately, only 19.1 has ever been supported.
I have a build environment that is currently building 19.1, just as a test. I also have the most recent Android 11 vendor firmware, from which I should be able to extract any required proprietary files.
I'm really missing 2 things:
The list of proprietary files that I should extract from the vendor's firmware. (I have the 19.1 list, but I assume that it won't work.)
What other files do I need to create/edit to add the device to the 18.1 build tree.
Is there a guide somewhere that walks through the process?
Ah, @ipilcher I was hoping someone smarter than me would answer your question. It would do so much for all the Android forks, and Android in general. I've asked the same question to several devs on IRC and they all basically say "no, no easy way to explain it...". My kingdom for a guide that doesn't involve the School of Hard Knocks all the way through.
So in full disclosure, as of today, I haven't managed to build a ROM on an unsupported phone- but I have done full builds from source with LOS and Calyx (with bootloader relocking on the latter) using existing projects.
But... I would assume from others that have gotten the AOSP "Generic Stock Images" to run on various random phones that there isn't really that much you /need/ for what you want to do; you don't need a functioning modem, fingerprint sensor, camera, GPS, notification LED, battery management, etc.
From what I understand, if your vendor follows android specs, all that would be in one of the vendor partitions anyway. From the builds I've done (mostly Motorola and OnePlus devices) the proprietary files (in "stock" LOS) are sourced from a few different places, possibly from generic chipset support (the same tree is used for multiple devices by a manufacturer and/or chipset). One LOS 18.1 build had a whole bunch of (proprietary) files in it that weren't even in the stock rom image! If you are sourcing from stock firmware (OTA off OP site or one of the MSM images here) I'd assume that half the partition is spyware or manufacturer test/calibration tools, and the other half are the drivers you want for a fully functional phone- which, luckily, it seems you can fall short of without failure, so you can probably be pretty lax about picking.
The bootloader chain seems to have a lot of drama between Android 11, 12, and 13 (requiring flashing other partitions outside of the normal system ones)- I've never had a N200 to play with to know if it is high drama, too.
Hey, at least you're using a OnePlus with QC chipset, so EDL can bail you out of pretty much anything you do wrong. I hard-bricked a $500 Pixel and learned how absolutely hideous Google support is- never buying one of those again.
Hope that helps.
SomeRandomGuy said:
Ah, @ipilcher I was hoping someone smarter than me would answer your question. It would do so much for all the Android forks, and Android in general. I've asked the same question to several devs on IRC and they all basically say "no, no easy way to explain it...". My kingdom for a guide that doesn't involve the School of Hard Knocks all the way through.
So in full disclosure, as of today, I haven't managed to build a ROM on an unsupported phone- but I have done full builds from source with LOS and Calyx (with bootloader relocking on the latter) using existing projects.
But... I would assume from others that have gotten the AOSP "Generic Stock Images" to run on various random phones that there isn't really that much you /need/ for what you want to do; you don't need a functioning modem, fingerprint sensor, camera, GPS, notification LED, battery management, etc.
From what I understand, if your vendor follows android specs, all that would be in one of the vendor partitions anyway. From the builds I've done (mostly Motorola and OnePlus devices) the proprietary files (in "stock" LOS) are sourced from a few different places, possibly from generic chipset support (the same tree is used for multiple devices by a manufacturer and/or chipset). One LOS 18.1 build had a whole bunch of (proprietary) files in it that weren't even in the stock rom image! If you are sourcing from stock firmware (OTA off OP site or one of the MSM images here) I'd assume that half the partition is spyware or manufacturer test/calibration tools, and the other half are the drivers you want for a fully functional phone- which, luckily, it seems you can fall short of without failure, so you can probably be pretty lax about picking.
The bootloader chain seems to have a lot of drama between Android 11, 12, and 13 (requiring flashing other partitions outside of the normal system ones)- I've never had a N200 to play with to know if it is high drama, too.
Hey, at least you're using a OnePlus with QC chipset, so EDL can bail you out of pretty much anything you do wrong. I hard-bricked a $500 Pixel and learned how absolutely hideous Google support is- never buying one of those again.
Hope that helps.
Click to expand...
Click to collapse
I just wanted to close this out and thank you for your response.
Fortunately, the issue that was driving me to try to build 18.1 for this device (https://gitlab.com/LineageOS/issues/android/-/issues/4983) has been diagnosed, and I was able to work around it.
Of course, I just realized that my wife's new Moto G 5G is an XT2213-3, not an XT2113-3, so maybe I'll revisit this subject some day.
Welllp... at the risk of being accused of insufficent RTFMing, I did stumble across this article the other day that nicely outlined a few things that I didn't know:
[GUIDE] [how to] CREATE OWN ROM [FOR ANY ANDROID DEVICE] [FOR N00B] [EASIEST METHODS]
NOTE: THIS GUIDE WILL WORK ANY ANDROID DEVICE BUT HAS FEW EXTRA PRE-SUGGESTED LINKS FOR GALAXY ACE PLUS USERS. Special Thanks to - dsixda for his awesome kitchen. Please Hit Thanks button for him. inspired by isidromxz's thread. Please kindly...
forum.xda-developers.com
It isn't exactly "build your own device tree on top of AOSP" which I think is what you wanted and I certainly still do... but it might help someone else who finds /this/ thread with the same question. It also ends with the wonderful quote "This thread is 10 yo. Leave it alone. things have changed" - which is pretty solid advice IMHO.
Ah well, if it wasn't a challenge, there would be no reward, eh?