[GSI][13] LineageOS 20 "Light"
- Thread starter AndyYan
- Start date
I did it without any issue.
GSIs based on same version of Android, you can switch them by dirty flash.
Well, so that isn't the issue caused by dirty flash. It's the issue of compatibility of your device and the ROM.
I was able to switch between ArrowOS, crDroid, LOS 20 TD and LOS 20 Lite with dirty flash without any issue on my Moto g30.
But other GSIs I tried won't boot even with clean flash.
most GSIs boot for me unless they need a modded vendor... will try a clean flash later today.
hi! just installed.
1. experienced failing Networking, fixed with restricted_networking_mode off
2. Bluetooth headset doesn't play music. I remember fixing it on LOS-19 by disabling a2dp offload. Now I see it disabled by default [persist.sys.phh.disable_a2dp_offload]: [true]. Hmm. What shall I do?
Having MTK phone (A11 vendor). Model AGM H3. ROM Testing 20221109-personal
@AndyYan , thanks a lot for this ROM!
1. experienced failing Networking, fixed with restricted_networking_mode off
2. Bluetooth headset doesn't play music. I remember fixing it on LOS-19 by disabling a2dp offload. Now I see it disabled by default [persist.sys.phh.disable_a2dp_offload]: [true]. Hmm. What shall I do?
Having MTK phone (A11 vendor). Model AGM H3. ROM Testing 20221109-personal
@AndyYan , thanks a lot for this ROM!
I've had a bunch of reports of "Light" failing on Xiaomi/Redmi devices, but none detailed enough (log while bootlooping would be nice). My own Civi is working well, but it's on a slightly older MIUI12 R vendor. It does interest me when "modern" devices wouldn't boot "Light" - perhaps I should grab one of the reported devices and see for myself...
Unimplemented yet, I'll check if they're as simple as a prop + a single platform-side change, and if so I'm okay with adding them next.
I am not sure this is related or not, but I just tried to DSU the light GSI as a simple way to grab some logs. But it just fails.
The command I used was:
Code:
adb shell am start-activity -n com.android.dynsystem/com.android.dynsystem.VerificationActivity -a android.os.image.action.START_INSTALL -d file:///storage/emulated/0/Download/system.img --el KEY_SYSTEM_SIZE 3350601728 --el KEY_USERDATA_SIZE 8589934592Has anyone been able to boot this GSI in this way?
It's actually implemented. But there's a bug: https://github.com/phhusson/treble_experimentations/issues/2480
So setting to false fixed the issue.
But the real big problem is that it seems to not support the Signature Spoofing a.k.a. FAKE_PACKAGE_SIGNATURE. So MicroG doesn't work.
Right?
Right?
I'm using zygisk LSPosed module and fake gapps module with the light build, everything seems to be working OK, all boxes ticked. I'm using nogoolag microG tho.
DSU immediately failing likely indicates something's wrong with your parameters - logcat should tell you exactly what.
It's not... It's a "phh"-series prop, and had such been implemented in "Light", they'd be under a different name.
Noted, but again, I'd prefer not to expand "light" excessively. If TD-based works better for you, simply switch to that.
1. lptools is a matter to ~50kB. Shouldn't disturb the "lightness" ))
2. MicroG is very honored in FOSS community, strongly recommended. And again, AFAIK it's a very light patch, yet strongly recommended.
I'll definitely try the TD LOS20 but I'm sure I'll miss your "personal" patches because my FP sensor is crap.
thanks!
a little too insisting, sorry. Vote results at https://forum.xda-developers.com/t/gsi-12-lineageos-19-x-gsi-a64b-64b.4358041/
I don't use GAPPS at all: 42%
I don't use GAPPS at all: 42%
I have just tried it again and it worked. The main difference is that previously I was on stock, now on ArrowOS, but I cannot rule out some error on my side previously.
The GSI used was lineage-20.0-20221109-UNOFFICIAL-gsi_arm64_gN-secure.
For the record:
Code:
adb shell am start-activity -n com.android.dynsystem/com.android.dynsystem.VerificationActivity -a android.os.image.action.START_INSTALL -d file:///storage/emulated/0/Download/gsi.img.gz --el KEY_SYSTEM_SIZE 3350601728 --el KEY_USERDATA_SIZE $((8*1024*1024*1024))As for the debug part, could you please point to docs or explain how to generate useful logs in this scenario?
My short report on testing the ROM on my AGM H3 (MTK):
1. Works almost perfectly.
2. BT stack crashes with some headsets. Similar to https://github.com/phhusson/treble_experimentations/issues/376 but I didn't check the logcat yet.
3. BLE doesn't connect until scanned, https://github.com/phhusson/treble_experimentations/issues/2413
4. NFC not detected, https://github.com/phhusson/treble_experimentations/issues/1073
Actually the bugs are the same as with the Phh's AOSP 12 and TD ROMs.
If anyone has an idea how to fix those, plz raise the voice. Thanks,
1. Works almost perfectly.
2. BT stack crashes with some headsets. Similar to https://github.com/phhusson/treble_experimentations/issues/376 but I didn't check the logcat yet.
3. BLE doesn't connect until scanned, https://github.com/phhusson/treble_experimentations/issues/2413
4. NFC not detected, https://github.com/phhusson/treble_experimentations/issues/1073
Actually the bugs are the same as with the Phh's AOSP 12 and TD ROMs.
If anyone has an idea how to fix those, plz raise the voice. Thanks,
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
7Updated all variants with January security patches. [Insert obligatory backup-and-test warning here]
Some users have reported that securize bootloops their device, and the current "integrally securize" approach means they can't boot up even once. This month I've changed it yet again to "securize on-demand", which is similar to how you securize on PHH/TD-based (a toggle in Treble Settings), but reversible and doesn't require SU.
For new users who are unsure about whether securize might bootloop your device, please turn on USB Debugging and Rooted Debugging below it, and if/when you do hit a bootloop on the next boot, you'll have a rooted ADB shell available to you, from where you can toggle off manually:
For users who are already on a gN build, be sure to toggle it on and reboot right after you update!Code:adb root adb shell setprop persist.sys.treble.securize false adb reboot
Also implemented:
- Override minimum brightness - @Captain_cookie_200
- Override navbar availability - @pbgapski
- FDE and unencrypted data - @DerTeufel1980 - given that yours is actually a legacy device, I recommend just using TD-based instead (I was hit by CoV last month and skipped an update; I'll update it in a few days). Thank you for understanding.
Fixed an oversight that caused Settings to not have a search bar.
And finally, I've examined / received reports about 2 Snapdragon 8 Gen 2 (SM8550) devices which have a common bug of no call audio. This one's gonna take me a while to figure out (AIDL coding-wise), but since SM8550 isn't going international very soon, I won't rush it.2
1. Try light first, then trebledroid.
2. The whole idea of GSI is that there's no firmware in /system. You're supposed to use gsi with stock everything. You can use xiaomifirmwareupdater to get both latest stock firmware and /vendor
3. vndklite is for some legacy devices.2
Indeed that switch needs a re-toggle (most devices do have a navbar on first boot, so I coded it to default ON when it isn't set), plus a reboot, to come into effect.
The basis of this (again, inherited from PHH) is the ubiquitous "qemu.hw.mainkeys" prop which has very high priority in the framework and also shouldn't be touched by non-emulator vendors. If even that doesn't work, then your device has a really rogue vendor...
That's how non-Securized g* builds have always been, and why I made "integrally securized" earlier...Me (moto g30) too....
↓
If it keeps appearing even after Securizing, just silence it by long pressing, GAPPS will start to work regardless.1
To regular users, "Light" will have generally worse device support, but due to what's already mentioned in OP plus my favoritism towards it, will get updated easier and faster. I guess that's it? So yeah, I actually would like people to use TD-based, if that means one less not-so-elegant patch in "Light".
For some of the devices I use, see the forum signature. Nowadays I tend to choose form (aesthetics) over function (specs/value), so even though I can obviously afford a large fleet, I intentionally miss many popular ones like Redmi Notes.1 -
23
MUST-READ BACKGROUND - Android 13 and the two approaches:
As some of you already know, due to various reasons, @phhusson , who kickstarted the GSI trend and committed to it over the years, is backing out from future development - there won't be any AOSP 13+ builds or patches directly from him. He did most of the heavylifting for fixing bugs and implementing features, and selflessly supported more than his AOSP GSIs and more than devices he own. For the situation of GSIs today, we owe him a big thank-you.
Since PHH made up his mind, a number of existing builders incl. myself have formed the TrebleDroid organization, with PHH himself helping us in technical issues. TD will forward-port PHH's final patches (v415) onto Android 13 and attempt to fix new issues. This is still a new and ongoing process, but if done right, will have compatibility and feature-completion on par with past PHH-based GSIs.
Meanwhile, I'm aware that at least I myself am not as capable as PHH, and won't be able to look after the myriad of patches and devices, esp. legacy ones (pre-A10). Therefore, inspired by @PeterCxy , I'm taking a different approach - start over from AOSP's generic gsi_* target, add in the minimum amount of fixes needed for my own devices, shaking off much of the legacy burden in the process and making it easier for myself to follow/maintain. This is a radical, selfish approach that by definition won't work for legacy devices anymore, and won't work as well as PHH-based GSIs that you've come to love either. However, I've fixed it up to my own daily-driver standards, and I figured it should still be of use to many. For now, I call this the "light" approach.
Disclaimer:
No flashing instructions will be offered. If you're here in this forum, you should know what you're doing.
No guarantees that everything would work. This is a GSI, bugs are bound to happen.
The selfish nature of this approach means I can and will ignore certain bugs as I see fit. Deal with it or kindly go try something else.
Download:
https://sourceforge.net/projects/andyyan-gsi/files/
Scroll down for the naming rules of variants.
Compressed as .xz archives - extract first.
Stuff on GitHub (builders-only):
Most things should be self-explanatory. Not the cleanest code, but should help if you need some clues.
- lineage_build_unified - my unified script for building
- lineage_patches_unified - my unified patches for building
- device_lineage_gsi - my device tree that extends native generic targets
- The LineageOS team - helping me out even when they don't offer GSIs themselves
- @phhusson - shaped the treble community, and even the "light" approach uses his fixes/infra extensively
- @PeterCxy - inspired me with his personal-use GSI, and coded critical fixes such as sysbta
- ...and more
https://paypal.me/AndyCGYan7Updated all variants with Android 13 QPR1 and December security patches. [Insert obligatory backup-and-test warning here]
As usual with "feature drops", things can change or break majorly.
Newly implemented:
- Disable A2DP offload
- Alternative audio jack detection
- Signature spoofing for priv-app (just like in PHH/TD-based)
- Optional FP lockout (set persist.sys.fp.lockouts.disable to true to disable timeout on failed FP attempts)
- Built-in PHH-SU app for *S variant
Rejected:
- Force headset audio (slightly harder to implement, and not proven effective outside of Huawei)
- lptools
7Updated all variants with November security patches. [Insert obligatory backup-and-test warning here]
As teased a few days ago, here's a gN build with MindTheGapps, plus both vN and gN are now "integrally securized", for better chances (but not guaranteed) to pass SN. OP will be updated to reflect these changes.
A "personal" build has also been uploaded to Testing.
I'd like to once again remind you that "light" will remain a selfish approach. For other needs e.g. Samsung oddities, please wait for the TD-based batch which I'll make a thread for shortly, see if that would scratch your itch instead.7Updated all variants with January security patches. [Insert obligatory backup-and-test warning here]
Some users have reported that securize bootloops their device, and the current "integrally securize" approach means they can't boot up even once. This month I've changed it yet again to "securize on-demand", which is similar to how you securize on PHH/TD-based (a toggle in Treble Settings), but reversible and doesn't require SU.
For new users who are unsure about whether securize might bootloop your device, please turn on USB Debugging and Rooted Debugging below it, and if/when you do hit a bootloop on the next boot, you'll have a rooted ADB shell available to you, from where you can toggle off manually:
For users who are already on a gN build, be sure to toggle it on and reboot right after you update!Code:adb root adb shell setprop persist.sys.treble.securize false adb reboot
Also implemented:
- Override minimum brightness - @Captain_cookie_200
- Override navbar availability - @pbgapski
- FDE and unencrypted data - @DerTeufel1980 - given that yours is actually a legacy device, I recommend just using TD-based instead (I was hit by CoV last month and skipped an update; I'll update it in a few days). Thank you for understanding.
Fixed an oversight that caused Settings to not have a search bar.
And finally, I've examined / received reports about 2 Snapdragon 8 Gen 2 (SM8550) devices which have a common bug of no call audio. This one's gonna take me a while to figure out (AIDL coding-wise), but since SM8550 isn't going international very soon, I won't rush it.6Notes:
- I now have a rather taxing day job, and can't devote nearly as much time/effort into this as I did as a student, or even a year ago.
- No A-only or VNDKLite builds. These are concepts that don't exist natively.
- GAPPS builds are offered as-is without guarantees. As a Chinese I can't/won't help with GAPPS/SN issues - please help each other out.
- ADB is intentionally insecure, even on first boot (turned on by default and no authentication needed). GSIs are more fragile compared to device-specific custom ROMs, both on first boot (no-boot issues) and on subsequent boots (after tuning certain Treble settings), and I insist that no-auth ADB is a must-have for debugging and general fail-safe.
- Signature spoofing (MicroG) is supported, but only for priv-apps. This is a security consideration from PHH.
- Refer to #9 for explanation/workaround of an MediaTek-specific kernel bug that causes no internet.
