[Xperia Z4/Z3+ General] dl12345:
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

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

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