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

[steadfasterX]

Hi Steadfaster,

Thanks for taking the time out to look into this, especially while you're on holiday.

The log files can be found: (square brackers inserted in the URLs to prevent the Forum anti-spammer from blocking my post)

boot_lc_kernel.txt - https[://]del.dog/motinaduki

boot_lc_full.txt - https[://]del.dog/ettingerin

boot_lc_crash.txt - Not uploaded as the file was 0KB, empty.


As for the workaround you suggested, if I create the file /data/misc/bluetooth/bdaddr which simply contains a single line with any bullsh*t Bluetooth MAC address (e.g: E0-E8-16-93-72-61) do you believe that would get things working again? Does the file expect the MAC address to be formatted with dashes like my example, or with colons? (e.g: E0:E8:16:93:72:61)

If the workaround is not as simple as I make it out to be, I'm more than happy to wait for the full fix when you return from holiday.

Cheers,

-zwab

thx @zwab for the logs. As it is hard to re-produce the issue here (tried everything which came in my mind) I would prefer to test with your phone.
I have also created an issue for that here: https://github.com/Suicide-Squirrel/issues_pie/issues/49

Could you pls do a backup in TWRP of just the "Bootloader" (just tick that one and backup). You will find the backup in the TWRP folder of the storage you selected. Pls upload that somewhere safe (as it contains your IMEI) and share the link to me by PM.

thx
sfX

.-

 

[verbage]

Hi all, I am running the 20200223 version of this ROM on an H811, and when I make or receive a call, the screen goes black, and there is no way to access it till the other person hangs up, or I plug something into the 3.5mm audio jack (which will turn the screen on instantly). Calls work fine using Bluetooth, and the screen does not go black. For sure, this is an issue related to the proximity sensor, and indeed, after installing a few sensor reading apps like AndroSense and Sensor Box, I can see my proximity sensor seems to be dead even though it was working with other LOS16 versions from before the 20200223 release. I have been living with this hiccup since late February when I first installed the 20200223 release, but since nobody else has mentioned it, and I am partly able to avoid it by using Bluetooth, well, I have not pursued a fix.

Well, fast-forward to today, and I just had an identical problem with an LG G5 H830. In that case, I was able to identify the problem quite easily by luck--a new tempered glass screen protector I had installed on that phone was blocking the proximity sensor, and by simply removing the screen protector, that fixed the problem. However, in the case of my LG G4 H811, this is certainly not the problem as it does not have a screen protector at all.

If you do a search on something like "screen goes black during calls", you will see lots of results from lots of different phones and ROMs. In sum, it is not a problem limited to the LG G4 on LOS16. Many of the fixes that are suggested involve recalibrating the proximity sensor, and that is usually done by punching in a USSD code that will pop up a hidden testing menu. But those codes apparently only work on stock firmwares--they do not necessarily work on LOS16. There are also some apps in the Google Play Store that can supposedly be used to reset/recalibrate the proximity sensor, but I have tried several to no avail.

So I am turning to you all to see if there is a more direct way of recalibrating a G4 proximity sensor. For example, perhaps the current proximity sensor calibration data is kept as a simple text file that I could either manipulate directly with a text editor, or simply delete, and have it recreated on-the-fly during the next boot or similar? Maybe this is just wishful thinking on my part?

Another thought--though I do not necessarily think my H811's proximity sensor is defective because it was working with earlier versions of LOS16, for sure, that remains a possibility. But I already know it is not working at the level of the GUI so trying to test it at that level is not helpful. This leads me to wonder if there is anything that runs at a lower that I could be used to diagnose the proximity sensor? For example, maybe I could fastboot a tools or diagnostic partition and do the analysis there (much like one would fastboot a recovery partition to install it permanantly)? Does anybody know about something like this, i.e. a way to test sensors a level that is lower than the GUI?

Thanks in advance for any guidance you can provide!

 

[steadfasterX]

Hi all, I am running the 20200223 version of this ROM on an H811, and when I make or receive a call, the screen goes black, and there is no way to access it till the other person hangs up, or I plug something into the 3.5mm audio jack (which will turn the screen on instantly). Calls work fine using Bluetooth, and the screen does not go black. For sure, this is an issue related to the proximity sensor, and indeed, after installing a few sensor reading apps like AndroSense and Sensor Box, I can see my proximity sensor seems to be dead even though it was working with other LOS16 versions from before the 20200223 release. I have been living with this hiccup since late February when I first installed the 20200223 release, but since nobody else has mentioned it, and I am partly able to avoid it by using Bluetooth, well, I have not pursued a fix.

Well, fast-forward to today, and I just had an identical problem with an LG G5 H830. In that case, I was able to identify the problem quite easily by luck--a new tempered glass screen protector I had installed on that phone was blocking the proximity sensor, and by simply removing the screen protector, that fixed the problem. However, in the case of my LG G4 H811, this is certainly not the problem as it does not have a screen protector at all.

If you do a search on something like "screen goes black during calls", you will see lots of results from lots of different phones and ROMs. In sum, it is not a problem limited to the LG G4 on LOS16. Many of the fixes that are suggested involve recalibrating the proximity sensor, and that is usually done by punching in a USSD code that will pop up a hidden testing menu. But those codes apparently only work on stock firmwares--they do not necessarily work on LOS16. There are also some apps in the Google Play Store that can supposedly be used to reset/recalibrate the proximity sensor, but I have tried several to no avail.

So I am turning to you all to see if there is a more direct way of recalibrating a G4 proximity sensor. For example, perhaps the current proximity sensor calibration data is kept as a simple text file that I could either manipulate directly with a text editor, or simply delete, and have it recreated on-the-fly during the next boot or similar? Maybe this is just wishful thinking on my part?

Another thought--though I do not necessarily think my H811's proximity sensor is defective because it was working with earlier versions of LOS16, for sure, that remains a possibility. But I already know it is not working at the level of the GUI so trying to test it at that level is not helpful. This leads me to wonder if there is anything that runs at a lower that I could be used to diagnose the proximity sensor? For example, maybe I could fastboot a tools or diagnostic partition and do the analysis there (much like one would fastboot a recovery partition to install it permanantly)? Does anybody know about something like this, i.e. a way to test sensors a level that is lower than the GUI?

Thanks in advance for any guidance you can provide!

sounds like a hardware defect. flash a previous LOS version or 15.1 to see if its gone then but I really believe its your hardware. proximity issues are mainly happening due to protection glasses (even when right now there is none but if there were any some of the glue might reached the sensor). if that is not the case its 90% a hardware issue. ofc there is always a chance (10%) that a ROM causes this so your best way to check is flashing STOCK again and not a custom ROM.

.-

 

[dat_benjie]

Hallo !

Please bear in mind that you only have to do one of the three options in FAQ #9, point 3.
Personnally, I do the following :


Have you tried it yet ? Does it work ? If it does, no need to go further.

Hi,
Please excuse the very late answer. I did it first with this step, but it didn't work. So I thought that I had to do these other steps as well. However, as I didn't need the GPS working these past days, I had the opportunity to use this ROM without Gapps and I came to the conclusion that I wanted just the tiniest Google Footprint, as for comfort.
So I did a reflash and installed nano gapps.
Long story short, thank you for your help (even though belated).
Cheers

 

[verbage]

sounds like a hardware defect. flash a previous LOS version or 15.1 to see if its gone then but I really believe its your hardware. proximity issues are mainly happening due to protection glasses (even when right now there is none but if there were any some of the glue might reached the sensor). if that is not the case its 90% a hardware issue. ofc there is always a chance (10%) that a ROM causes this so your best way to check is flashing STOCK again and not a custom ROM.

Ok, thanks for the suggestion--I suspected this would mean going all the way back to stock to verify whether this is a hardware defect or not. I was just trying to avoid that for all the time it will involve But I will use it as an opportunity to upgrade to your new 20200515 version on the way back.

It would sure be cool to have something like a diagnostics/testing partition image (similar to a recovery partition image) that one could fastboot for basic, bare-metal testing of hardware. Even it was just raw reads of output values from a sensor, at least one could use this to assess whether a particular sensor is still functional or not. I wonder if from recovery, one could open up a shell, and just raw read a /dev node corresponding to a sensor? I really have no idea about how sensors are set up and polled under Android so don't laugh too much as my suggestion!!! But let's take it even a level lower--imagine doing the same thing, but from download mode--that's about as bare-metal as you can get!

Thanks again, @steadfasterX, for keeping the LG G4 alive for many of us!

 

[breversa]

Hi,
Please excuse the very late answer. I did it first with this step, but it didn't work. So I thought that I had to do these other steps as well. However, as I didn't need the GPS working these past days, I had the opportunity to use this ROM without Gapps and I came to the conclusion that I wanted just the tiniest Google Footprint, as for comfort.
So I did a reflash and installed nano gapps.
Long story short, thank you for your help (even though belated).
Cheers

I understand, that's what I did in the past too, until 1- MicroG became easier to install and 2- I realised that even Nano GApps was getting too bloated with Google features I wanted to NOT have.

 

[steadfasterX]

Ok, thanks for the suggestion--I suspected this would mean going all the way back to stock to verify whether this is a hardware defect or not. I was just trying to avoid that for all the time it will involve But I will use it as an opportunity to upgrade to your new 20200515 version on the way back.

It would sure be cool to have something like a diagnostics/testing partition image (similar to a recovery partition image) that one could fastboot for basic, bare-metal testing of hardware. Even it was just raw reads of output values from a sensor, at least one could use this to assess whether a particular sensor is still functional or not. I wonder if from recovery, one could open up a shell, and just raw read a /dev node corresponding to a sensor? I really have no idea about how sensors are set up and polled under Android so don't laugh too much as my suggestion!!! But let's take it even a level lower--imagine doing the same thing, but from download mode--that's about as bare-metal as you can get!

Thanks again, @steadfasterX, for keeping the LG G4 alive for many of us!

There is such a thing : the LG mini OS. It sits in a specific partition and can be booted from stock from the hidden menu . There are other ways to boot the miniOS but that's complicated so stock will help here as well.



Sent from my OnePlus 6T using XDA Labs

 

[verbage]

There is such a thing : the LG mini OS. It sits in a specific partition and can be booted from stock from the hidden menu . There are other ways to boot the miniOS but that's complicated so stock will help here as well.

A-ha, thanks for the hint. If I cannot figure it out, I will make the long slog back to stock and go from there.

 

[Daniel071]

Constant freezing and lagging

I'm on the LG G4 (h811, build 20200515), and I experience constant lagging and freezing. This happens usually on apps like Youtube Vanced and reddit. The screen would become unresponsive for about 15 to 30 seconds and the System UI would freeze. I set SELinux to permissive and I'm experiencing less lagging however, it still occurs occasionally. I've done some searching on this thread and found that some people had a similar issue.

Here is a logcat for when my phone was freezing:
https://gist.github.com/daniel071/cb0f9a1ff093c8ce7f7e9c65c1a3d458

 

[bel57]

Yes me too, phone becomes slow or start to freeze and takes some time to get back to normal - usually a reboot does the trick. Seems like a common issue on Pie roms, says that the UI/interface or current app is not responding.
Anyhoo I'm on the previous version so I'll take time soon to wipe, flash and test the latest build.
Thanks for your work.

 

[Feduz]

Yes me too, phone becomes slow or start to freeze and takes some time to get back to normal - usually a reboot does the trick. Seems like a common issue on Pie roms, says that the UI/interface or current app is not responding.
Anyhoo I'm on the previous version so I'll take time soon to wipe, flash and test the latest build.
Thanks for your work.

I had a similar issue, app were very slow. Than I discovered something useful on battery settings, this function "reduce" the power of app for maintain battery. I have disabled it and now the LG works better

 

[bel57]

Which function? The battery saving/optimizer setting?
Well on or off it doesn't make such a difference, AFAIK that's a random behavior happening here.
Edit: even on charge (not even low battery) sometimes the phone becomes slow.

 

[Daniel071]

I had a similar issue, app were very slow. Than I discovered something useful on battery settings, this function "reduce" the power of app for maintain battery. I have disabled it and now the LG works better

Yes me too, phone becomes slow or start to freeze and takes some time to get back to normal - usually a reboot does the trick. Seems like a common issue on Pie roms, says that the UI/interface or current app is not responding.
Anyhoo I'm on the previous version so I'll take time soon to wipe, flash and test the latest build.
Thanks for your work.

I've tried disabling and enabling the battery saving feature and it doesn't really make much of a difference. I've also tried rebooting however, the freezing still occurs. I also noticed that the freezing occurs much more frequently on Youtube Vanced, for Reddit and other apps it only freezes occasionally.

 

[steadfasterX]

I'm on the LG G4 (h811, build 20200515), and I experience constant lagging and freezing. This happens usually on apps like Youtube Vanced and reddit. The screen would become unresponsive for about 15 to 30 seconds and the System UI would freeze. I set SELinux to permissive and I'm experiencing less lagging however, it still occurs occasionally. I've done some searching on this thread and found that some people had a similar issue.

Here is a logcat for when my phone was freezing:
https://gist.github.com/daniel071/cb0f9a1ff093c8ce7f7e9c65c1a3d458

Yes me too, phone becomes slow or start to freeze and takes some time to get back to normal - usually a reboot does the trick. Seems like a common issue on Pie roms, says that the UI/interface or current app is not responding.
Anyhoo I'm on the previous version so I'll take time soon to wipe, flash and test the latest build.
Thanks for your work.

I had a similar issue, app were very slow. Than I discovered something useful on battery settings, this function "reduce" the power of app for maintain battery. I have disabled it and now the LG works better

When the freezing happens do 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 a paste service



Sent from my OnePlus 6T using XDA Labs

 

[Daniel071]

When the freezing happens do 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 
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 a paste service



Sent from my OnePlus 6T using XDA Labs

I ran the above commands when my LG G4 froze while in the launcher,
Here is the logcat:
https://gist.github.com/daniel071/27597c0290754ea671c85eb74921ccd4

 

[steadfasterX]

I ran the above commands when my LG G4 froze while in the launcher,
Here is the logcat:
https://gist.github.com/daniel071/27597c0290754ea671c85eb74921ccd4

thx that helps

.-

 

[steadfasterX]

@Daniel071 , @bel57 , @Feduz

if you like pls test the following.

1. extract the attached file
2. boot to TWRP/SHRP
3. exec:
   

   adb shell mount /system
   adb push init.qcom.post_boot.sh /system/vendor/bin/
   adb shell
   chcon u:object_r:qti_init_shell_exec:s0 /system/vendor/bin/init.qcom.post_boot.sh
   sync
   reboot

4. test. if the issues occur again share the debug info again as described here
   

 

[Daniel071]

Still have the same freezing (it's worse now)

@Daniel071 , @bel57 , @Feduz

if you like pls test the following.

1. extract the attached file
2. boot to TWRP/SHRP
3. exec:
   

   adb shell mount /system
   adb push init.qcom.post_boot.sh /system/vendor/bin/
   adb shell
   chcon u:object_r:qti_init_shell_exec:s0 /system/vendor/bin/init.qcom.post_boot.sh
   sync
   reboot

4. test. if the issues occur again share the debug info again as described here

I ran the above commands, and I constantly got these warnings while running them:

linker: /system/etc/ld.config.txt:21: warning: property "namespace.default.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:21: warning: property "namespace.default.search.paths +" redefinition
linker: /system/etc/ld.config.txt:25: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:25: warning: property "namespace.default.asan.search.paths +" redefinition
linker: /system/etc/ld.config.txt:26: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:26: warning: property "namespace.default.asan.search.paths +" redefinition
linker: /system/etc/ld.config.txt:27: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:27: warning: property "namespace.default.asan.search.paths +" redefinition
linker: /system/etc/ld.config.txt:28: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:28: warning: property "namespace.default.asan.search.paths +" redefinition

It seemed to be successful however, I still get constant lagging and freezing.

Here's the logcat:
(While I was running the commands, my phone froze for about 2 minutes, much longer than previously)
https://gist.github.com/daniel071/8f2d7bc6dfb5bf9eb91e71412a355bd4


EDIT:
My phone becomes very unresponsive, very frequently even after setting SELinux to permissive, should I revert the commands you gave me and if so, how?

 

[steadfasterX]

I ran the above commands, and I constantly got these warnings while running them:

linker: /system/etc/ld.config.txt:21: warning: property "namespace.default.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:21: warning: property "namespace.default.search.paths +" redefinition
linker: /system/etc/ld.config.txt:25: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:25: warning: property "namespace.default.asan.search.paths +" redefinition
linker: /system/etc/ld.config.txt:26: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:26: warning: property "namespace.default.asan.search.paths +" redefinition
linker: /system/etc/ld.config.txt:27: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:27: warning: property "namespace.default.asan.search.paths +" redefinition
linker: /system/etc/ld.config.txt:28: warning: property "namespace.default.asan.search.paths +" redefinition
WARNING: linker: /system/etc/ld.config.txt:28: warning: property "namespace.default.asan.search.paths +" redefinition

It seemed to be successful however, I still get constant lagging and freezing.

Here's the logcat:
(While I was running the commands, my phone froze for about 2 minutes, much longer than previously)
https://gist.github.com/daniel071/8f2d7bc6dfb5bf9eb91e71412a355bd4


EDIT:
My phone becomes very unresponsive, very frequently even after setting SELinux to permissive, should I revert the commands you gave me and if so, how?

uhm .. which TWRP version?

-.

 

[Daniel071]

uhm .. which TWRP version?

-.

TWRP version 3.3.1-1


I got it from:
https://twrp.me/lg/lgg4.html