Database Users

Odd issues trying to update Cyanogen

Perhaps someone can shine some light on this issue I've been having with my Tmobile G1.
As above a TMobile G1 (32A) rooted, flashed with HardSPL and RA-Recovery(Tried CM-Recovery too)
I can install Cyanogen (any version) without issues (Wipe, Flash HTC 1.6, Flash Cyanogen, reboot) Works fine. The problems start when I try to update to a NEW version of Cyanogen, it flashes reboots and then jams at the second-stage of loading (Android skateboard logo) It will just sit there forever.
I ran logcat while its in that state and got a large output of code..
Code:
1.I/ServiceManager( 166): Waiting for sevice media.audio_flinger...
2.I/ServiceManager( 166): Waiting for sevice media.audio_flinger...
3.W/AudioSystem( 166): AudioFlinger not published, waiting...
4.I/ServiceManager( 166): Waiting for sevice media.audio_flinger...
5.I/ServiceManager( 166): Waiting for sevice media.audio_flinger...
6.I/ServiceManager( 166): Waiting for sevice media.audio_flinger...
7.I/ ( 325): ServiceManager: 0xac38
8.E/AudioHardwareMSM72XX( 325): Could not open libhtc_acoustic.so
9.W/AudioHardwareInterface( 325): Using stubbed audio hardware. No sound will be produced.
10.I/DEBUG ( 128): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11.I/DEBUG ( 128): Build fingerprint: 'tmobile/kila/dream/trout:1.6/DRC83/14721:user/ota-rel-keys,release-keys'
12.I/DEBUG ( 128): pid: 325, tid: 325 >>> /system/bin/mediaserver <<<
13.I/DEBUG ( 128): signal 11 (SIGSEGV), fault addr 00000100
14.I/DEBUG ( 128): r0 00000000 r1 00000001 r2 b0017b1c r3 000000fc
15.I/DEBUG ( 128): r4 b0017b1c r5 00000000 r6 0000da90 r7 ab01dfc8
16.I/DEBUG ( 128): r8 00000000 r9 00000000 10 00000000 fp 00000000
17.I/DEBUG ( 128): ip ab7084c4 sp becf3bc4 lr b0001aa7 pc b00019b0 cpsr 00000030
18.I/DEBUG ( 128): #00 pc b00019b0 /system/bin/linker
19.I/DEBUG ( 128): #01 lr b0001aa7 /system/bin/linker
20.I/DEBUG ( 128): stack:
21.I/DEBUG ( 128): becf3b84 ab7067a8 /system/lib/libaudio.so
22.I/DEBUG ( 128): becf3b88 b000f448 /system/bin/linker
23.I/DEBUG ( 128): becf3b8c b0001ae7 /system/bin/linker
24.I/DEBUG ( 128): becf3b90 b000cbb1 /system/bin/linker
25.I/DEBUG ( 128): becf3b94 b000cbb8 /system/bin/linker
26.I/DEBUG ( 128): becf3b98 00000000
27.I/DEBUG ( 128): becf3b9c b0002df0 /system/bin/linker
28.I/DEBUG ( 128): becf3ba0 b0017b18
29.I/DEBUG ( 128): becf3ba4 66a2ab86
30.I/DEBUG ( 128): becf3ba8 00000001
31.I/DEBUG ( 128): becf3bac 0000ad68 [heap]
32.I/DEBUG ( 128): becf3bb0 b0017b1c
33.I/DEBUG ( 128): becf3bb4 b0002ee0 /system/bin/linker
34.I/DEBUG ( 128): becf3bb8 df002777
35.I/DEBUG ( 128): becf3bbc e3a070ad
36.I/DEBUG ( 128): becf3bc0 becf3ca0 [stack]
37.I/DEBUG ( 128): #00 becf3bc4 b0017b1c
38.I/DEBUG ( 128): becf3bc8 00000000
39.I/DEBUG ( 128): becf3bcc becf3ca0 [stack]
40.I/DEBUG ( 128): becf3bd0 ab01dfc8 /system/lib/libaudioflinger.so
41.I/DEBUG ( 128): becf3bd4 b0001aa7 /system/bin/linker
42.I/DEBUG ( 128): becf3bd8 0000ad68 [heap]
43.I/DEBUG ( 128): becf3bdc ab708420 /system/lib/libaudio.so
44.I/DEBUG ( 128): becf3be0 becf3ca0 [stack]
45.I/DEBUG ( 128): becf3be4 ab7046d9 /system/lib/libaudio.so
46.I/DEBUG ( 128): becf3be8 0000ad68 [heap]
47.I/DEBUG ( 128): becf3bec ab708420 /system/lib/libaudio.so
48.I/DEBUG ( 128): becf3bf0 becf3ca0 [stack]
49.I/DEBUG ( 128): becf3bf4 ab7051d1 /system/lib/libaudio.so
50.I/DEBUG ( 128): becf3bf8 afe3bb00
51.I/DEBUG ( 128): becf3bfc afe0f3b0 /system/lib/libc.so
52.I/DEBUG ( 128): becf3c00 afe3bb74
53.I/DEBUG ( 128): becf3c04 afe0f3b0 /system/lib/libc.so
54.I/DEBUG ( 128): becf3c08 00000000
55.I/ServiceManager( 166): Waiting for sevice media.audio_flinger...
The only method I've found to update is to install Cyno from scratch (Wipe, htc flash..) and it will work fine from that point onwards.
I've tried replacing the SDcard, tried different recovery images (CM-Recovery and RA-Recovery) Tried wiping the Cache, Davik-cache, Ext partion wipe.
Tried rolling back to an older version of Cyanogen which did product intresting results, I could update from 4.0.2 to 4.0.4 without any issues but everything post C&D fails.
Obviously having to wipe my phone every time I want to update the OS (and given Cyanogens efforts thats quite offen) is annoying and unpratical as hell x.x
Anyone know/Seen anything like this?

I don't think I ever had to wipe between versions of his roms (or any AOSP rom). What worked for me was exactly what is on his wiki: wipe data, wipe extX, flash htc, reboot back to recovery, flash his, the when I update, just flash his newest.

Well, figured out why its not been working correctly..
After talking with Rikupw (creator of the fine NewReco recovery, thanks again btw)
It seems like the NAND is buggered.. tore apart the logfiles and it shows 2-3 I/O errors while trying to write/erase the flash, as well as problems mounting/writing to CACHE: (Which explains why its missing files and I keep loosing my google apps)
The new recovery environment "works around" the issues by not using Cache but, I fear it may have to go back to HTC for repair since I doubt many are qualified to replace the NAND.
Anyone know if they have a presence/contact in the UK? I checked their site but its vague at best

I've the same problem! I can't update cyanogen rom. I must install from scratch.
Same log as you: loop on "waiting for sevice media.audio_flinger"

[CM7] #28 wildfire still drops calls after a few seconds

Hello,
What I did:
- format all partitions except SDCARD
- removed all hidden android directories on SDCARD, only Media, downloaded nightly and gapps-gb and my nandroid-backup were left.
- reset to factory settings
- wiped cache
- applied newest radio 13.55.55.24H_3.35.20.10
- rebooted
- installed nightly #28
- installed gapps-gb-20110307
- rebooted
- entered SIM code
- skipped login to google
- called my mailbox
Phone call still drops after a few seconds.
D/SurfaceFlinger( 172): About to give-up screen, flinger = 0x93778
I/DEBUG ( 113): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 113): Build fingerprint: 'google/passion/passion:2.3.3/GRI40/102588:user/release-keys'
I/DEBUG ( 113): pid: 114, tid: 136 >>> /system/bin/rild <<<
I/DEBUG ( 113): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000004
I/DEBUG ( 113): r0 100ffb2c r1 00000001 r2 000000ff r3 00000000
I/DEBUG ( 113): r4 00000000 r5 000000ff r6 afd41504 r7 100ffb2c
I/DEBUG ( 113): r8 ae604fe5 r9 00000000 10 00100000 fp 00000001
I/DEBUG ( 113): ip 80074820 sp 100ffa90 lr 80050abf pc afd18ca0 cpsr 20000030
I/DEBUG ( 113): #00 pc 00018ca0 /system/lib/libc.so (fread)
I/DEBUG ( 113): #01 pc 00050abc /system/lib/libhtc_ril.so (ril_func_screen_state_notified)
I/DEBUG ( 113): #02 pc 00032d18 /system/lib/libhtc_ril.so (ril_request_on_request)
I/DEBUG ( 113): #03 pc 00004348 /system/lib/libril.so
I/DEBUG ( 113): #04 pc 00004cf0 /system/lib/libril.so
I/DEBUG ( 113): #05 pc 00004d3e /system/lib/libril.so
I/DEBUG ( 113): #06 pc 00005344 /system/lib/libril.so (_Z14ril_event_loopv)
I/DEBUG ( 113): #07 pc 0000505a /system/lib/libril.so
I/DEBUG ( 113): #08 pc 00011cf4 /system/lib/libc.so (__thread_entry)
I/DEBUG ( 113): #09 pc 000118a4 /system/lib/libc.so (pthread_create)
I/DEBUG ( 113):
I/DEBUG ( 113): code around pc:
I/DEBUG ( 113): afd18c80 bd101c18 1c15b5f0 b0851c0a 4e4d436a
I/DEBUG ( 113): afd18c90 447e9103 92011c1c d1012a00 e08e2500
I/DEBUG ( 113): afd18ca0 2b00685b 2100da01 1c076061 078289a0
I/DEBUG ( 113): afd18cb0 6be2d572 d16f2a00 58734943 2e00681e
I/DEBUG ( 113): afd18cc0 f7ffd101 89a3fd9d 60602000 d474069a
I/DEBUG ( 113):
I/DEBUG ( 113): code around lr:
I/DEBUG ( 113): 80050a9c 2800efd2 4b6fd139 af1d4a6f 18a918e8
I/DEBUG ( 113): 80050aac e840f7c1 1c231c04 22ff2101 f7c11c38
I/DEBUG ( 113): 80050abc 1c20e828 e818f7c1 18294868 f7c11c38
I/DEBUG ( 113): 80050acc 7987e8ce 2f654b5e 58efd110 29006839
I/DEBUG ( 113): 80050adc 485fdd09 4c624a5b 18a9182b 192a3304
I/DEBUG ( 113):
I/DEBUG ( 113): stack:
I/DEBUG ( 113): 100ffa50 ae604fe5 /system/lib/libril.so
I/DEBUG ( 113): 100ffa54 00000000
I/DEBUG ( 113): 100ffa58 00100000
I/DEBUG ( 113): 100ffa5c 80059c81 /system/lib/libhtc_ril.so
I/DEBUG ( 113): 100ffa60 800747a8
I am now back to my backup (#28 but switched kernel to HCDR.Kernel_4.1). With this kernel wifi is not very stable but at least I can use my phone for calls ;-).
After succesful boot with HCDR.Kernel_4.1, I use SetCPU to set 264MHz Min and 518MHz Max using interactive scaling. Afterwards I may install HCDR.Kernel_4.2 and use this, which has better WIFI and mobile data for me.
Regards
Mirko

Tried libhtc_ril_2.2.0110HM as well, still drops calls for me.

mfriedenhagen said:
Tried libhtc_ril_2.2.0110HM as well, still drops calls for me.
Click to expand...
Click to collapse
Stick with the fixed libril from Post #3972 , which seems to work for everybody. (Didnt get a failure report yet when I went through the thread.)

Please try arco's new test kernel here and report on the nightly thread whether it works or not.

nhnt11 said:
Please try arco's new test kernel here and report on the nightly thread whether it works or not.
Click to expand...
Click to collapse
Would like to reply on the nigthly thread but am still not allowed as I have not created enough posts .
What I did:
- Coming from a nightly #28 and libhtc_ril.so from 3972
- Booted into Recovery
- Cleaned cache and dalvik-cache.
- Installed nightly #28 and kernel from 4104 in one go
- Rebooted
- Signal drops during call when screen goes blank, service provider is gone and reappears after a few seconds.
Code:
W/InputManagerService( 167): Starting input on non-focused client [email protected] (uid=10011 pid=925)
D/AccelerometerListener( 392): orientation: horizontal
D/AccelerometerListener( 392): orientation: vertical
I/power ( 167): *** set_screen_state 0
D/SurfaceFlinger( 167): About to give-up screen, flinger = 0x93778
D/WifiService( 167): ACTION_SCREEN_OFF
I/DEBUG ( 109): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 109): Build fingerprint: 'google/passion/passion:2.3.3/GRI40/102588:user/release-keys'
I/DEBUG ( 109): pid: 1127, tid: 1128 >>> /system/bin/rild <<<
I/DEBUG ( 109): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000004
I/DEBUG ( 109): r0 100ffb2c r1 00000001 r2 000000ff r3 00000000
I/DEBUG ( 109): r4 00000000 r5 000000ff r6 afd41504 r7 100ffb2c
I/DEBUG ( 109): r8 ae604fe5 r9 00000000 10 00100000 fp 00000001
I/DEBUG ( 109): ip 80074820 sp 100ffa90 lr 80050abf pc afd18ca0 cpsr 20000030
D/NetworkCollector( 705): state now IDLE
I/DEBUG ( 109): #00 pc 00018ca0 /system/lib/libc.so (fread)
I/DEBUG ( 109): #01 pc 00050abc /system/lib/libhtc_ril.so (ril_func_screen_state_notified)
I/DEBUG ( 109): #02 pc 00032d18 /system/lib/libhtc_ril.so (ril_request_on_request)
I/DEBUG ( 109): #03 pc 00004348 /system/lib/libril.so
I/DEBUG ( 109): #04 pc 00004cf0 /system/lib/libril.so
I/DEBUG ( 109): #05 pc 00004d3e /system/lib/libril.so
I/DEBUG ( 109): #06 pc 00005344 /system/lib/libril.so (_Z14ril_event_loopv)
I/DEBUG ( 109): #07 pc 0000505a /system/lib/libril.so
I/DEBUG ( 109): #08 pc 00011cf4 /system/lib/libc.so (__thread_entry)
I/DEBUG ( 109): #09 pc 000118a4 /system/lib/libc.so (pthread_create)
I/DEBUG ( 109):
I/DEBUG ( 109): code around pc:
I/DEBUG ( 109): afd18c80 bd101c18 1c15b5f0 b0851c0a 4e4d436a
I/DEBUG ( 109): afd18c90 447e9103 92011c1c d1012a00 e08e2500
I/DEBUG ( 109): afd18ca0 2b00685b 2100da01 1c076061 078289a0
I/DEBUG ( 109): afd18cb0 6be2d572 d16f2a00 58734943 2e00681e
I/DEBUG ( 109): afd18cc0 f7ffd101 89a3fd9d 60602000 d474069a

mfriedenhagen said:
Would like to reply on the nigthly thread but am still not allowed as I have not created enough posts .
What I did:
- Coming from a nightly #28 and libhtc_ril.so from 3972
- Booted into Recovery
- Cleaned cache and dalvik-cache.
- Installed nightly #28 and kernel from 4104 in one go
- Rebooted
- Signal drops during call when screen goes blank, service provider is gone and reappears after a few seconds.
Click to expand...
Click to collapse
Alright thanks for testing, I've told arco about it. We'll see.

Would like to reply on the nigthly thread but am still not allowed as I have not created enough posts .
What I did:
- Coming from a nightly #28 and libhtc_ril.so from 3972
- Booted into Recovery
- Cleaned cache and dalvik-cache.
- Installed nightly #28 and kernel from 4139 in one go
- Rebooted
- Signal does not drop during calls from or to my phone when screen goes blank, service provider is not gone.
- Am able to receive SMS as well.
- WIFI/2G/3G are working.

[CM7] #30 wildfire still drops calls after a few seconds unless applying new kernel
What I did:
- Booted into Recovery
- Cleaned cache and dalvik-cache.
- Installed nightly #30
- Rebooted
- Signal does drop during calls from or to my phone when screen goes blank.
- Booted into Recovery
- Installed kernel from 4139
- Rebooted
- Signal does not drop during calls from or to my phone when screen goes blank, service provider is not gone.
- Am able to receive SMS as well.
- WIFI/2G/3G are working as well.

[CM 10.2] Google maps crashing on LG L5 E610

i have a problem with google maps crashing with cm-10.2-20131006-UNOFFICIAL-e610.zip (latest) and cm-10.2-20130928-UNOFFICIAL-e610.zip (previous) from PecanCM. The app displays a white screen, and then the whole cyanogenmod interface restarts (only the interface, not the whole device, no PIN is requested). This happens both with google maps from play store v7.2.0 and with older v6.14.3 (the older one manages to show some of the interface before crashing).
I can post logcat and dmesg from the device.
Is this a known problem? Are any workarounds known?
Sorry for the post here, but i'm a new user and can't post to the development forums (could someone forward the post there?)
edit:
according to logcat binder gets a segfault (binder uses some kernel memory for IPC - maybe this is a kernel bug?):
F/libc ( 3049): Fatal signal 11 (SIGSEGV) at 0xfbd2a0d3 (code=1), thread 3304 (Binder_6)
I/DEBUG ( 138): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 138): Build fingerprint: 'lge/m4_open_eu/m4:4.1.2/JZO54K/E61020c-EUR-XX.1367460723:user/release-keys'
I/DEBUG ( 138): Revision: '0'
I/DEBUG ( 138): pid: 3049, tid: 3304, name: Binder_6 >>> system_server <<<
I/DEBUG ( 138): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr fbd2a0d3

this seems to be solved in cm-10.2-20131014-UNOFFICIAL-e610.zip

flash beta 2

IDENTIFIED: cause of Xposed bootloop on Z3+

I've identified the cause of bootloops on Z3+ with Xposed.
When looking at a logcat after the bootloop it can be seen that the cause is com.google.android.gms, crashing after some intervention by Xposed libart.so
Code:
--------- beginning of crash
F/libc ( 8226): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x4 in tid 8241 (Signal Catcher)
I/ThermalEngine( 620): ACTION: BACKLIGHT - Setting max LCD brightness to 52
I/ThermalEngine( 620): Mitigation:BACKLIGHT:52
D/illumination-service( 626): 'thermal': Color 00343434, BrMode 0, OnMS 0, OffMS 0, Mode 0
D/clmlib ( 608): Got activities:0x0000000E
I/Process ( 1674): Sending signal. PID: 1674 SIG: 3
I/art ( 1674): Thread[9,tid=1687,WaitingInMainSignalCatcherLoop,Thread*=0x7f85521800,peer=0x12c02080,"Signal Catcher"]: reacting to signal 3
W/art ( 1674): Suspending all threads took: 18.026ms
I/DEBUG ( 608): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 608): UUID: b0341a53-b861-4217-bce5-8fe4798b8faf
I/DEBUG ( 608): Build fingerprint: 'Sony/E6553/E6553:5.0.2/28.0.A.8.251/1150652000:user/release-keys'
I/DEBUG ( 608): Revision: '0'
I/DEBUG ( 608): ABI: 'arm64'
I/DEBUG ( 608): pid: 8226, tid: 8241, name: Signal Catcher >>> com.google.android.gms <<<
I/DEBUG ( 608): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4
W/dex2oat ( 8299): Compilation of com.google.protobuf.nano.k com.google.c.g.c.a.n.mergeFrom(com.google.protobuf.nano.a) took 108.714ms
I/DEBUG ( 608): x0 0000000000000028 x1 0000000000000004 x2 000034746961770a x3 0000000000000070
I/DEBUG ( 608): x4 0000007f956ffa00 x5 0000007f956ff998 x6 0000000000000000 x7 0000000000001002
I/DEBUG ( 608): x8 0000007f956ff760 x9 0000000000001002 x10 00000000000000b0 x11 0000007f85512407
I/DEBUG ( 608): x12 0000000000000020 x13 88c5a592539be2de x14 88c5a592539be2de x15 0000007f956ff1dc
I/DEBUG ( 608): x16 0000007f967fafd8 x17 0000007f9644e9c8 x18 0000000000000028 x19 0000007f956ff760
I/DEBUG ( 608): x20 0000007f8d584048 x21 0000007f956ff990 x22 0000007f90ae24c0 x23 00000000702bd430
I/DEBUG ( 608): x24 0000007f96770020 x25 0000007f956ff990 x26 0000007f9675d238 x27 0000007f96774628
I/DEBUG ( 608): x28 0000007f96748000 x29 0000007f956ff6f0 x30 0000007f966b07f4
I/DEBUG ( 608): sp 0000007f956ff6f0 pc 0000007f966b06b4 pstate 0000000060000000
I/DEBUG ( 608):
I/DEBUG ( 608): backtrace:
I/DEBUG ( 608): #00 pc 000000000032a6b4 /system/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, char const*, art::mirror::ArtMethod*)+300)
I/DEBUG ( 608): #01 pc 00000000002fd718 /system/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+260)
I/DEBUG ( 608): #02 pc 00000000003087dc /system/lib64/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+172)
I/DEBUG ( 608): #03 pc 00000000002e9958 /system/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+96)
I/DEBUG ( 608): #04 pc 00000000002f21b4 /system/lib64/libart.so (art::SignalCatcher::HandleSigQuit()+1104)
I/DEBUG ( 608): #05 pc 00000000002f2dc8 /system/lib64/libart.so (art::SignalCatcher::Run(void*)+456)
I/DEBUG ( 608): #06 pc 000000000001ba00 /system/lib64/libc.so (__pthread_start(void*)+52)
I/DEBUG ( 608): #07 pc 0000000000017cf0 /system/lib64/libc.so (__start_thread+16)
An examination of the filesystem showed that com.google.android.gms (Google Play Services) installs an apk and an odex file in /data/data/com.google.android.gms/app_chimera/chimera-module-root/module-b4902ed544a9b2fc3415a9fb64fb048759fc2157. The long hashed folder name changes, as you can imagine with a name like "chimera".
Since I've previously had problems with un-odexed files and Xposed, I figured I try to manually de-odex it and then install xposed to see what happens. Previously, I'd been getting repeated boot loops no matter what I did.
What do you know, it worked. On first boot, I had a crash. When the device came up again it was stable and able to run Xposed and various modules. What did appear to have happened, however, is that after the first boot the hash filename had changed to a different hash and a new odex file and apk was in it's place.
With this knowledge in mind I did a more targeted search on Xposed and com.google.android.gms and come across this discussion on Github. Copy/pasting from the discussions
rovo69 said:
GMS correctly detects that the odex file is outdated and opens a DexClassLoader to recompile it. This finally ends up in ClassLinker::GenerateOatFile(), where one of the changes for Xposed finds the odex file and uses it for the --dex-file option instead of the APK. Normally, this works fine, but due to compiler-filter=interpret-only, the previous version of the odex has been optimized with more invoke-quick calls, which now fail to resolve with the new boot image.
So the odex-instead-of-APK mechanism has to be restricted to apply only for certain odex files.
Click to expand...
Click to collapse
There appear to be some commits to the Xposed repo to fix this problem, 18 days ago, which is post- the latest v74 of Xposed and so not available in any official release. I need to sync the latest AOSP 5.0.2 sources in order to build Xposed from the sources, so I'll get around to making an updated unofficial version of Xposed that hopefully should work on Z3+.
However in the meantime if you're impatient, you could use the temporary approach I used by manually deodexing the MapsModule.odex and replacing the apk/odex before installing. When I did this, I first did a reboot to TWRP, wiped cache and dalvik, then rebooted, ran Play Store. I verified that Play services worked ok, then rebooted to TWRP again and installed Xposed. I've attached the deodexed apk - when installing it don't forget to chmod it it 644.
On the first boot post installation of Xposed I got a crash. The second boot worked fine. Looking at the chimera module folder, I saw that the hashed folder name had changed and I speculate that the odex had been regenerated, I presume this time to one that was updated and so the Xposed crash didn't occur because of an attempted recompilation. Unfortunately I omitted to do a logcat on first boot and so I can't assert this for sure. I just know the workaround was successful, if a little clumsy...

Maybe you should try deodex or anther rom

风野龙太 said:
Maybe you should try deodex or anther rom
Click to expand...
Click to collapse
This problem is already fixed, though it's not officially released
http://forum.xda-developers.com/xperia-z4/development/unofficial-xposed-v74-sdk21-arm64-t3213833

Apps crashing in havoc os 2.9(athene)

Hey, I have flashed havoc os(v 2.9) on my athene device(moto g4+).A lot of apps(YouTube,Flipkart,Mx player....) have been crashing after using them for a minute or two. I tried flashing the stock rom and flashed havoc os but that did not solve the problem. Kindly provide a solution and thanks in advance. This is the error message:
time: 1591610936592
msg: Native crash: Aborted
stacktrace: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'motorola/athene/athene:7.0/NPJS25.93-14-13/3:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 14568, tid: 14676, name: RenderThread >>> com.flipkart.android <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'GL errors! frameworks/base/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp:110'
r0 00000000 r1 00003954 r2 00000006 r3 00000008
r4 000038e8 r5 00003954 r6 906b51a4 r7 0000010c
r8 ffffffff r9 906b5660 r10 906b5660 r11 906b5610
ip 906b5140 sp 906b5190 lr b0335d4d pc b032d856
backtrace:
#00 pc 0001d856 /system/lib/libc.so (abort+58)
#01 pc 00006cc5 /system/lib/liblog.so (__android_log_assert+156)
#02 pc 000891b8 /system/lib/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::swapBuffers(android::uirenderer::renderthread::Frame const&, bool, SkRect const&, android::uirenderer::FrameInfo*, bool*)+248)
#03 pc 00098ea4 /system/lib/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+648)
#04 pc 000a2978 /system/lib/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv+1648)
#05 pc 00076b80 /system/lib/libhwui.so (android::uirenderer::WorkQueue:rocess()+1268)
#06 pc 000b0e48 /system/lib/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+924)
#07 pc 0000c083 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+166)
#08 pc 000697f1 /system/lib/libc.so (__pthread_start(void*)+22)
#09 pc 0001ea29 /system/lib/libc.so (__start_thread+24)