Is it a a/b device?
Of course, otherwise it wouldn’t work with iodéOS GSI iode-5.5-20240919-arm64_bvN alias arm64_bfN.
Source: Andy Yan’s naming rules of variants
{arm|a64|arm64}_{a|b}{v|g}{N|S}-{signed|vndklite|secure|personal}
| | | | |
| | | | signed: Signed with maintainer's keys
| | | | vndklite: For VNDKLite devices,
| | | | or for read-writeable /system on regular devices
| | | | personal: With personal mods, for reference
| | | | secure: Superuser removed and system props spoofed
| | | |
| | | N: No Superuser
| | | S: *Built* with PHH Superuser (app needed)
| | | (Z): *Built* with eremitein's Dynamic Superuser (not offered here)
| | |
| | v: Vanilla, i.e. no GAPPS
| | g: With regular GAPPS
| | o: With Android Go GAPPS
| | (f): With built-in MicroG and FLOSS replacements of GAPPS (not offered here)
| |
| a: "A-only", i.e. system-as-system (deprecated since Android 12)
| b: "AB", i.e. system-as-root
|
arm: ARM 32-bit (deprecated since Android 12)
a64: ARM 32-bit with 64-bit binder
arm64: ARM 64-bit
my lenovo tab is “a” only and it works.
And that’s the reason I asked
Maybe it’s a seamless update which only works on a/b devices
Regarding the naming
a
a only
b
a and a/b
OTAs are only supported on a/b devices.
Regarding the naming, we won’t follow naming rules above for one simple reason: we won’t have any variant. So we will just name it arm64_ab, to clearly state that it is an a/b image for arm64 arch.
1 Like
In the end, I don’t care which naming convention is used. With arm64_ab I get what is useful to me: an iodéOS GSI with MicroG.
However, arm64 does not give any clear information that MicroG is implemented in the system. Inexperienced users then ask:
Believe me, these users also ask if there is an “f” instead of a “V” in the file name.
In the end, whatever it says, these questions always come up. Lots of questions without even thinking about them. You give an answer and then nothing happens. Often a waste of time. I’ve moved on from that.
I think it’s fine the way it is. You don’t need to put much more effort into it
You are right. That happens often, not just here. Nevertheless, the iodé forum is a very special one.
I don’t think it’s good the way it is. But I won’t be wasting any more time here from now on.
Gigaset GS4
Mediatek Helio P70 [ arm64_ab ]
System update available > Preparing system update > New update failed to be installed.
System update available > Preparing system update > New update failed to be installed.
With this GSI that we used, you know what I mean, there was also no naming for the microG implementation
bvN, bvS, VNDKLite
I don’t think it’s important either
I’m very surprised by this statement from an ‘expert’, because Andy Yan’s naming rules for variants are clear and …*
arm64: ARM 64-bit
b: “AB”, i.e. system-as-root
N: No Superuser
S: Built with PHH Superuser (app needed)
vndklite: For VNDKLite devices, or for read-writeable /system on regular devicesv: Vanilla, i.e. no GAPPS
g: With regular GAPPS
o: With Android Go GAPPS
(f): With built-in MicroG and FLOSS replacements of GAPPS (not offered here)
*… are largely adhered to by the majority of GSI developers for good reason:
@andyyan
lineage-21.0-20240918-UNOFFICIAL-arm64_bvS.img.gz
lineage-21.0-20240918-UNOFFICIAL-arm64_bvS-vndklite.img.gz
lineage-21.0-20240918-UNOFFICIAL-arm64_bvN.img.gz
lineage-21.0-20240918-UNOFFICIAL-arm64_bvN-vndklite.img.gz
lineage-21.0-20240918-UNOFFICIAL-arm64_bgN-vndklite-signed.img.gz
lineage-21.0-20240918-UNOFFICIAL-arm64_bgN-signed.img.gz
@phhusson
system-td-arm64-ab-vanilla.img.xz
system-td-arm64-ab-vndklite-vanilla.img.xz
@ponces
aosp-arm64-ab-gapps-14.0-20240816.img.xz
aosp-arm64-ab-gapps-vndklite-14.0-20240816.img.xz
aosp-arm64-ab-vanilla-14.0-20240816.img.xz
aosp-arm64-ab-vanilla-vndklite-14.0-20240816.img.xz
Uniform, clear, unambiguous labeling facilitates orientation, serves product transparency and is therefore important.
Idk what’s you’re problem with Andy’s naming rules 
Most TD maintainers use this naming scheme
There is also the slim version RO for smaller patitions
And the maintainer from official RisingOS (Lynix) use this
Then it says e.g. bcgN
- a/b
- core
- gapps
- no superuser
What makes you think I’ve a problem with Andy Yan’s naming rules for variants? His declarations are just as clear as those of @phhusson, @ponces or the maintainer from RisingOS .
iodé.tech uses iode-5.5-20240919-arm64_bvN and iode-5.5-20240923-arm64_ab in its GSI naming, even though the GSI has built-in MicroG in each case. MicroG is therefore not mentioned, although it is implemented. This is not usual in the branch. I would like to draw your attention to this.
Current examples of GSI with MicroG:
LeafOS: leaf-3.2-333-microG-leaf_gsi_arm64-img.zip
VoltageOS-microg-arm32_binder64-ab-3.7-20240915-UNOFFICIAL.img.xz
VoltageOS-microg-arm32_binder64-ab-vndklite-3.7-20240915-UNOFFICIAL.img.xz
VoltageOS-microg-arm64-ab-3.7-20240915-UNOFFICIAL.img.xz
VoltageOS-microg-arm64-ab-vndklite-3.7-20240915-UNOFFICIAL.img.xz
The extremely few GSI distributions that even implement MicroG in their GSI make this clearly recognizable. So why not iodéOS?
iodeOS 5.x GSI with built-in MicroG is an enrichment for the GSI scene, which is teeming with GSI with built-in GApps (“Google Goodies”).
Yeah, that’s true so far, but @AlphaElwedritsch and I used to use LeOS and there was no clear name for the implementation of microG, but we knew that it was integrated and also included AP from iodéOS
I would also think it would be better if the naming clearly indicated that it was integrated
By the way, I just had such a case in a Telegram group where someone asked if iodéOS has microG implementation, I wrote him that it is included
In the end it makes sense in any case
As well as to offer the file as IMG.xz for download and not as ZIP, because ZIP’s are actually only used for ROM’s and not for GSI’s
Yeah, @AlphaElwedritsch, you and I know what we get with iode-5.5-20240923-arm64_ab - a GSI image with built-in MicroG. But it’s not obvious to other interested parties at first glance, as you just told us yourself.
If an interested person reads What are GSIs and how to install them? on the iodé website, they won’t find a single syllable about MicroG. Why? What are the real reasons why MicroG is not mentioned?
That the leading head of the Lineage Android Distribution (LOS) @npjohnson is not a friend of MicroG, but of ‘Google Goodies’ GApps à la MindTheGapps, can be read in his XDA threads.
I agree with you 
You could call it something like the other maintainer in your previous post, or just
bfvN
-a/b
-microG
-vanilla
-no su
or
bmvN
-a/b
-microG
-vanilla
-no su
microG is mentioned here
The flash guide should also work on
We use this at Telegram
FOR CLEAN FLASH
FOR DIRTY FLASH
1 Like
Telekom T Phone Pro (Lion) 6/128 GB
MediaTek Dimensity 700 (MT6833)
Stock Android 13.0 Bootloader unlocked | Kernel version 4.9.191+
iode-5.5-20240923-arm64_ab (with built-in MicroG) via DSU Sideloader
iodéOS 5.5 GSI via DSU Sideloader works fine. But it does not work for me,
to install any GSI arm64_ab in the classical way (see above: Clean Flash), because - as soon as I’m in fastboot mode and switch to fastboot'D' mode (fastboot reboot fastboot), the bootloader is locked again(!) I get an error message like ‘not allowed in Lock State’
@Der_Baliner do you have a tip for me?
I’ve never experienced bootloader suddenly being locked again in this state on any other device, not even on the “little brother” T Phone 5G (Jaguar) [see post #30]. There must be some diabolical security mechanism at work here.
Side note: The bootloader of the ‘Lion’ with stock Android 14 can no longer be unlocked using the MTKClient [ DA version 1.0 ].
1 Like
Telekom T Phone ‘2’ 5G (Puma) 6/128 GB
Qualcomm Snapdragon 6 Gen. 1
Stock Android 14.0 | Kernel version 5.10.185
The classic unlock commands fastboot flashing unlock or fastboot oem unlock don’t work. I suspect that a special manufacturer unlock code is required. What other way is there to unlock the bootloader?
Because every IodéOS ROM - GSI or device-specific - includes microG. Same is true for e.g. /e/OS: all their GSI images include microG, but it is not mentioned in the image name because there is no /e/OS build without microG. LineageOS for microG builds do include microG in the name, to distinguish them from official LineageOS builds which do not include microG. There is no build of IodéOS that does not have microG, so no need to mention it in the ROM name.
But there is no such thing as a ‘vanilla’ build of IodéOS without microG, or a build of IodéOS with ‘su’. someone chose to make such a build, then they should mention in in the name, but it is just not necessary or useful for normal builds of IodéOS
I understand your reasoning. Nevertheless, it makes sense to speak plainly, because for us iodéOS friends everything is clear, but not for newcomers, as various installation requests for GApps or MicroG clearly show.