• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[ROM][UNOFFICIAL] LineageOS 17.1 for Nexus 5 (hammerhead) [DISCONTINUED]

Search This thread

_zagto

New member
Oct 6, 2020
2
1
I think I found the code that makes the display not lag on boot.

I can't post links because I'm a new member of this forum but you can go to my Github name zagto and search for android_frameworks_native repo and look at the lastest commit.

I built and installed the ROM with this and there is no more lag in when booting.
 

bluetooth-bug

Member
Jan 11, 2019
26
15
I think I found the code that makes the display not lag on boot.

I can't post links because I'm a new member of this forum but you can go to my Github name zagto and search for android_frameworks_native repo and look at the lastest commit.

I built and installed the ROM with this and there is no more lag in when booting.
I'll post that "z3DD3rBootLagFix" commit for you: https://github.com/zagto/android_frameworks_native/commit/167d318faab3696e0a98374aad5c4e58bb8a3ea8
 

Gaeguri

Member
Nov 28, 2019
15
2
I think I found the code that makes the display not lag on boot.

I can't post links because I'm a new member of this forum but you can go to my Github name zagto and search for android_frameworks_native repo and look at the lastest commit.

I built and installed the ROM with this and there is no more lag in when booting.

That is pretty awesome, thank you! May I ask how you found this?
 

_zagto

New member
Oct 6, 2020
2
1
That is pretty awesome, thank you! May I ask how you found this?

I started with transplanting files from z3's lastest build to mine an see if it the lag goes away. First I tried boot.img which did not change anything. Second guess was libsurfaceflinger.so because that is the component responsible "Faking VSYNC ..." messages in logcat. And there was no more lag.

Now it's time to compare the files what is actually different. To disassemble a .so file I use the following commnd: (this requires you to have GNU binutils for ARM installed)
Code:
arm-none-eabi-objdump -d --no-addresses --no-show-raw-insn -Mforce-thumb libsurfaceflinger.so | sed 's/0x\S*/HEX/g' > libsurfaceflinger.S
The flags --no-addresses --no-show-raw-insn and the regex are there to make it not print the hex addresses for everything, because the binary layout changes for different code, meaning different addresses everywhere, even where the code logic is the same. This is not fully effective but makes the assembly files somewhat comparable.

Now you can use your favorite diff tool (I use Meld) to compare the assembly files. There will be a lot of differences that don't mean anything like the compiler choosing a different register to store something or places where the disassembly is broken and tries to interpret addesses as instructions(?).

Around line 81200 you can see the density of differences becoming much higher (blue scrollbar in Meld). Around that area I looked at the individual changes and found one that stood out:

at line 81428 (my version) the z3 version hat additional code not corresponding to anything in mine:
Code:
	ldr.w	r0, [r9, #324]	; HEX
	cbnz	r0, <__emutls_t._ZN7android3pdx3rpc17ThreadLocalBufferIhNS1_30DefaultInitializationAllocatorIhNSt3__19al[email protected]@Base+HEX
	ldr.w	r0, [r9, #332]	; HEX
	cmp	r0, #9
	add.w	r1, r0, #1
	str.w	r1, [r9, #332]	; HEX
	blt.n	<__emutls_t._ZN7android3pdx3rpc17ThreadLocalBufferIhNS1_30DefaultInitializationAllocatorIhNSt3__19al[email protected]@Base+HEX
	movs	r4, #0
	str.w	r4, [r9, #332]	; HEX
	b.n	<__emutls_t._ZN7android3pdx3rpc17ThreadLocalBufferIhNS1_30DefaultInitializationAllocatorIhNSt3__19al[email protected]@Base+HEXa
It introduces new comparisons and jumps (b.n, blt.n) and uses two variables in memory that the code around does not use (offsets 324 and 332) from pointer in register r9. This means this is probably the code doing the magic but we need to translate it to C++ to integrate with new builds.

To get some context where exactly the code is inserted and what it does I analyzed the files with radare2. First re-enable address printing in objdump to find the corresponding addresses. For example line 81428 of disassembly is address 0x7d898 in my file.

To make analyzing easier, for my version I don't use the file extracted from the device. Instead in the directory where you compile the ROM from source, in out/target/product/hammerhead/symbols/system/lib there will be a version that includes debugging symbols that are removed before packaging the ROM.
Code:
[[email protected] SurfaceFlinger-diff]$ radare2 symbols.so 
 -- In r2land usability is treated as a bug
[0x00048000]> aa
[x] Analyze all flags starting with sym. and entry0 (aa)
[0x00048000]> s 0x7d898
[0x0007d898]> pd
│     ╎╎╎   ; CODE XREF from android::impl::DispSync::addPresentFence(std::__1::shared_ptr<android::FenceTime> const&) @ 0x7d8cc
│    ┌────> 0x0007d898      97f83c00       ldrb.w r0, [r7, 0x3c]       ; DispSync.cpp:541
│    ╎╎╎╎   0x0007d89c      0028           cmp r0, 0
│    ╎╎╎└─< 0x0007d89e      3ff424af       beq.w 0x7d6ea
│    ╎╎╎    0x0007d8a2      d7e90c01       ldrd r0, r1, [r7, 0x30]
radare2 will print the code with nice comments what is from what line in C++ and what is called from where. Use s and pd (seek and print disassembly) commands to look around in the file.

So I found out the following:
  • we are in DispSync::addPresentFence method in line 541
  • r7 (r9 in z3 version) is the this pointer of C++, r4 holds the return value (0=false)
  • DispSync class is defined in DisplaySync.h file which can be used to calculate to what variable the offsets are corresponding to. If my calculations are right 324 is mNumResyncSamples. 332 is mPresentFences which makes no sense because that is of type shared_ptr, but the code is incrementing it by one, which you would not do with a shared_ptr. This means probably a new variable was introduced here.
 
  • Like
Reactions: blackmambazzz

Gaeguri

Member
Nov 28, 2019
15
2
I started with transplanting files from z3's lastest build to mine an see if it the lag goes away. First I tried boot.img which did not change anything. Second guess was libsurfaceflinger.so because that is the component responsible "Faking VSYNC ..." messages in logcat. And there was no more lag.

Now it's time to compare the files what is actually different. To disassemble a .so file I use the following commnd: (this requires you to have GNU binutils for ARM installed)
Code:
arm-none-eabi-objdump -d --no-addresses --no-show-raw-insn -Mforce-thumb libsurfaceflinger.so | sed 's/0x\S*/HEX/g' > libsurfaceflinger.S
The flags --no-addresses --no-show-raw-insn and the regex are there to make it not print the hex addresses for everything, because the binary layout changes for different code, meaning different addresses everywhere, even where the code logic is the same. This is not fully effective but makes the assembly files somewhat comparable.

Now you can use your favorite diff tool (I use Meld) to compare the assembly files. There will be a lot of differences that don't mean anything like the compiler choosing a different register to store something or places where the disassembly is broken and tries to interpret addesses as instructions(?).

Around line 81200 you can see the density of differences becoming much higher (blue scrollbar in Meld). Around that area I looked at the individual changes and found one that stood out:

at line 81428 (my version) the z3 version hat additional code not corresponding to anything in mine:
Code:
	ldr.w	r0, [r9, #324]	; HEX
	cbnz	r0, <__emutls_t._ZN7android3pdx3rpc17ThreadLocalBufferIhNS1_30DefaultInitializationAllocatorIhNSt3__19al[email protected]@Base+HEX
	ldr.w	r0, [r9, #332]	; HEX
	cmp	r0, #9
	add.w	r1, r0, #1
	str.w	r1, [r9, #332]	; HEX
	blt.n	<__emutls_t._ZN7android3pdx3rpc17ThreadLocalBufferIhNS1_30DefaultInitializationAllocatorIhNSt3__19al[email protected]@Base+HEX
	movs	r4, #0
	str.w	r4, [r9, #332]	; HEX
	b.n	<__emutls_t._ZN7android3pdx3rpc17ThreadLocalBufferIhNS1_30DefaultInitializationAllocatorIhNSt3__19al[email protected]@Base+HEXa
It introduces new comparisons and jumps (b.n, blt.n) and uses two variables in memory that the code around does not use (offsets 324 and 332) from pointer in register r9. This means this is probably the code doing the magic but we need to translate it to C++ to integrate with new builds.

To get some context where exactly the code is inserted and what it does I analyzed the files with radare2. First re-enable address printing in objdump to find the corresponding addresses. For example line 81428 of disassembly is address 0x7d898 in my file.

To make analyzing easier, for my version I don't use the file extracted from the device. Instead in the directory where you compile the ROM from source, in out/target/product/hammerhead/symbols/system/lib there will be a version that includes debugging symbols that are removed before packaging the ROM.
Code:
[[email protected] SurfaceFlinger-diff]$ radare2 symbols.so 
 -- In r2land usability is treated as a bug
[0x00048000]> aa
[x] Analyze all flags starting with sym. and entry0 (aa)
[0x00048000]> s 0x7d898
[0x0007d898]> pd
│     ╎╎╎   ; CODE XREF from android::impl::DispSync::addPresentFence(std::__1::shared_ptr<android::FenceTime> const&) @ 0x7d8cc
│    ┌────> 0x0007d898      97f83c00       ldrb.w r0, [r7, 0x3c]       ; DispSync.cpp:541
│    ╎╎╎╎   0x0007d89c      0028           cmp r0, 0
│    ╎╎╎└─< 0x0007d89e      3ff424af       beq.w 0x7d6ea
│    ╎╎╎    0x0007d8a2      d7e90c01       ldrd r0, r1, [r7, 0x30]
radare2 will print the code with nice comments what is from what line in C++ and what is called from where. Use s and pd (seek and print disassembly) commands to look around in the file.

So I found out the following:
  • we are in DispSync::addPresentFence method in line 541
  • r7 (r9 in z3 version) is the this pointer of C++, r4 holds the return value (0=false)
  • DispSync class is defined in DisplaySync.h file which can be used to calculate to what variable the offsets are corresponding to. If my calculations are right 324 is mNumResyncSamples. 332 is mPresentFences which makes no sense because that is of type shared_ptr, but the code is incrementing it by one, which you would not do with a shared_ptr. This means probably a new variable was introduced here.

Thank you very much for this detailed and interesting writeup! I could have never done this myself with the experience that I have. I will try to reproduce this myself for the learning experience.
 

_zagto

New member
Oct 6, 2020
2
1
Turns out this is actually an issue on Lineage Gerrit (#70070). Also my reverse engineering was incomplete because there are two additional spots where the counter is reset to zero, so the workaround is not applied more often than necessary.
 

jjcdennis

Senior Member
Jun 20, 2015
463
99
Toronto
Sorry for the newbie'ish questions. I have had my main phone toast itself and my backup is a Nexus 5 with Lineage 14.1, 7.1.2 NJH47F running on it. I have a couple questions and I can't remember the answers. I have flashed this phone in the past, but there have been many flashes and devices since then:
I would like to update the phone and this rom looks like a good choice. Would I have to do a fill clean wipe including data before flashing this rom? By clean flash I mean formatting the data and clean flashing system, cache. This is what the process was for my LG G4.
If yes, where do I store the rom/gapps, twrp if I'm wiping the data? Which version of twrp. I think I have 3.2.1-0 on it now. Had a SD card slot on my last phone.
Are there any other steps I have to take before flashing, ie any preflash updates to the phone. I'm aware of repartitioning and I think this wipes the data and system?
Thanks, I appreciate the help.
 
Last edited:

TomiLynch

Senior Member
Jan 31, 2017
444
433
Google Nexus 5
Moto E
Sorry for the newbie'ish questions. I have had my main phone toast itself and my backup is a Nexus 5 with Lineage 14.1, 7.1.2 NJH47F running on it. I have a couple questions and I can't remember the answers. I have flashed this phone in the past, but there have been many flshes and devices since then:
I would like to update the phone and this rom looks like a good choice. Would I have to do a fill clean wipe including data before flashing this rom?
If yes, where do I store the rom/gapps, twrp if I'm wiping the data? Which version of twrp. I think I have 3.2.1-0 on it now.
Are there any other steps I have to take before flashing, ie any preflash updates to the phone.
Thanks, I appreciate the help.

Yes, you do have to do a clean flash because you are doing a major Android version upgrade, and there have been significant changes since Nougat. However, the last versions of Android are to large for our device's System partition size, so in order to install this rom, you first have to repartition and make it larger. This process will wipe your device entirely, so make sure to backup anything you want to your computer before doing it.

Fortunately, our beloved dev made a modded version of TWRP with which you can do this very easily. Just follow the instructions in this thread: https://forum.xda-developers.com/go...recovery-twrp-hh-nexus-5-hammerhead-t4047653/
You only have to repartition once, and must continue to use that version of TWRP.

- After repartitioning, your phone will be wiped, so connect it to your computer and transfer Rom, OpenGapps Pico, and Magisk .zips
- Just to do things the proper way, go to Wipe > Advanced wipe and select System, Data, Dalvik and Cache. DO NOT SELECT INTERNAL STORAGE OR YOU WILL HAVE TO TRANSFER THE FILES AGAIN.
- After wiping, go to Install, and flash rom, gapps, Magisk, in that order.
- Reboot and enjoy!
 

jjcdennis

Senior Member
Jun 20, 2015
463
99
Toronto
Yes, you do have to do a clean flash because you are doing a major Android version upgrade, and there have been significant changes since Nougat. However, the last versions of Android are to large for our device's System partition size, so in order to install this rom, you first have to repartition and make it larger. This process will wipe your device entirely, so make sure to backup anything you want to your computer before doing it.

Fortunately, our beloved dev made a modded version of TWRP with which you can do this very easily. Just follow the instructions in this thread: https://forum.xda-developers.com/go...recovery-twrp-hh-nexus-5-hammerhead-t4047653/
You only have to repartition once, and must continue to use that version of TWRP.

- After repartitioning, your phone will be wiped, so connect it to your computer and transfer Rom, OpenGapps Pico, and Magisk .zips
- Just to do things the proper way, go to Wipe > Advanced wipe and select System, Data, Dalvik and Cache. DO NOT SELECT INTERNAL STORAGE OR YOU WILL HAVE TO TRANSFER THE FILES AGAIN.
- After wiping, go to Install, and flash rom, gapps, Magisk, in that order.
- Reboot and enjoy!

Thanks a lot for your help with this. I couldn't remember the part about internal storage. If I remember correctly the rom, gapps and magisk go to the root of the phone storage, which will not get wiped. The LG G4 usu process and rom installation required a format of the data and I wasn't sure if this was required. Having an SD card on the LG allowed me to store the rom/etc to safeguard it.
BTW, I'm pretty impressed with this circa 2014 phone. It seems fast enough and definitely does the job as I need it done.
 

ZhenMing

Senior Member
Feb 27, 2008
514
79
Penang
Xiaomi Mi 10T / 10T Pro
I convert from LOS 14.1 to this yesterday and I found the camera will hang during video shooting, after certain of time, proximately >10mins.

My Nexus 5 now become my webcam through DroidCam and it just don't last. i will hang after certain of time and the error was more like the camera was locked. I can't even use the original camera to call the camera module.

Restart to resume the working condition.

Anyone had any idea how to fixed this?
 

mandayugana

Senior Member
Jan 17, 2012
239
75
I convert from LOS 14.1 to this yesterday and I found the camera will hang during video shooting, after certain of time, proximately >10mins.

My Nexus 5 now become my webcam through DroidCam and it just don't last. i will hang after certain of time and the error was more like the camera was locked. I can't even use the original camera to call the camera module.

Restart to resume the working condition.

Anyone had any idea how to fixed this?

I sometimes experienced camera error while on video call. The only thing I need was just restarting cameraserver. There is an app at Playstore that do the job: Kill Camera.
 

pepperser

New member
Mar 13, 2011
1
0
hmm some mystery step seems to be necessary to do a normal install of this something about repartitioning something then no clear direction from there I feel like i should not have to ask but what are you supposed to do to get it to install with gapps?
 

anivegmin

Member
Mar 29, 2019
44
19
I'm enjoying this ROM and everything seems to work fine... Apart from the following 3 bugs -

My phone will randomly shut down after a few hours of non use (not good if you've set an alarm)

Adaptive brightness also seems to randomly change and won't remember my setting.

When switching between Alarms only and Priority only ring volume sometimes gets set to zero.
 

DReddowg

New member
Oct 18, 2020
3
0
Awesome build. Thanks for bringing some life back into the old girl. I want to go through my issues to see what people think of my workaround.
I first up installed 17.1 over the factory image with app data and everything left in place and it worked but was glitchy. Once I realised what I had done I wiped everything using the HH twrp, copied in the 0929 build, resized partition, flashed build, flashed pico gapps and then on reboot......nothing. It sat on the lineage OS boot animation for quite a while before booting back into recovery, as I have seen it had happened to a few before me. As with the advice given to others I tried a few different orders but no success, ie wipe all, flash only 17.1, wipe cache, reboot into twrp, reboot system - wipe all, reboot in twrp, flash 17.1, reboot into twrp, wipe cache, reboot into twrp, resize system, flash gapps reboot system. ANYHOW, all orders gave the same response. In the end I tried flashing back to a stock image. From there I rooted again, flashed hh twrp, resized, NO WIPE, flashed 17.1, wiped cache, reboot into twrp, flashed gapps, reboot system, and this appears to be working.
Now I am pretty sure thats a no no but unsure why and it appears to be working fine although I havent installed my sim yet.
Any thoughts for this noob?? Thanks for reading.
 

jjcdennis

Senior Member
Jun 20, 2015
463
99
Toronto
- After repartitioning, your phone will be wiped, so connect it to your computer and transfer Rom, OpenGapps Pico, and Magisk .zips
- Just to do things the proper way, go to Wipe > Advanced wipe and select System, Data, Dalvik and Cache. DO NOT SELECT INTERNAL STORAGE OR YOU WILL HAVE TO TRANSFER THE FILES AGAIN.
- After wiping, go to Install, and flash rom, gapps, Magisk, in that order.
- Reboot and enjoy![/QUOTE]
Well finally got around to doing this and it really was easy. I haven't used Magisk before, so the only missing part was that Magisk manager has to be installed via Android apk after completing the rom, gapps, Magisk install via twrp. .
The ol' Nexus 5 is pretty snappy after this update.
Thanks again for your help...
 

anivegmin

Member
Mar 29, 2019
44
19
I know we are currently living in strange and uncertain times but will this rom continue to be maintained? It was being updated every couple of weeks but there has been no update since 29/09. Thanks.
 

jp3_99

Member
Jun 12, 2010
7
0
Having issue getting network connection working. Worked fine on android 6.0.1 but on lineage 17.1-20200929 it will see the sim card and sprint network but will not give me service. I have tried reflashing the last radio update. Also trying to go to carrier setting doesn't work.

Hopefully someone has an idea because I am at a loss.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 8
    New build is out (lineage-17.1-20210917-UNOFFICIAL-hammerhead-signed.zip)
    Short change log:
    • September security patch
    • Some fixes for device overlays
    • Fixed connection to Wi-Fi with enabled (not enforced) PMF
    • Added fast charge in battery settings as in LineageOS 18.1
    • Charging currents are reduced to stock values as on android 6.0.1
    • Tweaks for CPU governor and I/O scheduler
    • Added 5th row with numbers in keyboard
    • Updated interactive governor
    • Updated ZRAM driver (version from 4.1 kernel)
    • Updated F2FS driver (version from 3.10 kernel)
    • Small fixes and improvements in kernel
    • Maybe something else that i've forgot to mention)
  • 80
    LineageOS 17.1 is a free, community built, aftermarket firmware distribution of Android 10.0 (Q), which is designed to increase performance and reliability over stock Android for your device.

    Code:
    #include <std_disclaimer.h>
    
    /*
    * Your warranty is now void.
    *
    * We are not responsible for bricked devices, dead SD cards,
    * thermonuclear war, or you getting fired because the alarm app failed. Please
    * do some research if you have any concerns about features included in this ROM
    * before flashing it! YOU are choosing to make these modifications, and if
    * you point the finger at us for messing up your device, we will laugh at you.
    *
    */
    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.

    The source code for LineageOS is available in the LineageOS Github repo. And if you would like to contribute to LineageOS, please visit our Gerrit Code Review. Your changelog is whatever was merged into gerrit.

    Known bugs:
    Fantom icons in launcher after installing/updating apps. Fixed since 2020-03-18 build.
    Expanded desktop doesn't work. LineageOS team planning to remove this feature entirely. This feature was removed in latest builds.
    For some users phone won't boot after installing Magisk. Right now there is no solution. Use rom without Magisk. Fixed since 2020-02-22 build. Credits to @Sashko98 for help!
    Screen timeout does not work if the Screen lock is set to none. Fixed since 2020-05-31 build.
    Random drops of the bluetooth connection. Fixed since 2020-06-13 build.
    Screen mirroring via slimport HDMI adapter doesn't work.
    PMF aka 802.11w doesn't work.

    Downloads:
    ROM: https://sourceforge.net/projects/hammerhead-lineageos/files/17.1/
    GAPPS: https://opengapps.org/?arch=arm&api=10.0&variant=pico

    Credits:
    Many thanks to the LineageOS team and all the contributors out there in the community

    Contributors:
    @z3DD3r, @EnesSastim, @Sashko98, @razorloves, esa-n, jprimero15 and others

    Source Code:
    Device tree: https://github.com/z3DD3r/android_device_lge_hammerhead/tree/lineage-17.1
    Kernel tree: https://github.com/z3DD3r/android_kernel_lge_hammerhead/tree/lineage-17.1
    Vendor tree: https://github.com/z3DD3r/android_vendor_lge/tree/lineage-17.1

    Android version: 10.0.0 (Q)
    Kernel version: Linux 3.4.113
    Status: Stable

    Created 2020-01-23
    Last Updated 2020-06-23
    28
    Don't worry. This build was released by me. Even if my device is dead i still can release new builds from time to time with updates from LOS team...
    19
    Hello everyone!

    Someone maybe already seen that i've release another one update for LOS 17.1 (2020-12-31). Unfortunately this will be last update from my side, cos i need to shutdown my build server and use it for another purpose.

    I've also released one more version of LOS 17.1 (2020-12-31). You can download it from 'signed' folder from sourceforge. This build doesn't have OTA support but it was signed with release keys. I remember that someone asked for such builds) In other terms these builds are the same. Be aware that YOU MUST DO A CLEAN INSTALLATION OF THIS 'SIGNED' BUILD WITH ALL WIPES. YOU CANNOT INSTALL 'SIGNED' BUILD ON TOP OF PREVIOUS BUILDS.

    There is one more update from my side. I can't promise anything, but everything is possible ;)
    LOS_18_1.png


    HAPPY NEW YEAR!
    17
    Hi there

    Unfortunately i should announce that i stopped N5 support. I have no time to support this device anymore. Furthermore and my N5 is almost dead (motherboard corrupted by water)
    Daily builds already stopped. Maybe i'll release a single last build with May security patch in a few days...

    I want to thank everyone who helped to support N5 all this year. It was a really fun and interesting time! Thanks a lot!!!
    Time to move forward...




    What does this mean from your perspective? What's the difference between unofficial and official support?
    Official builds can't include some changes that are included in unofficial builds. Also official maintainer should continue to support and improve builds for supported device...

    @z3DD3r I am trying to compile LineageOS 17.1 with your sources and the build runs through successfully.

    But I am always facing the same issue after flashing (clean, factory reset and no additional zips) the image: The boot animation is displayed very slowly (~1 frame per second). Only the animation seems to be affected, as you can hear the screen locking sound after a couple of minutes while the animation is still running. Once the animation is finished after 5+ minutes, the screen is black, since the device locked itself in the meantime. If you turn the screen on, unlock it and interact with the device, it runs just fine. Snappy and quick, as you would expect. It seems to be just the boot animation, that is flawed in my personal builds, but not in your builds.
    Is there anything I am missing or doing wrong? Are you building from exactly the same sources that you published? Have you also seen this issue?[/code]
    Not all changes can be included in device trees. Some patches are picked from gerrit. I've already answered similar question here.

    Did some further investigation. Had a Whatsapp call yesterday and had the logging running while the call was going on. Found the following lines before the camera was not showing new frames anymore:

    [05-10 10:13:43.765 383:22238 E/mm-camera]
    module_faceproc_port_event_func:886] MCT_EVENT_MODULE_BUF_DIVERT 131074, Cannot start FD, active 20003, frameid 22715 0, native 1, mapped 1 1

    [05-10 10:13:43.784 306:22245 E/Parcel]
    fcntl(F_DUPFD_CLOEXEC) failed in Parcel::read, i is 0, fds is -1, fd_count is 1, error: Too many open files

    [05-10 10:13:43.790 306:22245 E/Camera3-OutputStream]
    getBufferLockedCommon: Stream 0: Can't dequeue next output buffer: Invalid argument (-22)

    [05-10 10:13:43.790 306:22245 W/Camera2Client]
    notifyError: Received recoverable error 3 from HAL - ignoring, requestId 10000001

    So it seems filedescriptors remain open? Most likely something in the ROM somewhere?

    Whatsapp again... Unfortunately this will not be fixed. At least by me...
    16
    Hi there.
    I highly suggest everyone update to 2020-03-18. This build includes some fixes for SELinux, Bluetooth and kernel.