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

Quote:

Originally Posted by rovo69 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.

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

Attached Files

MapsModule.zip - [Click for QR Code] (981.3 KB)