Xposed
Xposed copied to clipboard
rovo89
Huawei Mate 9 (C432) got Bootloop on v90-beta1 xposed
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!
Thanks, Im flashing the oreo again to get the logcat for you cuz I had rolled back to Nougat. Wait for me :D
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
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!
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.
Thanks mate! At least you give not only me but also Mate 9 users a hope!
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...
@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*) \
@rovo89 You can disable rescue party to stop reboot to recovery, no ramdisk patch needed
@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
@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
@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...
@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
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!
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.
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
@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.
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...
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?
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.
@meetinnet What did kangvip exactly say? Is there any guide or something? Maybe I can try it on.
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.
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.