[GSI][12] LineageOS 19.x GSI (A64B/64B)

What's your status on GAPPS and SafetyNet?

  • I use GAPPS and passed SafetyNet with Magisk, etc.

    Votes: 10 20.0%
  • I use GAPPS and can't pass SafetyNet - I probably need a VNDKLite or "secure" build

    Votes: 12 24.0%
  • I use GAPPS as-is and don't care about SafetyNet

    Votes: 7 14.0%
  • I don't use GAPPS at all

    Votes: 21 42.0%

  • Total voters
    50
  • Poll closed .
Search This thread

jamadz15

Member
Feb 5, 2015
42
6
Hi, in my experience GSI is (probably) always without in build sounds, at all.....you just download some ringtone/notification jingle from browser, from Zedge for example, and set it as ringtone or notification sound.
Actually, that's not the issue I meant, when I'm making a messenger calling there's no audio on the phone nor on the speaker
 
  • Like
Reactions: autokoise

Novhytha

Member
Jun 24, 2014
8
1
why i cant pass safetynet even its securized?
i was changed ro.control_privapp_permissions to enforce but it cant helped

but i can pass safetynet in phh gsi,
any way to fix safetynet in this gsi?
 
D

Deleted member 12251071

Guest
does anyone have a memory leak in surfaceflinger?

I have also a memory leak in "system_server", i must restart my phone everyday to mitigate this issue
Same here.

But there's a fix for this issue:
cc @AndyYan

It looks like next builds will be LineageOS 20. :unsure:
 
Last edited by a moderator:

nisfta

Member
Oct 1, 2022
13
0
I installed the GSI via DSU loader, but there is no MAC randomization (even with 'Wi-Fi non-persistent MAC randomization' turned on). Will randomization work if I flash the GSI the proper way (through recovery)?
 

Virteal

New member
Feb 26, 2014
3
0
Hello, after flashing Lineage OS 19.1 20220912 arm64_bgS on my Doogee S68Pro my sim is not working. When I tried version 18.1 a long time ago, I couldn't make calls, only receive calls. In version 17.1 everything always worked for me without any problem. Do you have any solution? I wouldn't mind if, for example, the bluetooth didn't work, but if the sim doesn't work, it's a big problem especially with a mobile phone. Thanks
 
@AndyYan Is there any explanation for why you only ship bvS/bgS ? Why not N ?
Why only pre-rooted builds which has no user functionality advantage ?

No one shouldn't be supposed to ship pre-rooted ROMs & GSIs. Root is a choice that has to be taken by users themselves. bvN/bgN builds give users chance to flash magisk upon their will. Pre-rooted builds slow that process down & give issues to newcomers. It's also against user's security.
 
Last edited:
D

Deleted member 12251071

Guest
@AndyYan Is there any explanation for why you only ship bvS/bgS ? Why not N ?
Why only pre-rooted builds which has no user functionality advantage ?

No one shouldn't be supposed to ship pre-rooted ROMs & GSIs. Root is a choice that has to be taken by users themselves. bvN/bgN builds give users chance to flash magisk upon their will. Pre-rooted builds slow that process down & give issues to newcomers. It's also against user's security.
Isn't it clear?

From https://github.com/AndyCGYan/lineage_build_unified

Note: VNDKLite and Secure targets are generated from built images instead of source-built - refer to sas-creator.

Generate secure targets isn't difficult and only take a few minutes.

Also,
GSI is not a device-specific custom ROM.
Users should not assume that this rom is perfect.
We (users) need to create overlays and/or make changes and we need to test it.
For that we (users) need root and the ability to remount partitions.
 
I know about sas creator mate. My point isn't about difficulty. I myself created overlays that got merged in vendor before.
I wanna know what made Andy decide to ship only bvS/bgS bydefault (on his sourceforge).
SU from bvS/bgS is simply unusable & has no applicable advantage to any user. Manually flashing Magisk is currently a root standard & works perfectly on non root builds out of the box (I know Magisk discussion isn't preferred in GSI threads. But it's truth)
For every update, one wouldn't always execute sas creator, it's already another step overhead on top of installation. bvN will ease that, is all what I'm saying.
Every other GSI dev provides non root builds, except Andy, which seemd so strange.
 
  • Like
Reactions: ChristianWS
D

Deleted member 12251071

Guest
SU from bvS/bgS is simply unusable & has no applicable advantage to any user. Manually flashing Magisk is currently a root standard & works perfectly on non root builds out of the box (I know Magisk discussion isn't preferred in GSI threads. But it's truth)


Every other GSI dev provides non root builds, except Andy, which seemd so strange.
Waste of bandwidth?
 
Last edited by a moderator:
That isn't ignorable. Magisk would still use su binary in the backend instead of it's own (which is the reason it shows conflict). Both binaries are completely different, even though they provide same usecase.
It ain't that hard for a single dev to spare couple more builds to upload. Caz thousands of users gonna save their time by not sas creating non root builds on every update.
You're literally saving thousands of collective minutes of all users by just uploading couple more builds.
It's not a waste of bandwidth, right now it's a waste of time.
 

AndyYan

Recognized Contributor
Jan 30, 2012
4,551
3,992
Beijing
@MPK99 Building *N is a community concensus (vote) made back in A10 days. You made some good points, so I'm opening a vote once again, however I should also rebut some of them:
SU from bvS/bgS is simply unusable & has no applicable advantage to any user.
  • It's /system-based and therefore works unconditionally even on devices that don't play well with Magisk (notably, Samsung).
  • It's simple and "just works", like any pre-Magisk-era root manager. Pushing files, running root commands from apps (not just adb shell), etc. Call me an old timer, but I don't need Magisk modules.
  • It also serves to enhance debugging or recovering from bootloop situations, though this is admittedly less of a user advantage.
It ain't that hard for a single dev to spare couple more builds to upload.
My ~400KB/s upload bandwidth would disagree, and I can't negotiate that due to where I live.
Likewise, my 1TB SSD juggling A12, A13 LOS, A13 AOSP sources plus their ccache would like to catch a breath. I don't request or live on donations, but I also lack an incentive to expand my storage further.
Andy perhaps you can add eremitein patch to support dynamic root
I'm pretty sure there had been more than one user in the past who voiced their objection to *Z citing its issues...
 
@MPK99 Building *N is a community concensus (vote) made back in A10 days. You made some good points, so I'm opening a vote once again, however I should also rebut some of them:
Tq for considering this mate.
My ~400KB/s upload bandwidth would disagree, and I can't negotiate that due to where I live.
Likewise, my 1TB SSD juggling A12, A13 LOS, A13 AOSP sources plus their ccache would like to catch a breath. I don't request or live on donations, but I also lack an incentive to expand my storage further.
Haven't thought of your specs btw. I had the same issues when I was building stuff for some devices. There are some large repositories that are common on all Android releases. They need to get symlinked. And ccache doesn't need to be on SSDs. Affordable way is to use hard drives, since read speeds are almost the same when data is stored sequentially.
Call me an old timer, but I don't need Magisk modules
I can understand you andy, but as we know, that majority of the users are just lazy, so they prefer Magisk over any other script/procedure/solution...XD
 

AndyYan

Recognized Contributor
Jan 30, 2012
4,551
3,992
Beijing
XDA doesn't seem to allow creating a new poll over the existing, so here it is hosted off-site: SU poll (2022)

I doubt that I actually have thousands of active users, let alone who checks XDA, but hey, let's hear it! It'll be open for roughly a week from now.
There are some large repositories that are common on all Android releases. They need to get symlinked. And ccache doesn't need to be on SSDs. Affordable way is to use hard drives, since read speeds are almost the same when data is stored sequentially.
I've tried the "--reference" feature of repo command back when I built both GSI and device-specific in separate workspaces - they used the exact same sources and it should've saved me almost all the space, but in the end the saving wasn't large enough as anticipated, and it got annoying to maintain when I wanted to move or delete one of them. I assume it'd get even messy if I cross-reference/symlink between Android versions or AOSP/LOS.

I work and play on a single laptop that has respectable specs but (by nature) limited expansion - no HDD slot, both SSD slots occupied. Heck, I now rely on a small external SSD over USB to contain occasional non-current sources such as TWRP. Maybe A14 will break this fragile storage balance again and force me to migrate to a bigger SSD...
 
First thanks to the great work. I flashed a a600f with the GSI, new Vendor and new Kernel. It is running fine. But I cannot pass any saftynet checks and of course not the google play certification. I tried a lot. Shortly also with Magisk, safetynet fix, MagiskHidePropsConf (with original fingerprint from the a600f) and busybox it will not pass basic and cts check. I tried to remove the prebuild SU but without success. So for me it will be interest to get a lineage-19.1-2022xxyy-UNOFFICIAL-a64_bgN-vndklite (or bvN) version to test, if the problem will be the buildin SU or something else.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    Right now, for people who don't want built-in SU, I make post-processed "secure" builds. During post-processing they lose EXT4 shared blocks and therefore become a lot larger (~1.7GB -> ~2.5GB). I wonder if any of you have really small, non-dynamic (i.e. can't be resized) /system that can actually benefit from a "natively" no-SU build, e.g. *N? I've experimented with "securizing" at build time with success, so I'm ready to build such.
    2
    Updated all variants with November security patches and in sync with PHH v416. [Insert obligatory backup-and-test warning here]

    Now building vN/gN natively, and they're "integrally securized". Also, on LOS20 there were 2 reports of *N killing USB Debugging altogether, which I wasn't able to replicate. I've made test builds for them that stops securing the USB bits, but they weren't able to confirm for me. Therefore, I've applied the same to this batch of LOS19, in hopes of finding out. Even though I'm not well-suited to deal with GAPPS/SN issues, let me know nonetheless if you hit regressions.
    1
    With or without my patches ?
    Tested without - just PHH's vold patches + LOS's exfatprogs.
    1
    And in attempting to try it on a 3rd device (a Samsung), its card tray somehow got stuck, likely needing a disassembly, rendering it half-useless.
    Sorry @AnonVendetta , but now I neither have a suitable device for, nor am in the mood to debug exfat on Samsung.
    I now hate Samsung even more...
  • 29
    640px-Lineage_OS_Logo.png


    Background:
    This is a natural continuation/extension of the LineageOS 18.x GSIs I've been making since 2020.
    LineageOS is a free, community built, aftermarket firmware distribution of Android, which is designed to increase performance and reliability over stock Android for your device.
    LineageOS is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. LineageOS does still include various hardware-specific code, which is also slowly being open-sourced anyway.
    All the source code for LineageOS is available in the LineageOS GitHub repo. And if you would like to contribute to LineageOS, please visit Gerrit Code Review.

    Disclaimer:
    This is still mostly a LineageOS team / PHH @phhusson effort, credits to them and all associated for making all this possible.
    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.

    Must-read:
    You are STRONGLY ADVISED to try PHH's AOSP of equivalent version FIRST and identify/report issues there, before moving onto other GSIs that are based on his work, including this one.
    If you do find bugs on this GSI and want to report, then you MUST try reproducing on AOSP, and ONLY proceed to report here when it's specific to this GSI. This filters out bugs common to all PHH-based GSIs, which you should let PHH know, not me. I might silently ignore your report if you skip this.


    Download:
    https://sourceforge.net/projects/andyyan-gsi/files/
    Compressed as .xz archives - extract first.

    Stuff on GitHub (builders-only):
    Since builders' stuff aren't really interesting to end users, I decided not to separately document the modifications needed in this post; instead just check out these repos, where most things should be self-explanatory. Not the cleanest code, but should help if you need some clues.
    Donate?
    https://paypal.me/AndyCGYan
    13
    Reserved

    Notes:
    • 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.
    • Naturally, LOS19 is pretty early at this point, and many features are absent or don't work. Heck, I hacked in Gallery and LiveDisplay before LOS people even attempted, just because they're important to me.
    • GAPPS builds are offered as-is without guarantees. Read #10 for more.
    • /system is RO on regular builds and RW on VNDKLite builds. VNDKLite builds can be used on most non-VNDKLite devices as well.
    • Signature spoofing (MicroG) is supported, but only for priv-apps. This is a security consideration from PHH.
    • Magisk support should be on par with A11 (thanks @eremitein). The "abnormal state / unsupported SU" warning can be ignored. For devices that still don't play well with Magisk (e.g. kernel restrictions implemented by OEM), use PHH-SU instead. Install the app and you'll get root for apps.
    • I've picked a few commits from ProtonAOSP to fix global theming (thanks @kdrag0n), and also moved a few useful patches out from my personal build to public. I'm willing to deviate a bit from vanilla LOS to bring them to everyone. For even more personalized mods, check out this sample personal build side-by-side with the patches repo.
    • exfat SD cards still don't seem to work. Any help related to this would be appreciated.
    8
    Updated all variants with March security patches and in sync with PHH v410. [Insert obligatory backup-and-test warning here]

    Lots to say about this build...
    • Backup: We're entering Android 12L / LineageOS 19.1, and you should be alarmed to any major updates like this. Especially if you're a maniac like me who uses this daily, BACKUP EVERYTHING and BRACE FOR WIPE! Out of the 10 devices I flashed 19.x on, 2 of them was unable to update through a dirty flash, prompting me to wipe data. I was lucky that neither were critical, and my daily driver updated smoothly, but don't test your luck.
    • Change of variant names: see 18.1 post.
    • Broken stuff: 12L broke quite a bunch of my changes, as evident by how much I delayed this build to correct them, but even now there might still be ones lingering. Known is statusbar height might be f'd up for devices that have an overlay (Google inverted the definition, I already informed PHH of it), and SearchLauncher on GAPPS variants might be half-working.
    • OTA: This is also the first release to contain PHH's homemade OTA mechanism, implementation info here. Enter the Updater either from PHH Settings, or from Settings - System. However, some known caveats:
      • SourceForge could be stupidly slow when accessed through the Updater
      • No error detection or A/B fallback in case of failure
      • Magisk will NOT work anymore after you take such an OTA
      • Any data wipe will take you back to when you haven't taken any
    ...thus I strongly recommend you stick to the current flow and have a PC by you for updates.​
    7
    Initial builds are based on PHH v400.c and November security patches.
    Sigh, I don't really want to make a thread this early...

    BTW, 32-bit and A-only users, you should really move on.
    7
    Updated all variants with September security patches. [Insert obligatory backup-and-test warning here]

    LOS19 has passed its year mark and now enters low-effort maintenance mode.

    Unfortunately for all waiting out there, PHH isn't working on A13 yet (burnout, etc.), and neither am I (day job, etc.). If you feel thankful to PHH's work over the years and are looking forward to more, please show it by donating to him, perhaps via PayPal ([email protected]).