Huawei Mate 9 (C432) got Bootloop on v90-beta1 xposed

[lemonade747]

I got bootloop after flash the lastest beta1 v90 xposed and it CANNOT be fixed by flashing xposed installer.zip, only restore or flash the system file work. Hope you can fix this for Mate 9 community! Thanks!

[rovo89]

Please post the logcat, otherwise I can't help.

[lemonade747]

Thanks, Im flashing the oreo again to get the logcat for you cuz I had rolled back to Nougat. Wait for me :D

[lemonade747]

Hi @rovo89 sorry It took me long time to get the logcat for you. I got it via adb. Please look at this. Thanks! https://drive.google.com/open?id=1otqBMOh-TksWotZQWgc7wMQaC8DXawa2

[lemonade747]

Hey friend @rovo89 please look at this and tell me whether this bug could be fixed or not :( I really really love Oreo but I think at this time nobody can live without xposed :( thanks!

[rovo89]

01-14 17:31:03.153 F/DEBUG   ( 1291): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-14 17:31:03.153 F/DEBUG   ( 1291): Build fingerprint: 'HUAWEI/MHA-L29/HWMHA:8.0.0/HUAWEIMHA-L29/362(C432):user/release-keys'
01-14 17:31:03.153 F/DEBUG   ( 1291): Revision: '0'
01-14 17:31:03.153 F/DEBUG   ( 1291): ABI: 'arm64'
01-14 17:31:03.153 F/DEBUG   ( 1291): pid: 596, tid: 596, name: main  >>> zygote64 <<<
01-14 17:31:03.153 F/DEBUG   ( 1291): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
01-14 17:31:03.153 F/DEBUG   ( 1291): Cause: null pointer dereference
01-14 17:31:03.153 F/DEBUG   ( 1291):     x0   0000000000000000  x1   0000000000000000  x2   0000000000000000  x3   0000000000000001
01-14 17:31:03.153 F/DEBUG   ( 1291):     x4   0000000000000001  x5   0000007a8dee9fd4  x6   0000007a92d90000  x7   0000000000000d1e
01-14 17:31:03.153 F/DEBUG   ( 1291):     x8   c3bc72a01ee34657  x9   c3bc72a01ee34657  x10  0000000000000000  x11  0000000000000000
01-14 17:31:03.153 F/DEBUG   ( 1291):     x12  0000007a8dec8920  x13  0000007a8dec8974  x14  0000007a8dec89d4  x15  0000000000000000
01-14 17:31:03.153 F/DEBUG   ( 1291):     x16  0000007fd5e67490  x17  0000000000000000  x18  0000000000000000  x19  0000007a8e0a3a00
01-14 17:31:03.153 F/DEBUG   ( 1291):     x20  000000006f85a528  x21  0000000000000000  x22  0000000000000000  x23  0000000000000000
01-14 17:31:03.153 F/DEBUG   ( 1291):     x24  0000007fd5e67490  x25  0000007fd5e673d8  x26  0000007a8dfa1000  x27  00000001a2917ec0
01-14 17:31:03.153 F/DEBUG   ( 1291):     x28  0000007a8dfa7118  x29  0000007fd5e67480  x30  0000007a8dea8bfc
01-14 17:31:03.153 F/DEBUG   ( 1291):     sp   0000007fd5e67340  pc   0000007a8dea8c44  pstate 0000000060000000
01-14 17:31:03.172 F/DEBUG   ( 1291): 
01-14 17:31:03.172 F/DEBUG   ( 1291): backtrace:
01-14 17:31:03.172 F/DEBUG   ( 1291):     #00 pc 00000000004f0c44  /system/lib64/libart.so (artInvokeDirectTrampolineWithAccessCheck+180)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #01 pc 000000000051029c  /system/lib64/libart.so (art_quick_invoke_direct_trampoline_with_access_check+92)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #02 pc 0000000000510a38  /system/lib64/libart.so (art_quick_invoke_static_stub+600)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #03 pc 00000000000d9a4c  /system/lib64/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+260)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #04 pc 000000000013892c  /system/lib64/libart.so (_ZN3art11ClassLinker15InitializeClassEPNS_6ThreadENS_6HandleINS_6mirror5ClassEEEbb+3392)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #05 pc 00000000001211d0  /system/lib64/libart.so (_ZN3art11ClassLinker17EnsureInitializedEPNS_6ThreadENS_6HandleINS_6mirror5ClassEEEbb+172)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #06 pc 000000000035a0b8  /system/lib64/libart.so (_ZN3artL11FindFieldIDERKNS_18ScopedObjectAccessEP7_jclassPKcS6_b+824)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #07 pc 0000000000339018  /system/lib64/libart.so (_ZN3art3JNI10GetFieldIDEP7_JNIEnvP7_jclassPKcS6_+628)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #08 pc 000000000001e9f0  /system/lib64/libopenjdk.so (register_sun_nio_ch_IOUtil+104)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #09 pc 0000000000016180  /system/lib64/libopenjdk.so (JNI_OnLoad+128)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #10 pc 00000000002dce30  /system/lib64/libart.so (_ZN3art9JavaVMExt17LoadNativeLibraryEP7_JNIEnvRKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEEP8_jobjectP8_jstringPS9_+2204)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #11 pc 0000000000445bf4  /system/lib64/libart.so (_ZN3art7Runtime17InitNativeMethodsEv+328)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #12 pc 0000000000443e84  /system/lib64/libart.so (_ZN3art7Runtime5StartEv+1244)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #13 pc 00000000002df1bc  /system/lib64/libart.so (JNI_CreateJavaVM+524)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #14 pc 00000000000bc978  /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime7startVmEPP7_JavaVMPP7_JNIEnvb+4260)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #15 pc 00000000000bceac  /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime5startEPKcRKNS_6VectorINS_7String8EEEb+400)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #16 pc 00000000000040a8  /system/bin/app_process64_xposed (main+1456)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #17 pc 000000000001b790  /system/lib64/libc.so (__libc_init+88)
01-14 17:31:03.172 F/DEBUG   ( 1291):     #18 pc 0000000000003a58  /system/bin/app_process64_xposed (do_arm64_start+80)

No idea where this issue is coming from. I assume it can be fixed, but I'm currently busy with many other issues already, so you'll have to be patient.

[lemonade747]

Thanks mate! At least you give not only me but also Mate 9 users a hope!

[rovo89]

Same thing happens on Huawei Honor View 10. I'll investigate.

[lemonade747]

Thanks! We are still waiting for you!

[dosomder]

Also happening on the Honor 9 with 8.0

Tombstone from crash attached tombstone_01.txt

[rovo89]

I had difficulties to even debug this because V10 reboots to eRecovery after 4 Zygote crashes. After many hours of trying, I found out that it's because the service is marked as "critical" in the init scripts (which isn't the case in AOSP). I patched the ramdisk to remove this flag and now I could finally debug this issue.

The issue itself is pretty strange, I already spent many hours on it. Latest findings are that artInvokeDirectTrampolineWithAccessCheck() shouldn't be called at all at this stage, but rather the Quick-to-Interpreter bridge. The entry point for the method is set correctly, but it seems that the offsets used in the oat file are different from the runtime environment. I suspect that Huawei made changes to this file: https://android.googlesource.com/platform/art/+/oreo-release/runtime/entrypoints/quick/quick_entrypoints_list.h It would be an off-by-one problem if it calls InvokeDirectTrampolineWithAccessCheck instead of QuickToInterpreterBridge, so if they removed one of the elements...

[dosomder]

@rovo89 Is only one line removed from this file? In libart.so I can't find these three

71: V(JniMethodFastStart, uint32_t, Thread*) \
74: V(JniMethodFastEnd, void, uint32_t, Thread*) \
77: V(JniMethodFastEndWithReference, mirror::Object*, jobject, uint32_t, Thread*) \

[frap129]

@rovo89 You can disable rescue party to stop reboot to recovery, no ramdisk patch needed

[rovo89]

@dosomder I'm not sure if you can see that just from grepping the library. I'll need to investigate more, but I'm currently blocked as the build server is down.

@frap129 Thanks, I do set persist.sys.disable_rescue to 1, but that didn't help. Besides that, at least in AOSP I don't see any reference from the reboot code to rescue party: https://android.googlesource.com/platform/system/core/+/oreo-release/init/service.cpp#299

[dosomder]

@rovo89 Maybe I'm wrong, here is this code: https://android.googlesource.com/platform/art/+/master/runtime/entrypoints/quick/quick_entrypoints.h#45

struct PACKED(4) QuickEntryPoints {
#define ENTRYPOINT_ENUM(name, rettype, ...) rettype ( * p ## name )( __VA_ARGS__ );
#include "quick_entrypoints_list.h"
  QUICK_ENTRYPOINT_LIST(ENTRYPOINT_ENUM)
#undef QUICK_ENTRYPOINT_LIST
#undef ENTRYPOINT_ENUM
};

So there is an enum of the entry points with prefix p for each func name

And in libart.so there is a list with all this functions and prefix p

[rovo89]

@dosomder Interesting, but there might also be other places where this is generated. Or the compiler might strip some of the names and keep others. Fields in a struct are access by offset, not by name, which is exactly that is the problem here.

QUICK RESOLUTION TRAMPOLINE:
AOSP 8.0:    ldr.w pc, [r9, #660] ; 0x294
AOSP 8.1:    ldr.w pc, [r9, #668] ; 0x29c
Huawei:      ldr.w pc, [r9, #668] ; 0x29c

QUICK TO INTERPRETER BRIDGE:
AOSP 8.0:    ldr.w pc, [r9, #664] ; 0x298
AOSP 8.1:    ldr.w pc, [r9, #672] ; 0x2a0
Huawei:      ldr.w pc, [r9, #672] ; 0x2a0

Whether it's just coincidence that Huawei has the same offset as in 8.1 is unclear. I'm also surprised to see that the difference between the two fields is 8 instead of 4, I thought it would be aligned at 4 bytes and hold a pointer, which should be 4 bytes in arm.

Anyway, that is the problem: This code (which is compiled into the oat file) access/executes something at a certain offset, but as Xposed is based on AOSP, it doesn't find there what it expects, which results in more or less random behavior.

I have compared the quick entry points list between 8.0 and 8.1. They are identical, but yet there is a difference in the offsets. So it must be some other change in the (native) Thread class which caused this difference.

The other questions are obviously a) how to detect this at runtime and b) how to work around this. As you can see, offsets are hardcoded into oat files in several places. That would mean I'd have to completely ignore the compiled code in the oat files on Huawei devices, or recompile them. That's something I hoped could be avoided since Nougat...

[dosomder]

@rovo89 well in thread.h class there was this field also added (8.1): https://android.googlesource.com/platform/art/+/master/runtime/thread.h#162

static constexpr bool kVerifyStack = kIsDebugBuild;

Maybe this is the other 4 bytes?

And for detecting, couldn't you check the variable before the pointers in the struct (e.g. https://android.googlesource.com/platform/art/+/master/runtime/thread.h#1686 ).

So for example let's say

    size_t thread_local_objects;

is at offset #500 in AOSP 8.0 and at #504 in AOSP 8.1. So you check one of these offsets and see if it's a pointer address or not

[rovo89]

That's a constant, not a field. ;) interrupted and user_code_suspend_count are fields though: https://android.googlesource.com/platform/art/+/365719c23d809e595cf320bfba40e76bb4e87940%5E!/#F14 https://android.googlesource.com/platform/art/+/88fd720b6799184c8ad61e766a6d37af33ed30ef%5E!/#F15 (and 2*32bit would be 8 bytes)

The correct offsets depend on the source code from which libart.so is compiled. The library included in Xposed will always have the same offsets. It's the oat files which differ. Inside the oat files, the compiled code is like above (ldr.w pc, [r9, #672] ; 0x2a0). That code would have to detect and use the right offset. So I'd have to analyze which assembler code is stored in the oat files and would have to patch it. Which probably won't be possible because the files are on /system and because SELinux should prevent writing to executable regions in memory. Besides that, only a few common calls are done from a well-known place in the oat file. Such calls might also be done from any compiled Java method, e.g. the call to pDeoptimize. It's hardly possible to detect all of these assembler instructions. And that would mean I'd indeed have to run the whole system on interpreter/JIT or recompile... not nice!

[dosomder]

Ah I see :)

I don't know if this is ugly but you could make these functions in libart.so simple stubs. At the beginning detect which version the oat files use. And then forward the function call in the stub to the right function according to the version. So that way it's not the oat code that has to detect the right offset but it's Xposed.

Example: OAT calls #672 => libart.so checks version (it's Huawei 8.0) => forward call to quickToInterpreterBridge.

[lemonade747]

Sorry when asking this but how are you doing these days friend? Hope you're fine with your fixing process as well as your real life 🌝 Im still waiting for any news from you everyday 👍 thanks

[dosomder]

@rovo89 is the Xposed ART source for Oreo available? On github I only see nougat as the latest branch. I would like to try it myself as it's really a pain without xposed.

[ghost]

@rovo89 hi will there be any possible fix on this Huawei issue?

[espaciosalter20]

It seems that fixes for this issue (bootloop over 8.0 roms on Huawei/Honor) isn't coming soon... :/ I have this also on my Oreo p10...

[laststandingdroid]

Meanwhile android emui 8.1 devices can rock xposed :)

[espaciosalter20]

@laststandingdroid how's that?

[kangvip]

Huawei P20/P20Pro is EMUI8.1(Andorid8.1), Xposed 90b3 can work now!

[nampud]

Would it work if the libart.so of Xposed was modified, maybe adding a field or something to pad it to have the same offsets as the Huawei libart.so? I'd try if we had the Xposed source code 🤔 Edit: would two dummy methods at the beginning of that list do it maybe?

[meetinnet]

Is it possible to use xposed on V10 by updating system to EMUI8.1(Andorid8.1) as @kangvip said? I just can not take the bootloop risk to reset the phone because too many things on it now.

[yanghaoxie]

@meetinnet What did kangvip exactly say? Is there any guide or something? Maybe I can try it on.

[kangvip]

Xposed 90-beta3 only work on EMUI8.1(Android 8.1). P20/P20Pro is EMUI81,it can work . V10 is EMUI8.0(Android 8.0) it can't work.

[rovo89]

Please try this for Huawei devices on Android 8.0: https://www.dropbox.com/s/bkb7iluiqob8qwa/xposed-v90-sdk26-arm64-beta4-test1.zip?dl=1

After installing, it will take ~15 minutes for the first boot, please be patient. If it doesn't work even after waiting for a long time, please post a logcat.

[schwabe93]

@rovo89 works on Mate 10 Pro , Android 8.0 .

[ulli5]

2018-05-21-11-22-31.txt After flashing beta4 to my Mate 9, Android 8, I could reboot the system, but apps that need xposed don't work. One of them says "Xposed framework not found" Added logcat

[yanghaoxie]

Tried on honor v10, works great. And only take 2-3 minutes to reboot first time after installing in twrp.

[espaciosalter20]

Tried beta 4 on p10 with latest Oreo version available (369) emui 8.0 with magisk 16.4 on it. No bootloop, xposed modules working as they should. No problems detected so far... Thanks @rovo89

[nicksimoneau]

I confirm my Huawei P10 bootloop was fixed with the Beta 4 :) Thanks a lot :)

P.S. on the first boot the xposed installer say that the framework is not enabled but after a reboot everything is okay !

[meetinnet]

@yanghaoxie hey which way did you use to root your v10, I tried TWRP+SuperSU 2.82 but failed, thanks.

[yanghaoxie]

My phone model is BKL-AL20 with system version 165(C00), I am using official twrp, and I am using official Magisk 16.0 to root my device. I just install xposed in twrp and it worked. @meetinnet

[meetinnet]

Thank you I will try Magisk-v16.0 later. @yanghaoxie

[Abdelali-Elbihari]

Device: Huawei mate 10 ALP-L09 It boots now but xposed installer says it´s not active. and it doesn´t give me access to the log. It lets me activate the modules, i activated GravityBox and now it gave me bootloop.

[nicksimoneau]

Bihariel, just reboot your device, and check again. I got the same problem and reboot has fix it.

[Abdelali-Elbihari]

All right, everything working perfectly after rebooting, now it activated and modules are working as expected.

[balthasarian]

@rovo89 Huawei Mate 10 Lite (RNE-L01) Oreo 8.0.0.304(C432) Magisk v16.4

Every single module that I use works perfect. Thank you for your amazing work...

[wangaamao]

@kangvip

3Q for Mate10 129SP6 ROM

[ulli5]

I'm happy for anyone with a Mate 10 or P10, but I only have a Mate 9. The bootloop is fixed, but xposed does not work. Has anyone tested the Beta4 with a Mate 9?

[laststandingdroid]

Beta 4 works great on EMUI 8.0.0 Honor 8 Pro only isse is root requests being blocked/popup window doesn't being shown and magisk refuses to show it, i'll try fetch a log

[JackChen007]

@ulli5 Here, I use Huawei Mate 9, and the Beta4 also fixed the bootloop. While, "xposed not installed" or sth similar occured.

[JackChen007]

@ulli5 @rovo89 After I install the newest version (V3.1.5) of Xposed Installer, now the Framework is active. (Huawei Mate 9 on EMUI 8.0 / Android Oreo , with Xposed Framework Version 90-beta-test1)

[ulli5]

The solution of JackChen007 works with my MHA-L29, Android 8, german. Thanks @rovo89 for the valuable hard work and @JackChen007 for the good support.

[jorgev121]

It's not working for me, already rooted, installed through recovery, (apk 3.1.5 and framework beta 4 - test1), all seems ok in app, but if i use a module has no response from xposed. I'm using a mate9 MHA-L29 8.0.0.

[lflf2004]

@rovo89 When will it be automatically updated to beta4