[ROM][UNOFFICIAL][P][F500,LS991,H81x,US991,VS986] LineageOS 16.0

Search This thread

steadfasterX

Recognized Developer
Nov 13, 2013
6,245
15,484
127.0.0.1
OnePlus 7T Pro
2okPze5.png


Code:
/*
* I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed (like it did for me...).
* Please do some research if you have any concerns about features included in the products you find here before flashing it!
* YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
* Your warranty will be void if you tamper with any part of your device / software.
* Same statement for XDA.
*/

About LineageOS​

LineageOS is a free, community built, aftermarket firmware distribution of Android 9 (pie), 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. Linked below is a package that has come from another Android project that restore the Google parts. LineageOS does still include various hardware-specific code, which is also slowly being open-sourced anyway.


**** These builds are for both: official unlocked and UsU'd devices ****
UsU? http://bit.do/unlockg4

Requirements​

  • Your device need to be unlocked either officially (h815 international or h811) or by UsU
  • Your bootloader stack should be on MM 20p (20x for H811) or higher! (see FAQ #8 for how to upgrade your bootloader stack without lgup BUT for your convenience I have alternatively created TWRP flashable files for that !!!! (click))
  • in particular that means this thread is for:
    F500 (UsU'd)
    H810 (UsU'd)
    H811
    H812 (UsU'd)
    H815 (official unlocked or UsU'd)
    H819 (UsU'd)
    LS991 (UsU'd)
    US991 (UsU'd)
    VS986 (UsU'd)
  • Latest TWRP - PREVIEW build: click
  • Do a full Nandroid backup before doing anything!

Installation​

  1. This single very first step is for UsU'd devices only:
    If you have ever flashed the UsU baseband package: Clean flash the modem partition from your backup in TWRP.
    If you do not know if you ever flashed it simply flash your modem partition again and you can be sure. This can't do any harm.
    If you have no backup:
    - TWRP flashable MM modems (N will not work)
  2. Full clean install as described here (FAQ "#2") is highly recommended. DO NOT REPORT ISSUES when you have skipped that step!
  3. Flash LOS
  4. Optional (f-droid is already included): Flash GApps (9.0 - ARM64) if you like to use google apps
  5. Optional (if you want root): Flash the official LOS root-addon (addonsu-16.0-arm64-signed.zip) or Magisk (ensure you read FAQ #1 when using Magisk though)
  6. Boot (will take a bit on first boot!!!)
  7. Enjoy

Features​

  • Pure LineageOS ROM experience
  • F-Droid included (Open Source alternative to Google Play)
  • Torch workaround included (no root)
  • BT voice FIXED:)

Known issues​

I can't test everything on my own, so a lot of things only show up after a release. That means:
- back up regularly and frequently!
- report issues the issue tracker (see next)
  1. Check the current issues at the github tracker (feel free to help, provide logs etc!
  2. If you find a bug not listed, follow the instructions here and provide me with the logs: FAQ #1

Download​

Get your builds from my leech server
https://leech.binbash.rocks:8008/lineage/16.0/

Note:
  1. Builds are updated as soon as possible. There is no build cycle.
  2. Information pertaining to your device is displayed accordingly.
  3. The current build is the latest for your device.

Changelogs​

  • only at my Telegram group

Credits​

  • LineageOS
  • The Suicide-Squirrel team (ThePiGuy, kessaras, steadfasterX)
  • aoleary
  • WiZaRd981
  • berkantkz
  • sdembiske
  • and more..

Sources​


LEGACY XDA DB info​

XDA:DevDB Information
lineage-16.0, ROM for the LG G4

Contributors
steadfasterX, ThePiGuy, kessaras, aoleary, WiZaRd981, HardStyl3r

ROM OS Version: 9.x Pie
ROM Kernel: Linux 3.10.x
ROM Firmware Required: latest MM / N (exact version is model dependent)
Based On: pure LineageOS

Version Information
Status:
Stable

Created 2019-05-10
 
Last edited:

steadfasterX

Recognized Developer
Nov 13, 2013
6,245
15,484
127.0.0.1
OnePlus 7T Pro
Frequently Asked Questions (FAQ)

Q #01: I want to report an issue. What is the proper way to do so?
I'm glad that you are asking: before doing so check the KNOWN ISSUES topic in the OP and ofc the other FAQ's listed here!
If you encountered a kernel panic follow FAQ #6 in this post instead.
If you have issues with "just" the boot process follow FAQ #7 for a very easy way to grab the boot logs.
if you have an audio issue follow FAQ #10 instead.

If your issue is not listed there click here to proceed:

If your issue is not listed there follow the directions here briefly and I may can fix it.

Often selinux can cause issues so try that at very first:
Code:
adb shell
su
(or "adb root" when enabled in developer settings)
setenforce permissive
Try again and if the issue is gone when in permissive mode: provide me a logcat as described here -> on step 3 I need the SELINUX log (option D)

If that does not solve your issue follow the logcat GUIDE to provide a valid log depending on what your issue is.

Ensure you have done a full CLEAN install before doing so (refer to FAQ #2 for what that means).

Warning: NO SUPPORT when:
- magisk is installed (known to cause issues sometimes - regardless of the ROM or version)
- Xposed is installed (known to cause issues sometimes - regardless of the ROM or version)
If you have installed any of these UNINSTALL or better do a FULL CLEAN install (see FAQ #2) before doing anything else. Often enough these above causes several issues like battery draining, problems on booting and much more. Even when they may work properly you should re-produce your issue without them first and follow the above to grab the log.

Magisk is a great piece of software and besides that it is Open Source which SuperSu never was.
I just saying I do not "support" issues with LOS when you have Magisk installed. Why? It is (like Xposed) extendable with modules (made by whoever) and those can cause billions of issues.
Other then that magisk was sometimes the reason for battery drain etc. Magisk modifies the boot "process" and sits very deep in the system (which is needed to make it work ofc) but that has the potential to make a system/ROM unstable or result in strange behaviors.

so in order to support a specific issue I have to be sure the ROM is in a "clean" state, no magisk, no xposed. The LOS root-addon is tested with LOS and made for it so that is not an issue but for the rest there are so many things which can going wrong..


Q #02: I want to install clean, how? What is a clean install? What is the recommended way to flash a new ROM version?
A clean install ensures that there are no leftovers from any previous install. One can say that there are 2 phases of a clean flash:
1) regular
2) full - when you (still) encounter issues

Usually the regular one is fully ok when flashing a new ROM version but if you encounter strange issues nobody else is reporting or if a release post is recommending it you should do a full clean install instead.

A regular clean install can be done like this:
  • WIPE -> Advanced -> select: System + Cache
  • Flash the ROM
  • reflash root addon/magisk if you want root
  • reflash opengapps if you want to use Google crap

A full clean install needs 2 steps more then the regular:
  • follow the steps for regular clean
  • go back in WIPE -> touch the "FORMAT data" button and type "yes" to format the internal storage (you will LOOSE ALL YOUR DATA - obviously)
  • REBOOT -> Recovery
  • Flash the ROM
  • reflash root addon/magisk if you want root
  • reflash opengapps if you want to use Google crap
It is absolutely recommended to create a backup before and COPYING IT to your PC(!) before doing the above.


Q #03: Are there any plans or a chance of official LOS builds?
TL;DR answer is: no.

Background:
LineageOS has "some" requirements before they accept it to do official builds: device-support-requirements.

For sure we do not met all and the most problematic one will be the kernel reqs as do provide a good battery life and a fast kernel kessaras had made unacceptable (for LOS) changes regarding several parts of that requirement topic. So a new kernel (branch) is needed to remove all the improvements we made which are not accepted. This process alone can take weeks (if you do not want to loose every good thing here). A much easier approach here would be to build a "just working" LOS stock kernel without any improvements and fixes and tell everyone: "Flash LOS, then a TITAN kernel afterwards". So while that might be the easier approach it will nevertheless take time to do that kernel and include the reqs + sec patches to the day.

Besides that a bit work is needed to fulfill some of the others like that.

Other then that and that is one of the most important things here:
Even when the device was accepted going official in the past (14.1... long time ago..) an incredible amount of changes happened to get oreo and now pie running. All these will be put to the test. Which actually means every commit we made will be discussed (worst case, yea, but ..) and changed. That can be from a simple "the commit message is wrong" to "pls re-write the code here". You maybe get an idea that this process is nerve-wracking (for me) and costs a lot of my free time.

Before RIL has been fixed (which had happened in the end of June 2019 first) it would have been impossible, I guess.

Now the base is fine, we could put a big amount of time into going to official to get finally ........ yea, what?
Well.. I would free resources on my build and leech server (I don't care - atm)
I would save bandwidth (I don't care - atm)
I would not need to tamper around anymore with (i.e jenkins) build issues (I don't care - atm)
you?
you would get a (LOS signed) build with a slow kernel, bad battery life and all the goodies missing... unless I build LOS kernels to bring those things back.
ok but to be honest. I can fully understand that request and I would feel better by myself when I were you. You do not know me so are my builds trustworthy ? Who knows. I could be a bad guy. :fingers-crossed:
Besides that I wrote above "I don't care - atm" so that might change in the future right? Correct.. there is no guarantee how long I can provide new builds or offer them on my leech server. There is nothing at the horizon that this might change soon but who knows? I can say that I am incredible happy with my OnePlus 6T and - believe it or not - I run STOCK OxygenOS here.. Why? It is just enough for me. So no need to do any dev there - which means all my dev time is still going here - to the G4. It is also a personal project to learn stuff around the Android eco system and woa.. who knows maybe Q came one day to the G4 as well.. :rolleyes:
... and yea official builds would give you some kind of guarantee that builds will happen - while that might change with my unofficial builds some day.

So.. as said in the TLDR above: No I personally do not have any plans in going official for the described reasons.
If someone else wants to go that way and needs help, I am here. But I cannot spend my whole free time on that.


Q #04: Google Play shows that my device is not "certified" - how can I fix that?
First of all you must be on the latest build. I fixed that from the latest July (2019) builds on.
If your issue persists click here to proceed:
The second thing is you must not be rooted by the LOS root addon (afaik). Magisk has its own protections to ensure you stay certified but I hadn't the time to test the LOS root-addon.
You also need to know that google play remembers your devices last state so if you are on the latest build and still having that issue do this and it will be certified again:

android settings -> apps -> find play store -> clear data (yes data, not cache) -> reboot -> open play store -> wait 2..5 minutes -> check certified state again



Q #05: It looks like the CPU cores 5 and 6 are disabled - how can I fix that?
TLDR;
There is no fix required! it is fully ok when those are idle. they get hot plugged whenever needed.
Details:
we have 2 clusters of CPU cores resulting in a Hexa-core CPU set: (4x1.4 GHz Cortex-A53 & 2x1.8 GHz Cortex-A57)
the big one (2 CPU cores - higher performance = more battery drain, more heat which potentially causing the: bootloop issue) and the little (4 CPU cores - less battery drain but a bit slower) are handled dynamically based on the load of your device.
the big cluster will run ONLY when it is NEEDED - i.e. high load.
so when you look closer: those are not DISABLED they are IDLE which is a big difference.



Q #06: I get a kernel panic or green/purple/blue screen how to grab logs for this?
You need a ROM with pstore fully enabled and working (pstore = debug kernel panics/oops happened in a ROM)!

All builds starting from 2019-08-15 on support pstore due to: commit#1, commit#2, commit#3

This is a 2-site change if you want to make use of it in TWRP you must install the latest TWRP "PREVIEW" release as well (TWRP is only able to show pstore logs when the ROM is able to write them so I needed to fix pstore in the ROM first (see above commits #1 + #2 )).
Besides those 2 patches these kernel configs were set: PSTORE

You can check if a ROM does support writing pstore logs by:

as soon as possible on a fresh boot:
Code:
adb shell
dmesg | grep "ramoops|pstore"

Code:
[    0.000000] cma: Found ramoops_region@0, memory base 0x000000001fe00000, size 2 MiB, limit 0xffffffffffffffff
[    0.000000] cma: CMA: reserved 2 MiB at 0x000000001fe00000 for ramoops_mem
[    0.200846] cma: Assigned CMA region at 0 to ramoops.78 device
[B][    3.957553] console [pstore-1] enabled
[    3.957939] ramoops: attached 0x200000@0x1fe00000, ecc: 16/0[/B]
[    3.958079] drv probe : 200 ramoops 3744
[    6.262463] SELinux: initialized (dev pstore, type pstore), uses genfs_contexts

or (if you are not fast enough) this ensures mostly the same check:

Code:
adb shell
ls -la /dev/pmsg0

Code:
crw-rw-rw- 1 camera camera 254,   0 2015-01-05 04:54 /dev/pmsg0
If you get no output your ROM does not support pstore logs.

From now on when you encounter a kernel panic and you are able to reboot without taking out the battery (taking out the battery will erase RAM):
1) reboot (without taking out the battery!) to either TWRP or (if you have root access) to your ROM
2) grab everything need from here: /sys/fs/pstore/ (e.g. adb pull /sys/fs/pstore/)
If you don't have a pc near you can do it directly from the device as well:

Enable the terminal app in developer options or download any
Open the terminal app.

su
cd /sdcard/Download
tar czf pstore.tgz /sys/fs/pstore

Attach pstore.tgz to your post.

It is crucial important that you do this only after the reboot happened . It's not important "when" though - as long as the device stays powered on.

Developers note:
convert PMSG log (requires a linux system):
Code:
tr -cd '\11\12\15\40-\176' < pmsg-ramoops-0 | sed 's/TENS\s/\n/g' > readable-pmsg.txt


Q #07a: I get a kernel panic on boot or having other boot issues but the pstore log are empty! What should I do?
Q #07b: How can I provide a clean boot log?


Since a while there is a very easy way to provide debug logs for the boot process. Before my convenient logging you had to follow FAQ #1 to grab them and it was a bit of PITA for some users.
So here you go for a much easier way:

  1. boot Android
  2. once booted : reboot to TWRP
  3. when you have a bootloop instead: take the battery out just before the bootloop occurs, or better press the key combo to get into TWRP all the time to eventually get there directly
  4. once in TWRP ensure that "Cache" is mounted in the "Mount" menu (if not mount it by ticking the box)
  5. open a terminal on your PC and type:
    Code:
    adb pull /cache/debug/boot_lc_crash.txt
    adb pull /cache/debug/boot_lc_full.txt
    adb pull /cache/debug/boot_lc_kernel.txt
  6. paste one by one to a paste service like https://del.dog/ , https://paste.systemli.org/ or https://paste.omnirom.org/



Q #8: upgrade your bootloader stack only?! Read here how:
If you don't mind you can use lgup as long as you do not have an UsU'd device!
For UsU devices follow the UsU FAQ #20 instead of this one!!!!!
If you just wanna upgrade the bootloader stack without loosing data: Check the OP topic "Requirements" of this thread because:
it has a link to TWRP flashable files for updating your bootloader with just 1 click ..

Anyways if you still want to go on doing it manually instead of the easy way then:
Download a KDZ of your device model.
Keep in mind that there a frankenstein devices out there (means refurbished devices with mixed hardware inside so you think u have model XXX as it was shown in Android but the mainboard is NOT the same!).
How to identify a Frankenstein device? Read FAQ #21 in the UsU thread.
IMPORTANT: Check the ARB of that KDZ (SALT v3.11 will show the ARB of a KDZ on extract!) - If you are unsure - DO NOT PROCEED. you can easily hard brick your device if!
Extract that KDZ with SALT - DO NOT USE ANY OTHER TOOL FOR EXTRACTING! The known windows tools like LG Firmware extract does not extract what we need here and not in the way we need it! So do not use that! You have been warned..
Open a terminal in the directory where you SALT backup before flashing UsU (or your extracted KDZ) is.
Then put your device in fastboot mode and type these commands (you have another file extension? read FAQ #24 of the UsU thread):
Again this guide is NOT for UsU'd devices!!!
Code:
fastboot flash aboot aboot.bin
fastboot flash factory factory.bin
fastboot flash hyp hyp.bin
fastboot flash modem modem.bin
fastboot flash pmic pmic.bin
fastboot flash rpm rpm.bin
fastboot flash sbl1 sbl1.bin
fastboot flash sdi sdi.bin
fastboot flash sec sec.bin
fastboot flash tz tz.bin

Alternative with TWRP (if the above fastboot cmds work for you no need to do this!):
Again this guide is NOT for UsU'd devices!!!
Code:
Boot TWRP
adb push factory.bin /tmp/
adb push hyp.bin /tmp/
adb push modem.bin /tmp/
adb push pmic.bin /tmp/
adb push rpm.bin /tmp/
adb push sbl1.bin /tmp/
adb push sdi.bin /tmp/
adb push sec.bin /tmp/
adb push tz.bin /tmp/
adb push aboot.bin /tmp/

adb shell sync
adb shell "dd if=/tmp/factory.bin of=/dev/block/bootdevice/by-name/factory"
adb shell "dd if=/tmp/modem.bin of=/dev/block/bootdevice/by-name/modem"
adb shell "dd if=/tmp/hyp.bin of=/dev/block/bootdevice/by-name/hyp"
adb shell "dd if=/tmp/pmic.bin of=/dev/block/bootdevice/by-name/pmic"
adb shell "dd if=/tmp/rpm.bin of=/dev/block/bootdevice/by-name/rpm"
adb shell "dd if=/tmp/sbl1.bin of=/dev/block/bootdevice/by-name/sbl1"
adb shell "dd if=/tmp/sdi.bin of=/dev/block/bootdevice/by-name/sdi"
adb shell "dd if=/tmp/sec.bin of=/dev/block/bootdevice/by-name/sec"
adb shell "dd if=/tmp/tz.bin of=/dev/block/bootdevice/by-name/tz"
adb shell "dd if=/tmp/aboot.bin of=/dev/block/bootdevice/by-name/aboot"

Download this verify tool to ensure the flashing was successful: [ATTACH]4687157[/ATTACH] ([URL="http://leech.binbash.it:8008/misc/verifyflash.zip"]mirror --> verifyflash.zip[/URL])

Usage:
extract verifyflash.zip
adb push verifyflash.sh /tmp/
adb shell chmod 755 /tmp/verifyflash.sh
adb shell /tmp/verifyflash.sh

Read the output of the flashing on the screen and in your terminal. Do NOT flash anything else! Just the above - but ALL of the above! (if you miss a single file you will HARD BRICK)
If something is failing do NOT continue and try to re-do the above commands. if it still fails write in this thread or better come into IRC (when between Monday and Friday)!
If something failing here it WILL brick your phone.




Q #9: A life without Google?! Read here how:
A life without Google ? Is that possible ? ...and why you should consider it ?
So why? That's easy to answer and if those are worth it depends totally on your personal needs:

1) BATTERY. Google services are draining a LOT of your battery, so to get the most out of your battery you should abandon Google gapps

2) PRIVACY. Almost all Google apps phoning home to Google! You don't care about that? You really should. You have nothing to hide? Oh dear believe me you have no idea how much of your private data you do NOT want to share. Keep also in mind that you give your private data not to a company only , there are always humans behind and what they do.. You do not believe me? Read on

BREAKING NEWS:
You can go on with the following steps or simply head-over to /e/ OS which is LOS but completely Google-Free + microG fully working pre-installed:
check it out here!

WARNING:
The last build supporting this spoofing method was 20210307. Everything later has that patch removed. Sorry for any inconvenience but maintaining that patch took more time then thought and for those who really care about privacy there is now /e/ OS available containing full microG support. I will leave the instructions here for those who cannot or do not want to switch to /e/ OS.



So if you feel one or both reasons might fit your personal needs here are some first steps to go (if you do NOT want to switch to /e/ OS):

1) all my builds come with FDroid which is a special app store containing just free open-source apps. As this might be a very limited I recommend to install Aurora from here which is a frontend for Google play. So search in FDroid for "Aurora Store" and let it install. Start Aurora and choose anonymous!!! and you can install everything from play as before.

2) install the microG repo in FDroid. Just open that link from your G4 and it will install the repo:
https://microg.org/fdroid/repo?fing...EB6DAB39B73157451582CBD138E86C468ACC395D14165

3) due to the fact that many apps depends on Google services as backend you need to do 2 things now:
a) developer options -> scroll down to signature spoofing and enable it *(read FAQ #11 why)
b) Download the current stable "Services Core" apk from here: https://microg.org/download.html and install it like that:
Code:
adb install com.google.android.gms-[REPLACETHIS].apk
c) if you have root:
Code:
adb shell
su
mount -o remount,rw /system
exit
adb push /tmp/com.google.android.gms-[REPLACETHIS].apk /system/priv-app/GsmCore.apk

if you do not have root, boot to TWRP now and mount system, then:
Code:
adb push /tmp/com.google.android.gms-[REPLACETHIS].apk /system/priv-app/GsmCore.apk

4) Install a location backend provider to make location services work without Google (yea Google is spying you..).
There are several available, just search for them in F-Droid:
  • Apple UnifiedNlp Backend uses Apple’s Wifi database.
  • LocalGsmNlpBackend uses downloaded GSM Cell data (local)
  • LocalWifiNlpBackend uses (on-device generated) WiFi data (local)
  • Déjà Vu Location Service uses (on-device generated) WiFi + GSM Cell data (local) * recommended
  • MozillaNlpBackend uses Mozilla Location Services * recommended
  • Radiocells.org UnifiedNlp Backend uses Radiocells.org
Also install a reverse location backend:
- e.g. NominatimNlpBackend (currently the only I know)

5) Now it's time to configure microG. Go in the app drawer and open microG settings:
you will be prompted or a notification is showing for setting permissions, go through all of them and choose allow.
UnifiedNlp settings:
- Configure the location backend service (choose the one you installed in step 4)
- Configure the address lookup backend (choose the one you installed in step 4)
Go back to the main screen of microG:
Choose Self-Check:
- Tap "System grants signature spoofing permission" and you wou get a request for allowing that (which you should do..)
- Tap Battery optimizations ignored to ensure microG is function properly
- Ensure "UnifiedNlp is registered in system" is checked (if not repeat the above steps for pushing the APK to system/priv-app)
- Ensure "Location Backends" is checked (if not repeat UnifiedNlp settings above)
Read the installation wiki for microG and install whatever else you might need:
- https://github.com/microg/android_packages_apps_GmsCore/wiki/Installation

6) reboot & re-do the self-check in microG settings

7) ensure the location service is *NOT* set to GPS-only (for LOS that means enable battery saving)

8) some general things now:
you might need to switch to alternatives sometimes. I use Waze instead of Google maps even though Google would work (but I don't like the Google spys). I use FairEmail as I love my privacy and supporting open-source. Usually you can find always an alternative, often paid apps offer activations and buying without Google play and that is often even cheaper (e.g. AquaMail costs 39€ on play and 30€ on their website etc).

There is one thing which really hurts me when it comes to gapps-less life: no smart lock. I really enjoyed it but for me the both reasons above have more weight then this.

So as you can see a life without Google has its advantages but also some changes are needed. If it's worth it depends on you. I can just recommend it ;)


Q #10: issues with audio (e.g. echo's, silence on one or the other site, ..)? Read here how to provide a specific log for that:
Do the following steps:

  • 1) Ensure you have adb set up on your PC, and have adb debugging and adb root enabled in developer options on your phone
  • 2) Then perform the following (all one command)

    On Linux:
    adb root ; adb shell "stop audioserver; logcat -c -b all; start audioserver" && sleep 10 && adb logcat -b all |egrep -vi "(dialer|telecom|ril|gsm|touch|brightn|dct|QC-time-services|SST|sensors|AlarmMan|Lights|perfp)"

    On windows:
    adb root ; adb shell "stop audioserver; logcat -c -b all; start audioserver && sleep 10 && logcat -b all |egrep -vi '(dialer|telecom|ril|gsm|touch|brightn|dct|QC-time-services|SST|sensors|AlarmMan|Lights|perfp)' "

  • 3) Then re-produce your audo issue and cancel the logcat from step 2 before hanging up!

  • 4) Share the logcat output from the console screen using paste.omnirom.org


Q #11: I'm scared about that microG , I don't want to expose my phone so is this LOS version a security risk?
First of all you need a lot of trust installing ANY custom ROM. A developer can do nasty things right? Besides that yes microG allowing to let apps act like as they are another app, also known as signature spoofing. This CAN be a good and a bad thing. Read on why my LOS is different:


In general the microG patch is an all or nothing. A ROM which supports microG (i.e. signature spoofing) have that feature enabled, always. That's what I don't like.

I want the user to decide if he wants to take the risk or not and not exposing a feature for everyone even when they don't need it.
That's why the user must enable it explicitly in developer options before it gets activated (as described in FAQ #9).

All details of the implementation and why can be found here:

https://github.com/steadfasterX/android_signature_spoofing

https://github.com/Suicide-Squirrel/issues_pie/issues/30


Q #12: The ROM is lagging and/or the device gets very hot/warm, what can I do to help fixing that?
Ensure you read and understand about the ILAPO first.
If you encounter any overheat or lagging issues follow this:

Code:
adb shell
logcat -b all  -d | egrep -i "thermal|kill" > /sdcard/Download/log.txt
ps -A  >> /sdcard/Download/log.txt
free -m >> /sdcard/Download/log.txt
logcat -b crash -d >> /sdcard/Download/log.txt
exit
adb pull  /sdcard/Download/log.txt
Share the log.txt as an attachment of your reply (bc txt is fine for that) or - as usual - by your favorite paste service




Q #13: I have graphic glitches / issues, what can I do?
My builds using skiaGL instead of OpenGL since a while. skia is the new and faster renderer coming with pie by default but it can cause graphic glitches in some applications and/or situations.
Is there any fix for skiaGL coming? No, details here .
To check if your current ROM version is using skiaGL do this:

Code:
adb shell getprop debug.hwui.renderer
If you get an empty result it means skiaGL is active.
If for any reason you wanna go back and enforce OpenGL you can do so by

temporary (immediately activated):
Code:
adb root (must be enabled in dev options)
adb shell setprop debug.hwui.renderer opengl

or make that change persistent:
Code:
boot TWRP
backup system
mount system
adb shell
echo "debug.hwui.renderer=opengl" >> /system/build.prop
sync
reboot


.-
 
Last edited:

steadfasterX

Recognized Developer
Nov 13, 2013
6,245
15,484
127.0.0.1
OnePlus 7T Pro
User recommendations to enhance the LOS experience

The following contains a list of 3rd party apps or mods to enhance the default LOS experience.
They are not tested by myself but recommended by the community for whatever reason..

If you miss something here post in the thread at least the app name, the google play store link to that app and a short description why it is that good.

Camera:

Launcher:

Keyboards:

Root:
  • Magisk because the LOS root-addon will be deprecated in LOS 17 and ofc because Magisk has so many nice features like hiding etc.
    Download Magisk - only there - nowhere else!

Web Browser:

Misc / Tools:

TUNING:
  • Kernel Adiutor settings by User gkg2k for a faster and smoother experience: check out his great guide here
    Note: I recommend to skip the RAM settings mentioned there when using build 20200324 or later. If you feel you still need those settings try it first without nevertheless ;) .. I made a lot of improvements since that mentioned build so give it a go first.



.-
 
Last edited:

steadfasterX

Recognized Developer
Nov 13, 2013
6,245
15,484
127.0.0.1
OnePlus 7T Pro
Builds are up for:

  • H811
  • H815
  • H815 - UsU
  • VS986
  • H812
  • H810



Before reporting issues ensure you have read the KNOWN ISSUES topic in the OP before

Keep in mind that this is brand new stuff so it may contain issues unknown yet!
That's why the whole project is declared as BETA - not STABLE.

It wasn't until Pie felt stable enough for everyday use that I released it publicly, but I still can't test everything on my own, so a lot of things only show up after a release.
So back up regularly and frequently.

If you find a bug, follow the instructions here and provide me with the logs: http://bit.do/logcat


.-
 
Last edited:

Sir Daniel III

Senior Member
Feb 12, 2019
87
23
Samsung Galaxy S7
Google Pixel 7
Looks great so far! I don't know why SELinux is disabled for me though... Is it because I flashed the ROM, Gapps, Magisk, then the high resolution video fix at the same time?
Edit: UI is a bit choppy (not too bad though), and app icons sometimes don't show when you're moving icons from the app drawer to your home screen for me. Also brightness slider might be a bit broken...
 

Attachments

  • Screenshot_20190512-144348_LineageOS_Settings.png
    Screenshot_20190512-144348_LineageOS_Settings.png
    164.7 KB · Views: 678
Last edited:

steadfasterX

Recognized Developer
Nov 13, 2013
6,245
15,484
127.0.0.1
OnePlus 7T Pro
Looks great so far! I don't know why SELinux is disabled for me though... Is it because I flashed the ROM, Gapps, Magisk, then the high resolution video fix at the same time?
Edit: UI is a bit choppy (not too bad though), and app icons sometimes don't show when you're moving icons from the app drawer to your home screen for me. Also brightness slider might be a bit broken...

regarding SELinux read the known issues. it is not enforcing atm.
yes the GL renderer is not optimal but you can try Pie's new default one if you like (known to have glitches)

just execute this (as root I guess)

Code:
setprop debug.hwui.renderer skiagl

That one works well for me but has sometimes in some situation graphic bugs. It will take effective immediately and will not survive a reboot (so must be set then again).


.-
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    @steadfasterX For the ' kernel_lge_msm8992' what is the difference between the branches of 'android-9.0' and 'android-9.0_titan' and what one should be used for h812_usu ? Thanks, S.
    always check the manifests I link in my OP's.
    in this case: https://github.com/LGgFour/local_manifests -> and more explicitly: https://github.com/LGgFour/local_manifests/blob/lineage-16.0/roomservice.xml#L23
    the _titan one was a try to get the latest titan one working in A9 (which fails)
    1
    always check the manifests I link in my OP's.
    in this case: https://github.com/LGgFour/local_manifests -> and more explicitly: https://github.com/LGgFour/local_manifests/blob/lineage-16.0/roomservice.xml#L23
    the _titan one was a try to get the latest titan one working in A9 (which fails)
    I did check the local_manifest but wondered if the _titan was a newer version and what it applied to - Thanks, again
  • 90
    2okPze5.png


    Code:
    /*
    * I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed (like it did for me...).
    * Please do some research if you have any concerns about features included in the products you find here before flashing it!
    * YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
    * Your warranty will be void if you tamper with any part of your device / software.
    * Same statement for XDA.
    */

    About LineageOS​

    LineageOS is a free, community built, aftermarket firmware distribution of Android 9 (pie), 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. Linked below is a package that has come from another Android project that restore the Google parts. LineageOS does still include various hardware-specific code, which is also slowly being open-sourced anyway.


    **** These builds are for both: official unlocked and UsU'd devices ****
    UsU? http://bit.do/unlockg4

    Requirements​

    • Your device need to be unlocked either officially (h815 international or h811) or by UsU
    • Your bootloader stack should be on MM 20p (20x for H811) or higher! (see FAQ #8 for how to upgrade your bootloader stack without lgup BUT for your convenience I have alternatively created TWRP flashable files for that !!!! (click))
    • in particular that means this thread is for:
      F500 (UsU'd)
      H810 (UsU'd)
      H811
      H812 (UsU'd)
      H815 (official unlocked or UsU'd)
      H819 (UsU'd)
      LS991 (UsU'd)
      US991 (UsU'd)
      VS986 (UsU'd)
    • Latest TWRP - PREVIEW build: click
    • Do a full Nandroid backup before doing anything!

    Installation​

    1. This single very first step is for UsU'd devices only:
      If you have ever flashed the UsU baseband package: Clean flash the modem partition from your backup in TWRP.
      If you do not know if you ever flashed it simply flash your modem partition again and you can be sure. This can't do any harm.
      If you have no backup:
      - TWRP flashable MM modems (N will not work)
    2. Full clean install as described here (FAQ "#2") is highly recommended. DO NOT REPORT ISSUES when you have skipped that step!
    3. Flash LOS
    4. Optional (f-droid is already included): Flash GApps (9.0 - ARM64) if you like to use google apps
    5. Optional (if you want root): Flash the official LOS root-addon (addonsu-16.0-arm64-signed.zip) or Magisk (ensure you read FAQ #1 when using Magisk though)
    6. Boot (will take a bit on first boot!!!)
    7. Enjoy

    Features​

    • Pure LineageOS ROM experience
    • F-Droid included (Open Source alternative to Google Play)
    • Torch workaround included (no root)
    • BT voice FIXED:)

    Known issues​

    I can't test everything on my own, so a lot of things only show up after a release. That means:
    - back up regularly and frequently!
    - report issues the issue tracker (see next)
    1. Check the current issues at the github tracker (feel free to help, provide logs etc!
    2. If you find a bug not listed, follow the instructions here and provide me with the logs: FAQ #1

    Download​

    Get your builds from my leech server
    https://leech.binbash.rocks:8008/lineage/16.0/

    Note:
    1. Builds are updated as soon as possible. There is no build cycle.
    2. Information pertaining to your device is displayed accordingly.
    3. The current build is the latest for your device.

    Changelogs​

    • only at my Telegram group

    Credits​

    • LineageOS
    • The Suicide-Squirrel team (ThePiGuy, kessaras, steadfasterX)
    • aoleary
    • WiZaRd981
    • berkantkz
    • sdembiske
    • and more..

    Sources​


    LEGACY XDA DB info​

    XDA:DevDB Information
    lineage-16.0, ROM for the LG G4

    Contributors
    steadfasterX, ThePiGuy, kessaras, aoleary, WiZaRd981, HardStyl3r

    ROM OS Version: 9.x Pie
    ROM Kernel: Linux 3.10.x
    ROM Firmware Required: latest MM / N (exact version is model dependent)
    Based On: pure LineageOS

    Version Information
    Status:
    Stable

    Created 2019-05-10
    47
    Frequently Asked Questions (FAQ)

    Q #01: I want to report an issue. What is the proper way to do so?
    I'm glad that you are asking: before doing so check the KNOWN ISSUES topic in the OP and ofc the other FAQ's listed here!
    If you encountered a kernel panic follow FAQ #6 in this post instead.
    If you have issues with "just" the boot process follow FAQ #7 for a very easy way to grab the boot logs.
    if you have an audio issue follow FAQ #10 instead.

    If your issue is not listed there click here to proceed:

    If your issue is not listed there follow the directions here briefly and I may can fix it.

    Often selinux can cause issues so try that at very first:
    Code:
    adb shell
    su
    (or "adb root" when enabled in developer settings)
    setenforce permissive
    Try again and if the issue is gone when in permissive mode: provide me a logcat as described here -> on step 3 I need the SELINUX log (option D)

    If that does not solve your issue follow the logcat GUIDE to provide a valid log depending on what your issue is.

    Ensure you have done a full CLEAN install before doing so (refer to FAQ #2 for what that means).

    Warning: NO SUPPORT when:
    - magisk is installed (known to cause issues sometimes - regardless of the ROM or version)
    - Xposed is installed (known to cause issues sometimes - regardless of the ROM or version)
    If you have installed any of these UNINSTALL or better do a FULL CLEAN install (see FAQ #2) before doing anything else. Often enough these above causes several issues like battery draining, problems on booting and much more. Even when they may work properly you should re-produce your issue without them first and follow the above to grab the log.

    Magisk is a great piece of software and besides that it is Open Source which SuperSu never was.
    I just saying I do not "support" issues with LOS when you have Magisk installed. Why? It is (like Xposed) extendable with modules (made by whoever) and those can cause billions of issues.
    Other then that magisk was sometimes the reason for battery drain etc. Magisk modifies the boot "process" and sits very deep in the system (which is needed to make it work ofc) but that has the potential to make a system/ROM unstable or result in strange behaviors.

    so in order to support a specific issue I have to be sure the ROM is in a "clean" state, no magisk, no xposed. The LOS root-addon is tested with LOS and made for it so that is not an issue but for the rest there are so many things which can going wrong..


    Q #02: I want to install clean, how? What is a clean install? What is the recommended way to flash a new ROM version?
    A clean install ensures that there are no leftovers from any previous install. One can say that there are 2 phases of a clean flash:
    1) regular
    2) full - when you (still) encounter issues

    Usually the regular one is fully ok when flashing a new ROM version but if you encounter strange issues nobody else is reporting or if a release post is recommending it you should do a full clean install instead.

    A regular clean install can be done like this:
    • WIPE -> Advanced -> select: System + Cache
    • Flash the ROM
    • reflash root addon/magisk if you want root
    • reflash opengapps if you want to use Google crap

    A full clean install needs 2 steps more then the regular:
    • follow the steps for regular clean
    • go back in WIPE -> touch the "FORMAT data" button and type "yes" to format the internal storage (you will LOOSE ALL YOUR DATA - obviously)
    • REBOOT -> Recovery
    • Flash the ROM
    • reflash root addon/magisk if you want root
    • reflash opengapps if you want to use Google crap
    It is absolutely recommended to create a backup before and COPYING IT to your PC(!) before doing the above.


    Q #03: Are there any plans or a chance of official LOS builds?
    TL;DR answer is: no.

    Background:
    LineageOS has "some" requirements before they accept it to do official builds: device-support-requirements.

    For sure we do not met all and the most problematic one will be the kernel reqs as do provide a good battery life and a fast kernel kessaras had made unacceptable (for LOS) changes regarding several parts of that requirement topic. So a new kernel (branch) is needed to remove all the improvements we made which are not accepted. This process alone can take weeks (if you do not want to loose every good thing here). A much easier approach here would be to build a "just working" LOS stock kernel without any improvements and fixes and tell everyone: "Flash LOS, then a TITAN kernel afterwards". So while that might be the easier approach it will nevertheless take time to do that kernel and include the reqs + sec patches to the day.

    Besides that a bit work is needed to fulfill some of the others like that.

    Other then that and that is one of the most important things here:
    Even when the device was accepted going official in the past (14.1... long time ago..) an incredible amount of changes happened to get oreo and now pie running. All these will be put to the test. Which actually means every commit we made will be discussed (worst case, yea, but ..) and changed. That can be from a simple "the commit message is wrong" to "pls re-write the code here". You maybe get an idea that this process is nerve-wracking (for me) and costs a lot of my free time.

    Before RIL has been fixed (which had happened in the end of June 2019 first) it would have been impossible, I guess.

    Now the base is fine, we could put a big amount of time into going to official to get finally ........ yea, what?
    Well.. I would free resources on my build and leech server (I don't care - atm)
    I would save bandwidth (I don't care - atm)
    I would not need to tamper around anymore with (i.e jenkins) build issues (I don't care - atm)
    you?
    you would get a (LOS signed) build with a slow kernel, bad battery life and all the goodies missing... unless I build LOS kernels to bring those things back.
    ok but to be honest. I can fully understand that request and I would feel better by myself when I were you. You do not know me so are my builds trustworthy ? Who knows. I could be a bad guy. :fingers-crossed:
    Besides that I wrote above "I don't care - atm" so that might change in the future right? Correct.. there is no guarantee how long I can provide new builds or offer them on my leech server. There is nothing at the horizon that this might change soon but who knows? I can say that I am incredible happy with my OnePlus 6T and - believe it or not - I run STOCK OxygenOS here.. Why? It is just enough for me. So no need to do any dev there - which means all my dev time is still going here - to the G4. It is also a personal project to learn stuff around the Android eco system and woa.. who knows maybe Q came one day to the G4 as well.. :rolleyes:
    ... and yea official builds would give you some kind of guarantee that builds will happen - while that might change with my unofficial builds some day.

    So.. as said in the TLDR above: No I personally do not have any plans in going official for the described reasons.
    If someone else wants to go that way and needs help, I am here. But I cannot spend my whole free time on that.


    Q #04: Google Play shows that my device is not "certified" - how can I fix that?
    First of all you must be on the latest build. I fixed that from the latest July (2019) builds on.
    If your issue persists click here to proceed:
    The second thing is you must not be rooted by the LOS root addon (afaik). Magisk has its own protections to ensure you stay certified but I hadn't the time to test the LOS root-addon.
    You also need to know that google play remembers your devices last state so if you are on the latest build and still having that issue do this and it will be certified again:

    android settings -> apps -> find play store -> clear data (yes data, not cache) -> reboot -> open play store -> wait 2..5 minutes -> check certified state again



    Q #05: It looks like the CPU cores 5 and 6 are disabled - how can I fix that?
    TLDR;
    There is no fix required! it is fully ok when those are idle. they get hot plugged whenever needed.
    Details:
    we have 2 clusters of CPU cores resulting in a Hexa-core CPU set: (4x1.4 GHz Cortex-A53 & 2x1.8 GHz Cortex-A57)
    the big one (2 CPU cores - higher performance = more battery drain, more heat which potentially causing the: bootloop issue) and the little (4 CPU cores - less battery drain but a bit slower) are handled dynamically based on the load of your device.
    the big cluster will run ONLY when it is NEEDED - i.e. high load.
    so when you look closer: those are not DISABLED they are IDLE which is a big difference.



    Q #06: I get a kernel panic or green/purple/blue screen how to grab logs for this?
    You need a ROM with pstore fully enabled and working (pstore = debug kernel panics/oops happened in a ROM)!

    All builds starting from 2019-08-15 on support pstore due to: commit#1, commit#2, commit#3

    This is a 2-site change if you want to make use of it in TWRP you must install the latest TWRP "PREVIEW" release as well (TWRP is only able to show pstore logs when the ROM is able to write them so I needed to fix pstore in the ROM first (see above commits #1 + #2 )).
    Besides those 2 patches these kernel configs were set: PSTORE

    You can check if a ROM does support writing pstore logs by:

    as soon as possible on a fresh boot:
    Code:
    adb shell
    dmesg | grep "ramoops|pstore"

    Code:
    [    0.000000] cma: Found ramoops_region@0, memory base 0x000000001fe00000, size 2 MiB, limit 0xffffffffffffffff
    [    0.000000] cma: CMA: reserved 2 MiB at 0x000000001fe00000 for ramoops_mem
    [    0.200846] cma: Assigned CMA region at 0 to ramoops.78 device
    [B][    3.957553] console [pstore-1] enabled
    [    3.957939] ramoops: attached 0x200000@0x1fe00000, ecc: 16/0[/B]
    [    3.958079] drv probe : 200 ramoops 3744
    [    6.262463] SELinux: initialized (dev pstore, type pstore), uses genfs_contexts

    or (if you are not fast enough) this ensures mostly the same check:

    Code:
    adb shell
    ls -la /dev/pmsg0

    Code:
    crw-rw-rw- 1 camera camera 254,   0 2015-01-05 04:54 /dev/pmsg0
    If you get no output your ROM does not support pstore logs.

    From now on when you encounter a kernel panic and you are able to reboot without taking out the battery (taking out the battery will erase RAM):
    1) reboot (without taking out the battery!) to either TWRP or (if you have root access) to your ROM
    2) grab everything need from here: /sys/fs/pstore/ (e.g. adb pull /sys/fs/pstore/)
    If you don't have a pc near you can do it directly from the device as well:

    Enable the terminal app in developer options or download any
    Open the terminal app.

    su
    cd /sdcard/Download
    tar czf pstore.tgz /sys/fs/pstore

    Attach pstore.tgz to your post.

    It is crucial important that you do this only after the reboot happened . It's not important "when" though - as long as the device stays powered on.

    Developers note:
    convert PMSG log (requires a linux system):
    Code:
    tr -cd '\11\12\15\40-\176' < pmsg-ramoops-0 | sed 's/TENS\s/\n/g' > readable-pmsg.txt


    Q #07a: I get a kernel panic on boot or having other boot issues but the pstore log are empty! What should I do?
    Q #07b: How can I provide a clean boot log?


    Since a while there is a very easy way to provide debug logs for the boot process. Before my convenient logging you had to follow FAQ #1 to grab them and it was a bit of PITA for some users.
    So here you go for a much easier way:

    1. boot Android
    2. once booted : reboot to TWRP
    3. when you have a bootloop instead: take the battery out just before the bootloop occurs, or better press the key combo to get into TWRP all the time to eventually get there directly
    4. once in TWRP ensure that "Cache" is mounted in the "Mount" menu (if not mount it by ticking the box)
    5. open a terminal on your PC and type:
      Code:
      adb pull /cache/debug/boot_lc_crash.txt
      adb pull /cache/debug/boot_lc_full.txt
      adb pull /cache/debug/boot_lc_kernel.txt
    6. paste one by one to a paste service like https://del.dog/ , https://paste.systemli.org/ or https://paste.omnirom.org/



    Q #8: upgrade your bootloader stack only?! Read here how:
    If you don't mind you can use lgup as long as you do not have an UsU'd device!
    For UsU devices follow the UsU FAQ #20 instead of this one!!!!!
    If you just wanna upgrade the bootloader stack without loosing data: Check the OP topic "Requirements" of this thread because:
    it has a link to TWRP flashable files for updating your bootloader with just 1 click ..

    Anyways if you still want to go on doing it manually instead of the easy way then:
    Download a KDZ of your device model.
    Keep in mind that there a frankenstein devices out there (means refurbished devices with mixed hardware inside so you think u have model XXX as it was shown in Android but the mainboard is NOT the same!).
    How to identify a Frankenstein device? Read FAQ #21 in the UsU thread.
    IMPORTANT: Check the ARB of that KDZ (SALT v3.11 will show the ARB of a KDZ on extract!) - If you are unsure - DO NOT PROCEED. you can easily hard brick your device if!
    Extract that KDZ with SALT - DO NOT USE ANY OTHER TOOL FOR EXTRACTING! The known windows tools like LG Firmware extract does not extract what we need here and not in the way we need it! So do not use that! You have been warned..
    Open a terminal in the directory where you SALT backup before flashing UsU (or your extracted KDZ) is.
    Then put your device in fastboot mode and type these commands (you have another file extension? read FAQ #24 of the UsU thread):
    Again this guide is NOT for UsU'd devices!!!
    Code:
    fastboot flash aboot aboot.bin
    fastboot flash factory factory.bin
    fastboot flash hyp hyp.bin
    fastboot flash modem modem.bin
    fastboot flash pmic pmic.bin
    fastboot flash rpm rpm.bin
    fastboot flash sbl1 sbl1.bin
    fastboot flash sdi sdi.bin
    fastboot flash sec sec.bin
    fastboot flash tz tz.bin

    Alternative with TWRP (if the above fastboot cmds work for you no need to do this!):
    Again this guide is NOT for UsU'd devices!!!
    Code:
    Boot TWRP
    adb push factory.bin /tmp/
    adb push hyp.bin /tmp/
    adb push modem.bin /tmp/
    adb push pmic.bin /tmp/
    adb push rpm.bin /tmp/
    adb push sbl1.bin /tmp/
    adb push sdi.bin /tmp/
    adb push sec.bin /tmp/
    adb push tz.bin /tmp/
    adb push aboot.bin /tmp/
    
    adb shell sync
    adb shell "dd if=/tmp/factory.bin of=/dev/block/bootdevice/by-name/factory"
    adb shell "dd if=/tmp/modem.bin of=/dev/block/bootdevice/by-name/modem"
    adb shell "dd if=/tmp/hyp.bin of=/dev/block/bootdevice/by-name/hyp"
    adb shell "dd if=/tmp/pmic.bin of=/dev/block/bootdevice/by-name/pmic"
    adb shell "dd if=/tmp/rpm.bin of=/dev/block/bootdevice/by-name/rpm"
    adb shell "dd if=/tmp/sbl1.bin of=/dev/block/bootdevice/by-name/sbl1"
    adb shell "dd if=/tmp/sdi.bin of=/dev/block/bootdevice/by-name/sdi"
    adb shell "dd if=/tmp/sec.bin of=/dev/block/bootdevice/by-name/sec"
    adb shell "dd if=/tmp/tz.bin of=/dev/block/bootdevice/by-name/tz"
    adb shell "dd if=/tmp/aboot.bin of=/dev/block/bootdevice/by-name/aboot"
    
    Download this verify tool to ensure the flashing was successful: [ATTACH]4687157[/ATTACH] ([URL="http://leech.binbash.it:8008/misc/verifyflash.zip"]mirror --> verifyflash.zip[/URL])
    
    Usage:
    extract verifyflash.zip
    adb push verifyflash.sh /tmp/
    adb shell chmod 755 /tmp/verifyflash.sh
    adb shell /tmp/verifyflash.sh

    Read the output of the flashing on the screen and in your terminal. Do NOT flash anything else! Just the above - but ALL of the above! (if you miss a single file you will HARD BRICK)
    If something is failing do NOT continue and try to re-do the above commands. if it still fails write in this thread or better come into IRC (when between Monday and Friday)!
    If something failing here it WILL brick your phone.




    Q #9: A life without Google?! Read here how:
    A life without Google ? Is that possible ? ...and why you should consider it ?
    So why? That's easy to answer and if those are worth it depends totally on your personal needs:

    1) BATTERY. Google services are draining a LOT of your battery, so to get the most out of your battery you should abandon Google gapps

    2) PRIVACY. Almost all Google apps phoning home to Google! You don't care about that? You really should. You have nothing to hide? Oh dear believe me you have no idea how much of your private data you do NOT want to share. Keep also in mind that you give your private data not to a company only , there are always humans behind and what they do.. You do not believe me? Read on

    BREAKING NEWS:
    You can go on with the following steps or simply head-over to /e/ OS which is LOS but completely Google-Free + microG fully working pre-installed:
    check it out here!

    WARNING:
    The last build supporting this spoofing method was 20210307. Everything later has that patch removed. Sorry for any inconvenience but maintaining that patch took more time then thought and for those who really care about privacy there is now /e/ OS available containing full microG support. I will leave the instructions here for those who cannot or do not want to switch to /e/ OS.



    So if you feel one or both reasons might fit your personal needs here are some first steps to go (if you do NOT want to switch to /e/ OS):

    1) all my builds come with FDroid which is a special app store containing just free open-source apps. As this might be a very limited I recommend to install Aurora from here which is a frontend for Google play. So search in FDroid for "Aurora Store" and let it install. Start Aurora and choose anonymous!!! and you can install everything from play as before.

    2) install the microG repo in FDroid. Just open that link from your G4 and it will install the repo:
    https://microg.org/fdroid/repo?fing...EB6DAB39B73157451582CBD138E86C468ACC395D14165

    3) due to the fact that many apps depends on Google services as backend you need to do 2 things now:
    a) developer options -> scroll down to signature spoofing and enable it *(read FAQ #11 why)
    b) Download the current stable "Services Core" apk from here: https://microg.org/download.html and install it like that:
    Code:
    adb install com.google.android.gms-[REPLACETHIS].apk
    c) if you have root:
    Code:
    adb shell
    su
    mount -o remount,rw /system
    exit
    adb push /tmp/com.google.android.gms-[REPLACETHIS].apk /system/priv-app/GsmCore.apk

    if you do not have root, boot to TWRP now and mount system, then:
    Code:
    adb push /tmp/com.google.android.gms-[REPLACETHIS].apk /system/priv-app/GsmCore.apk

    4) Install a location backend provider to make location services work without Google (yea Google is spying you..).
    There are several available, just search for them in F-Droid:
    • Apple UnifiedNlp Backend uses Apple’s Wifi database.
    • LocalGsmNlpBackend uses downloaded GSM Cell data (local)
    • LocalWifiNlpBackend uses (on-device generated) WiFi data (local)
    • Déjà Vu Location Service uses (on-device generated) WiFi + GSM Cell data (local) * recommended
    • MozillaNlpBackend uses Mozilla Location Services * recommended
    • Radiocells.org UnifiedNlp Backend uses Radiocells.org
    Also install a reverse location backend:
    - e.g. NominatimNlpBackend (currently the only I know)

    5) Now it's time to configure microG. Go in the app drawer and open microG settings:
    you will be prompted or a notification is showing for setting permissions, go through all of them and choose allow.
    UnifiedNlp settings:
    - Configure the location backend service (choose the one you installed in step 4)
    - Configure the address lookup backend (choose the one you installed in step 4)
    Go back to the main screen of microG:
    Choose Self-Check:
    - Tap "System grants signature spoofing permission" and you wou get a request for allowing that (which you should do..)
    - Tap Battery optimizations ignored to ensure microG is function properly
    - Ensure "UnifiedNlp is registered in system" is checked (if not repeat the above steps for pushing the APK to system/priv-app)
    - Ensure "Location Backends" is checked (if not repeat UnifiedNlp settings above)
    Read the installation wiki for microG and install whatever else you might need:
    - https://github.com/microg/android_packages_apps_GmsCore/wiki/Installation

    6) reboot & re-do the self-check in microG settings

    7) ensure the location service is *NOT* set to GPS-only (for LOS that means enable battery saving)

    8) some general things now:
    you might need to switch to alternatives sometimes. I use Waze instead of Google maps even though Google would work (but I don't like the Google spys). I use FairEmail as I love my privacy and supporting open-source. Usually you can find always an alternative, often paid apps offer activations and buying without Google play and that is often even cheaper (e.g. AquaMail costs 39€ on play and 30€ on their website etc).

    There is one thing which really hurts me when it comes to gapps-less life: no smart lock. I really enjoyed it but for me the both reasons above have more weight then this.

    So as you can see a life without Google has its advantages but also some changes are needed. If it's worth it depends on you. I can just recommend it ;)


    Q #10: issues with audio (e.g. echo's, silence on one or the other site, ..)? Read here how to provide a specific log for that:
    Do the following steps:

    • 1) Ensure you have adb set up on your PC, and have adb debugging and adb root enabled in developer options on your phone
    • 2) Then perform the following (all one command)

      On Linux:
      adb root ; adb shell "stop audioserver; logcat -c -b all; start audioserver" && sleep 10 && adb logcat -b all |egrep -vi "(dialer|telecom|ril|gsm|touch|brightn|dct|QC-time-services|SST|sensors|AlarmMan|Lights|perfp)"

      On windows:
      adb root ; adb shell "stop audioserver; logcat -c -b all; start audioserver && sleep 10 && logcat -b all |egrep -vi '(dialer|telecom|ril|gsm|touch|brightn|dct|QC-time-services|SST|sensors|AlarmMan|Lights|perfp)' "

    • 3) Then re-produce your audo issue and cancel the logcat from step 2 before hanging up!

    • 4) Share the logcat output from the console screen using paste.omnirom.org


    Q #11: I'm scared about that microG , I don't want to expose my phone so is this LOS version a security risk?
    First of all you need a lot of trust installing ANY custom ROM. A developer can do nasty things right? Besides that yes microG allowing to let apps act like as they are another app, also known as signature spoofing. This CAN be a good and a bad thing. Read on why my LOS is different:


    In general the microG patch is an all or nothing. A ROM which supports microG (i.e. signature spoofing) have that feature enabled, always. That's what I don't like.

    I want the user to decide if he wants to take the risk or not and not exposing a feature for everyone even when they don't need it.
    That's why the user must enable it explicitly in developer options before it gets activated (as described in FAQ #9).

    All details of the implementation and why can be found here:

    https://github.com/steadfasterX/android_signature_spoofing

    https://github.com/Suicide-Squirrel/issues_pie/issues/30


    Q #12: The ROM is lagging and/or the device gets very hot/warm, what can I do to help fixing that?
    Ensure you read and understand about the ILAPO first.
    If you encounter any overheat or lagging issues follow this:

    Code:
    adb shell
    logcat -b all  -d | egrep -i "thermal|kill" > /sdcard/Download/log.txt
    ps -A  >> /sdcard/Download/log.txt
    free -m >> /sdcard/Download/log.txt
    logcat -b crash -d >> /sdcard/Download/log.txt
    exit
    adb pull  /sdcard/Download/log.txt
    Share the log.txt as an attachment of your reply (bc txt is fine for that) or - as usual - by your favorite paste service




    Q #13: I have graphic glitches / issues, what can I do?
    My builds using skiaGL instead of OpenGL since a while. skia is the new and faster renderer coming with pie by default but it can cause graphic glitches in some applications and/or situations.
    Is there any fix for skiaGL coming? No, details here .
    To check if your current ROM version is using skiaGL do this:

    Code:
    adb shell getprop debug.hwui.renderer
    If you get an empty result it means skiaGL is active.
    If for any reason you wanna go back and enforce OpenGL you can do so by

    temporary (immediately activated):
    Code:
    adb root (must be enabled in dev options)
    adb shell setprop debug.hwui.renderer opengl

    or make that change persistent:
    Code:
    boot TWRP
    backup system
    mount system
    adb shell
    echo "debug.hwui.renderer=opengl" >> /system/build.prop
    sync
    reboot


    .-
    31
    New builds are cooking...

    PREPARE - this update is BiiiiiiiiG



    I have added a test in my jenkins build process to ensure that the unified device tree is working as it should.
    Unifying our device tree makes it much easier to maintain and to add other not-yet added models - while it comes with the risk something goes wrong when it comes to blobs.

    Nevertheless:
    This is the 6th round first of my unified device tree so I would highly recommend doing the following (I have done that in my manual builds but you get it from jenkins - so there is a tiny little chance of bad luck .. ):

    Pre-Cautions | Flashing instructions

    1. Recommended: Backup (system, userdata in TWRP, your internal storage which contains your photos etc elsewhere)
    2. Required: Do a "REGULAR CLEAN FLASH" (see bottom of this post)
    3. Flash LOS - DO NOT choose to reboot afterwards - stay in TWRP.
    4. TWRP menu: "Mount" --> choose "System"
    5. From a terminal execute:
      Code:
      adb shell md5sum /system/etc/firmware/venus.mbn
    6. Compare the value (last 4 characters is fully enough) with these:
      If you flash:
      h815, f500, h818, h819 it should be: d1f6fe863643b1e8d1e597762474928c
      h810, h811, h812, ls991, us991, vs986 it should be: 78e5cf520d0de4a413ef1cfa7bbbe713
      WARNING: If that checksum is NOT as it should be: DO NOT PANIC! simply FLASH the PREVIOUS LOS version BEFORE booting!. This will ensure you will not blow a fuse.
      While the above test should be considered safe: If you are unsure about this procedure: WAIT before flashing until someone (or I) had done the above quick test from the builds jenkins is providing at my leech server.
    7. Whenever an error occurs while flashing in TWRP (e.g "E1001: Failed to update system image.Updater process ended with ERROR: 7")
      or if the above checksum does not match:
      provide the recovery.log (FAQ #4 A)!!
      ... then flash the previous LOS version to get back to life - without harming your device.
    8. if instead (as we all expect) all went well and you had opengapps before - ensure you reflash gapps

    Cooking order & LIVE cooking view

    • H815
    • H811
    • H815 UsU
    • VS986
    • H812
    • H810

    Live - View:


    Noteworthy Changes:
    • enabled pstore commit#1, commit#2, commit#3 (pstore = debug kernel panics/oops happened in a ROM)
      This is a 2-site change if you want to make use of it in TWRP you must install the latest TWRP "PREVIEW" release as well (TWRP is only able to show pstore logs when the ROM is able to write them so I needed to fix pstore in the ROM first (see above commits #1 + #2 )).
      Besides those 2 patches these kernel configs were set: PSTORE
      All details & how to verify: see FAQ #6
      From now on when you encounter a kernel panic and you are able to reboot without taking out the battery (taking out the battery will erase RAM and so the logs would get lost):
      1) reboot (without taking out the battery!) to either TWRP or (if you have root access) to your ROM
      2) grab what you need from here: /sys/fs/pstore/ (e.g. adb pull /sys/fs/pstore/)

    • fixed battery draining caused by torch crashing the camera: on boot, randomly and when "enable torch for power button" configured in android settings
    • kernel: security fixes, IPA revamp, several other improvements here and there
    • fixed: WiFi & BT MAC changed on every boot in rare cases (e.g. after a format data in TWRP)
    • new: translations for torch (if you miss any let me know the 2-letter country code and the translation for "flashlight"), removed the LOS owned flashlight completely from status bar / tile (both require a factory reset or full clean flash if you wanna them)
    • fixed: build F-Droid without unifiednlp and its backends (might be of interest for you @zeduck)
    • wrild: fixed no-SIM handling, several optimizations for better detection and handling of rild issues, complete re-work of dontaudit handling for wrild
    • WOOF: proudly presenting a brand new and (hopefully) intelligent watchdog for rild (part of wrild.sh).
      The main purpose of this watchdog is detecting and solving issues with no cell service and/or unusual high load on the rild process (rare but sometimes happens) which causing a lot of battery drain if that occured.
      When the watchdog needs to bite rild it will write logs to /sdcard/Download/wdlog/ which you should provide (adb pull /sdcard/Download/wdlog/) if you ever see them :)
      This watchdog was a massive amount of work and ofc included all selinux stuff around as well - encrypted / unencrypted devices are both working
      All the details how this watchdog works and how you can watch what he does check out the commit message

    • PLATFORM_SECURITY_PATCH = 2019-08-01
    • fixed: timing perfected for rild service on boot
    • fixed: several selinux denials
    • changed kernel branch to android-9.0_sfx to workaround issues with cypher (still syncing from there but allowing me to revert, add whatever I need as well)
    • Full details:
      kernel: commits
      g4-common tree: commits
      g4 unified tree: commits
      closed issues (if any): github issue tracker


    IMPORTANT:
    • If you encounter issues try this first:
      Code:
      adb shell
      su
      (or adb root when enabled)
      setenforce permissive
      Try again and if the issue is gone when in permissive mode: provide me a logcat as described here
      On step 3 I need the SELINUX log (option D)

    • Taking a backup before is recommended - always
    • As usual a "REGULAR CLEAN FLASH" is RECOMMENDED .
      See the FAQ #2 of this thread how to do a "regular clean flash": https://xdaforums.com/g4/development/rom-lineageos-16-0-t3929082/post79502871

    Keep in mind that almost all pie ROM's sharing the same common device tree (or main parts of it), same model device trees and for sure the same kernel - so you can enjoy most fixes for any pie ROM available..
    The above fixes are brought to you by the Suicide Squirrel Team :victory:

    ok enough of words, just one more thing:
    flash and enjoy this biting (woof), battery saving and simply wonderful new LOS version - ever :D



    Sent from my OnePlus 6T using XDA Labs
    31
    OK guys. This update is BIG.

    Not only bc it includes a lot of stuff but also the complete way how I build changed in the background.
    I have done dozens of tests to ensure it will not do any bad but well.. there is a always a chance right..
    Unifying our device tree makes it much easier to maintain and to add other not-yet added models - while it comes with the risk something goes wrong when it comes to blobs.

    As this is the very first round of my unified device tree I would highly recommend doing the following (I have done that in my manual builds but you get it from jenkins - so there is a tiny little chance of bad luck .. ):

    Pre-Cautions | Flashing instructions

    1. Recommended: Backup (system, userdata in TWRP, your internal storage which contains your photos etc elsewhere)
    2. Required: Do a "REGULAR CLEAN FLASH" (see bottom of this post)
    3. Flash LOS - DO NOT choose to reboot afterwards - stay in TWRP.
    4. TWRP menu: "Mount" --> choose "System"
    5. From a terminal execute:
      Code:
      adb shell md5sum /system/etc/firmware/venus.mbn
    6. Compare the value (last 4 characters is fully enough) with these:
      If you flash:
      h815, f500, h818, h819 it should be: ebc5d32c651bf061787e82258cf78a3c
      h810, h811, h812, ls991, us991, vs986 it should be: 78e5cf520d0de4a413ef1cfa7bbbe713
      WARNING: If that checksum is NOT as it should be: DO NOT PANIC! simply FLASH the PREVIOUS LOS version BEFORE booting!. This will ensure you will not blow a fuse.
      While the above test should be considered safe: If you are unsure about this procedure: WAIT before flashing until someone (or I) had done the above quick test from the builds jenkins is providing at my leech server.
    7. Whenever an error occurs while flashing in TWRP (e.g "E1001: Failed to update system image.Updater process ended with ERROR: 7")
      or if the above checksum does not match:
      provide the recovery.log (FAQ #4 A)!!
      ... then flash the previous LOS version to get back to life.


    New builds are cooking...

    build errors can happen .. so it might take longer until everything completes (as I can fix build issues tomorrow first if any)

    In progress (in that order):

    Live - View: https://lets.binbash.it:8800/job/LG-G4/job/LOS-16.0/job/Build all LGE-G4 models/workflow-stage/

    • H810

    Done:
    • H815 (a re-build to patch the gapps issue* is required - until then use the workaround as described)
    • H811 (a re-build to patch the gapps issue* is required - until then use the workaround as described)
    • H815 UsU (a re-build to patch the gapps issue* is required - until then use the workaround as described)
    • VS986
    • H812

    Noteworthy Changes:
    • All models moved from dedicated trees to an unified device tree. While doing that I fixed/added fingerprints, missing infos and more.
      Oh yea and ALL (relevant) models have been added (while I do not build all of them atm .. but now it will be easy to build if someone (or I) wants to).
      If you have one of these models: ls911, f500, us991 and want to have a model specific ROM release: let me know the model and a "+1 to build" notice as a post here. I will decide to add them to the list then. A current full run takes approx ~ 10 hours so who cares :p
      (u may noticed: I exclude h819 here as no one use that.. it even not had received official MM so.. I guess no interest for that anyways?!)

    • Voice mic sensitivity increased when on speaker

    • tons(!) of kernel fixes & optimizations thx to @kessaras . That includes e.g the graphic driver as well (thats why I keep staying with opengl and not switched to skiagl as I first planned to)

    • Selinux = Enforced . I have tested encryption here as well which goes fine (after adding all req policies obviously)
      If you encounter issues try this first:
      Code:
      adb shell
      su
      (or adb root when enabled)
      setenforce permissive
      Try again and if the issue is gone when in permissive mode: provide me a logcat as described here

    • Selinux = Enforced policies have been added and tested for:
      - LOS root-addon downloaded from today (16.0, arm64 ofc)
      - open_gapps-arm64-9.0-nano-20190709
      - even when I do not support it: Magisk 19.3

    • QCRIL db is now writable. Once your phone boots / RIL starts you receive an updated collection of emergency numbers (i.e. 911 for the US etc). Until now these updates went to hell as the DB is readonly (as it sits in the system partition). I fixed that in a way that it starts now with a base DB and will create a writable copy to /data which then can get updated.

    • One of the most noteworthy changes is ofc: RIL. It is fixed now and .. tbh .. it is not 100% clear why :D We fixed and implemented so many things in that time range that it is impossible to say what exactly fixed it. but who cares? it does not crash anymore and that solves a lot of lagging and issues we had.

    • Since ages all LOS builds should pass SafetyNet (I tested for h815 already) but if not - let me know and share your model and a logcat while trying to pass safetynet as it turns out it was a "should". The testing on that was a bit tricky as when you install magisk it will pass it perfectly (not surprisingly) but google play is still showing as certified even when magisk has been uninstalled completely afterwards (which was the way I tested). Another thing is that the device certification check does not happen immediately when you open the play store - it can take a minute or more (and it happens silently). in the meanwhile everything looks just nice (all apps are shown). Last but not least testing requires a full cleared play store. Long story short: a fix comes asap

    • PLATFORM_SECURITY_PATCH: 2019-07-05

    • and others ... and all the details

    IMPORTANT:

    Keep in mind that almost all pie ROM's sharing the same common device tree (or main parts of it), same model device trees and for sure the same kernel - so you can enjoy most fixes for any pie ROM available..
    The above fixes are brought to you by the Suicide Squirrel Team :victory:

    ok enough of words, just one more thing:
    FLASH and ENJOY that ultra stable, fast, smooth and best pie build for LOS - ever :)


    .-
    27
    New builds are cooking...

    I have added a test in my jenkins build process to ensure that the unified device tree is working as it should.
    Unifying our device tree makes it much easier to maintain and to add other not-yet added models - while it comes with the risk something goes wrong when it comes to blobs.

    Nevertheless:
    I would highly recommend doing the following (I have done that in my manual builds but you get it from jenkins - so there is a tiny little chance of bad luck .. ):

    Pre-Cautions | Flashing instructions

    1. Recommended: Backup (system, userdata in TWRP, your internal storage which contains your photos etc elsewhere)
    2. Required: Do a "REGULAR CLEAN FLASH" (see bottom of this post)
    3. Flash LOS - DO NOT choose to reboot afterwards - stay in TWRP.
    4. TWRP menu: "Mount" --> choose "System"
    5. From a terminal execute:
      Code:
      adb shell md5sum /system/etc/firmware/venus.mbn
    6. Compare the value (last 4 characters is fully enough) with these:
      If you flash:
      h815, f500, h818, h819 it should be: d1f6fe863643b1e8d1e597762474928c
      h810, h811, h812, ls991, us991, vs986 it should be: 78e5cf520d0de4a413ef1cfa7bbbe713
      WARNING: If that checksum is NOT as it should be: DO NOT PANIC! simply FLASH the PREVIOUS LOS version BEFORE booting!. This will ensure you will not blow a fuse.
      While the above test should be considered safe: If you are unsure about this procedure: WAIT before flashing until someone (or I) had done the above quick test from the builds jenkins is providing at my leech server.
    7. Whenever an error occurs while flashing in TWRP (e.g "E1001: Failed to update system image.Updater process ended with ERROR: 7")
      or if the above checksum does not match:
      provide the recovery.log (FAQ #4 A)!!
      ... then flash the previous LOS version to get back to life - without harming your device.
    8. if instead (as we all expect) all went well and you had opengapps before - ensure you reflash gapps

    Cooking order & LIVE cooking view

    • H815
    • H811
    • H815 UsU
    • VS986
    • H812
    • H810

    Live - View:


    Noteworthy Changes:

    Flashing method: "REGULAR CLEAN FLASH" is REQUIRED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    (See the FAQ #2 of this thread how to do this)


    Thanks (again) to @aoleary for his continues work on kernel and other parts!

    • complete re-work of the thermal handling, throttling and performance increase
      The kernel handles hotplug of all cores if needed (just HIGHLY optimized now), while frequencies will be handled by the resurrected thermal-engine service.
      Fully explained:
      Before, when I had started a video capture it was like I could cook a meal on the G4 after 5 min latest.
      Now its getting just warm. Ofc that comes with a little drawback as when reducing frequencies the system will get slower - but not as as slow as when unplugging the whole core(s) (which was the case before my changes).
      That means optimized throttling (as integrated in the above experiment build) is better for your performance then hotplugging (current stable LOS).
      At least it should.

      If you encounter any overheat or lagging issues or just being curious how this thermal stuff works grab/monitor the log while/after doing high cpu usage tasks:

      Code:
      adb logcat -b all | grep -i "thermal"

    • h815/h815_usu: switching back to LTE, GSM/WCDMA instead of just LTE, WCDMA for the preferred network.

    • switching to Anxiety I/O scheduler

    • revert rounded corners

    • platform security patch: 2020-05-05

    • Note: do not flash GAPPS newer then the build date. Recommended is to switch to a life without google anyways (see FAQ #9) but if you rely on Google then use GAPPS which are released at least 1-10 days before the build date. If you flash later versions it MIGHT work but a lot of weird issues can happen so better avoid it.

    • ...... and more. Read "Full details"


    • Full details:
      kernel: commits
      g4-common tree: commits
      g4 unified tree: commits
      closed issues (if any): github issue tracker
      LOS: all merged changes since last build

    IMPORTANT:
    • If you encounter issues try this first:
      Code:
      adb shell
      su
      (or adb root when enabled)
      setenforce permissive
      Try again and if the issue is gone when in permissive mode: provide me a logcat as described here -> on step 3 I need the SELINUX log (option D)

    • Taking a backup before is recommended - always

    Keep in mind that almost all pie ROM's sharing the same common device tree (or main parts of it), same model device trees and for sure the same kernel - so you can enjoy most fixes for any pie ROM available.. :victory:

    ok enough of words, just one more thing:
    flash and enjoy this lightning fast, even more secure, coooooool(ing) and simply beautiful new LOS version - ever :D


    .-