[GSI][13] LineageOS 20 TrebleDroid-based

[AndyYan]

@AndyYan Your gsi & phh's trebledroid, are the only ones that are able to load my device overlay from phhusson's vendor mate. None of the other A13 GSIs able to. Any reason for this ?
And trebledroid throws unsupported magisk version, but none of the other GSIs have that issue. That's strange too.

Nothing weird about these.
The former is because I fixed and integrated the overlay matching patch ahead of notifying PHH, then PHH pushed it to TD and made a CI, and it hasn't trickled down to other ROMs just yet. Kinda proving point 3 in #2.
The latter is pure PHH/TD doesn't have /sbin-related patches necessary for Magisk, but it's half Magisk's fault (intentionally neglecting GSI usecases).

 

[MPK99]

Nothing weird about these.
The former is because I fixed and integrated the overlay matching patch ahead of notifying PHH, then PHH pushed it to TD and made a CI, and it hasn't trickled down to other ROMs just yet. Kinda proving point 3 in #2.
The latter is pure PHH/TD doesn't have /sbin-related patches necessary for Magisk, but it's half Magisk's fault (intentionally neglecting GSI usecases).

Nice. Which means one more monthly update iteration is enough for all GSIs to get overlay matching patch right?

 

[pommefrite8]

Hello,

Firstly thank for your work, it's amazing.

Do you know why when we run with "lunch lineage_gsi_arm64_vN-user" during the compilation we get the error below.
Because it security issue, no ?

FAILED:
In file included from system/libvintf/Android.mk:18:
system/sepolicy/Android.mk:85: error: SELINUX_IGNORE_NEVERALLOWS := true cannot be used in user builds.

Thanks

 

[K-BOX2022]

Hey. He has a problem with Lemfo T. On this Lineage os terribly stutters audio, animations are very muddy, terribly everything goes slow. I tried turning off animations but it didn't do anything. I need to catch some tweaks or something else to make it usable?

 

[prazola]

Hi, is this quick settings behavior expected?

It happens in both Los 19.1 and 20.
I would like to reduce the tiles per row to 3 or 2, as 4 is quite busy and unreadable.

Phone: Umidigi S5pro

EDIT:
Problem solved using Debloat app to mask out vendor apps.

 

[ildar_prophet]

Anyone has NFC working with Andy Yan's LineageOS ROMs? or with Phh's AOSP ROMs maybe?
I see it's failing badly, suspect it's the common problem.

 

[pbgapski]

Anyone has NFC working with Andy Yan's LineageOS ROMs? or with Phh's AOSP ROMs maybe?
I see it's failing badly, suspect it's the common problem.

I have tested both TD and light lineageos 20 GSIs and NFC does not show up in both (poco f4).

 

[psychofaktory]

In Xperia 10 III (latest Firmware) with lineage-20.0-20221111-UNOFFICIAL-arm64_bgN-vndklite-secure NFC ist working great.

 

[ildar_prophet]

thanks for that.
It looks problems with NFC are due to missing parts in /vendor.

 

[bentalebnordine]

The best root strategy for gsi roms is to install a bvn or bgn rom then patch the boot image with magisk, it's better than a built-in phh su because phh su do not allow r/w system
And also installing bvs with patched boot would cause interference between pph su and magisk su

 

[ildar_prophet]

because phh su do not allow r/w system

Nonsense! With Phh SU I easily modify /sysytem: install /system/etc/hosts with AdAway blocking , install MicroG with unofficial installer.
It just may be narrow in free space. But that's fixed with lptool (carefully).

then patch the boot image with magisk

You may not know but that's not successful with all the phones. Your mileage may vary.

 

[ykom]

Can it be dirty updated? How can it be done?
Thanks!

 

[AnonVendetta]

The best root strategy for gsi roms is to install a bvn or bgn rom then patch the boot image with magisk, it's better than a built-in phh su because phh su do not allow r/w system
And also installing bvs with patched boot would cause interference between pph su and magisk su

I think that part of what you're saying can't be right. My boot.img is patched with Magisk Delta. However, if I install a gsi that has phh su, the Magisk always get overridden by the phh su. Presumably they're both trying to use /system/bin/su as the su binary, obviously both can't coexist at the same time. So phh su takes precedence. However, if I delete the phh su files (from TWRP), Magisk is able to work.

And if I manually create /sbin and add sbin to the path statement in /init.environ.rc, Magisk overrides phh su, but grumbles that it exists. This is because /sbin has priority over /system/bin in the path order, so /sbin/su is found first.

 

[AndyYan]

I think that part of what you're saying can't be right. My boot.img is patched with Magisk Delta. However, if I install a gsi that has phh su, the Magisk always get overridden by the phh su. Presumably they're both trying to use /system/bin/su as the su binary, obviously both can't coexist at the same time. So phh su takes precedence. However, if I delete the phh su files (from TWRP), Magisk is able to work.

And if I manually create /sbin and add sbin to the path statement in /init.environ.rc, Magisk overrides phh su, but grumbles that it exists. This is because /sbin has priority over /system/bin in the path order, so /sbin/su is found first.

This here.

Many non-AOSP PHH-based GSIs incl. mine already have this /sbin patch, therefore Magisk kinda works on *S. The existence of PHH-SU can still fail detections though, and that's where secure or *N is really needed.

Can it be dirty updated? How can it be done?
Thanks!

Just flash an update like you would the original, nothing else.

 

[AnonVendetta]

This here.

Many non-AOSP PHH-based GSIs incl. mine already have this /sbin patch, therefore Magisk kinda works on *S. The existence of PHH-SU can still fail detections though, and that's where secure or *N is really needed.

Just flash an update like you would the original, nothing else.

I've noticed some peculiar behavior when Securizing on non-secure GSIs (tried on a few already):

If I install the phh su app (on a gsi that already has the binaries but lacks the app), securizing causes the ROM to softbrick. And not even a factory reset will allow it to boot again.

If i leave Magisk in /system/bin (by not creating sbin and adding to path), securize appears to work but silently fails (the phh-securize.sh file is still present after reboot, securize is supposed to delete it). I suspect Magisk "locks" the directory and reverts changes.

If I create sbin and add it to the path, Magisk migrates to sbin and securize succeeds. It reboots normally without softbricking.

On an unrelated note, I've tried your TrebleDroid (non-light) on my Galaxy Tab S7+ and a Galaxy Note 20 Ultra, it fails to boot on either device. It's strange, since phh's Android 13 appears to be based on your sources, but boots fine. I wanted to check on the exfat thing again, but can't since boot fails.

 

[ykom]

"Just flash an update like you would the original, nothing else."

Thanks Andy,

My phone has no twrp and I have to use ADB. When updating OS19 to OS20, I have to ease the system and personal data, so it was a clean installation. I'm not sure that OS20 can be updated without easing the system and data.

 

[AndyYan]

On an unrelated note, I've tried your TrebleDroid (non-light) on my Galaxy Tab S7+ and a Galaxy Note 20 Ultra, it fails to boot on either device. It's strange, since phh's Android 13 appears to be based on your sources, but boots fine. I wanted to check on the exfat thing again, but can't since boot fails.

I wonder if that's because I now integrally securize *N - I've had one report of that not booting on some other device. Did you try *N or *S?

 

[AnonVendetta]

I wonder if that's because I now integrally securize *N - I've had one report of that not booting on some other device. Did you try *N or *S?

I can't remember. It's been over a week. The only thing I can remember for sure is that it was a vndklite 11-11 build, because I refuse to try gsis that don't have that "flavor" available.

About the pre-securized gsi thing, they do boot for me. I've tried Pixel Experience (secure during build time) and secure phh Android 12 gsis. No issues with any of them.

 

[V0latyle]

I wonder if that's because I now integrally securize *N - I've had one report of that not booting on some other device. Did you try *N or *S?

Can confirm on my T290. All *N builds bootloop - they get to the splash screen, in some cases the setup screen, but eventually crash and reboot. No idea why.

Only the *S flavors work for me, but since I'm a Magisk user, I was hoping to just patch the unrooted builds.

I've noticed this is true with your older builds, too - 18.1 and 19.1, only the S variants are stable.

Any plans to do a *gS flavor for 20.0?

 

[AndyYan]

Any plans to do a *gS flavor for 20.0?

I only just killed that... I hate excessive variants that are almost identical.
I'll see if making "secure" a toggle (instead of forcing it) works. In PHH AOSP, the SU app and binaries are universally preloaded, and Securize was a one-way trip. Now that it's only some props to be reset, I reckon it might work as a toggle. OR, I might as well grab one of the broken devices and see just which "secured" prop is breaking it. Either would push back the next release further though.

I've noticed this is true with your older builds, too - 18.1 and 19.1, only the S variants are stable.

Only the most recent 19.1 update has *N, and 18.1 never had it. What they've had all along is VNDKLite "secure" builds. Please confirm if you meant that instead?