Not all SDM845 devices use A/B
I noticed that in https://github.com/NixOS/mobile-nixos/blob/974d9ac5c7834b98a435e6948bbdeaa9b90256fa/devices/families/sdm845-mainline/default.nix#L39C41-L39C41 it is assumed that all devices from the family use A/B. But at least the popular Pocophone F1 (xiaomi-beryllium) doesn't. https://github.com/NixOS/mobile-nixos/pull/560 still works as written there however (except the speaker thing, that is also not working on my device for some reason.. but I also went to the newest commit and added new firmware on my local copy...).
Hi :wave:
This won't be a problem, as it's using lib.mkDefault. Any device not following that default assumption can set it to false in their device description.
Hmmm. I wonder if it even makes sense to set a default assumption then. Maybe at least rephrasing it a bit could be considered. Hope it never breaks anything due to potentially misleading new people.
Btw. I also noticed that deviceinfo_flash_offset_second address is another thing that is different for that device (at least according to https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/community/device-xiaomi-beryllium/deviceinfo?ref_type=heads#L34). Will try to check a few more things and maybe I will add more in the PR for the device.
As of today, the only thing this changes is here:
https://github.com/NixOS/mobile-nixos/blob/974d9ac5c7834b98a435e6948bbdeaa9b90256fa/modules/system-types/android/default.nix#L52-L56
(as seen here https://github.com/search?q=repo%3ANixOS%2Fmobile-nixos%20ab_partitions&type=code)
So there should be no breakage. And any uses of that information I know of that we might want to use in the future either can't break, or really, should be caught at runtime anyway.
As far as offset_second goes, my understanding is that basically no modern~ish android systems even use it. It's part of the header up to and excluding version 3 of the header. I personally have never seen any device use it. We don't even have the setup to attach a second ramdisk into a boot image.
Having the wrong information in it shouldn't cause any issues, since it will not be used. It likely could be dropped from all android boot image data, with a bogus default, and be fine.