[G4 Android Development] steadfasterX:
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:

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:

adb shell
dmesg | grep "ramoops|pstore"

[ 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:

adb shell
ls -la /dev/pmsg0

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):

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:

boot Android

once booted : reboot to TWRP

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

once in TWRP ensure that "Cache" is mounted in the "Mount" menu (if not mount it by ticking the box)

open a terminal on your PC and type:

adb pull /cache/debug/boot_lc_crash.txt
adb pull /cache/debug/boot_lc_full.txt
adb pull /cache/debug/boot_lc_kernel.txt

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 of this thread because:

it has a link to TWRP flashable files for updating your bootloader with 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!!!

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!!!

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:

adb install com.google.android.gms-[REPLACETHIS].apk

c) if you have root:

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:

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:

On windows:

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:

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:

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):

adb root (must be enabled in dev options)
adb shell setprop debug.hwui.renderer opengl

or make that change persistent:

boot TWRP
backup system
mount system
adb shell
echo "debug.hwui.renderer=opengl" >> /system/build.prop
sync
reboot