Bootloop on ASUS ME302C / MeMO Pad FHD (x86) #6
Comments
|
Like wrote at http://forum.xda-developers.com/showpost.php?p=51193327&postcount=9784 |
|
Thanks, maybe that will help. I remember that Houdini caused some problems on the Genymotion emulator, but I think I worked around that... |
|
Sure, everything can be found at https://01.org/android-ia/documentation/developers. |
|
Thanks. Too bad that the new version is not open source, that would be really helpful. I usually do this with |
|
setprop dalvik.vm.execution-mode int:fast works :) |
|
So without JIT, Xposed is working fine? |
|
I don't know, if fine. Haven't test it much, but the stuck on boot logo in gone away. Android starts and Xposed Installer, say it's installed 👍 |
|
Ok, I'm pretty sure know what the issue is. I need to reset the code cache after placing hooks. This is done by setting The crashing statement is I will send you test version where I hard-code the offset to +0x98. If that works, I will have to find indicators when to use which offset. |
|
I tested a little bit now, gravity box works. :-) Vielen Dank :-) |
|
That sounds good! It's ok that this command doesn't work, I just found it in the documentation when I looked up how to disable JIT (as I didn't remember the command). Here is the test version: https://www.dropbox.com/s/fvt08kqx5bhnxqa/XposedInstaller_2.5-beta2%2BASUS.apk |
|
Installed and works, without help from adb, without disabling jit 👍 |
|
Ok, that's great! It won't be part of version 2.5 though as I still need to detect which offset to use (unfortunately, variable names etc. aren't available in the compiled library). Afterwards, I need to test it very carefully. As you saw, a wrong offset leads to bootloops and if the +0x98 offset is applied to any other ROMs, then it will crash there. |
|
That's ok, I and other MeMO Pad owners can live with an unoffcial version. |
|
Actually there were already bootloops with this phone on Android 4.2.2. That version also had the extended dvmChangeStatus() function, which is not part of Intel's source code. |
|
I haven't test it with Android 4.2.2. Others reported that it works with 4.2.2 and haven't updated to 4.3, they don't want to lose xposed ;) |
|
I have downgraded to version 4.2.2 (firmware 4.7.3) Both versions of xposed (2.5beta and the modified one for this tablet) are working. |
|
Could you send me the libdvm.so for this older ROM as well? Then I can check which offset it uses. It's possible that it uses offset 0x78, but writing 1 to 0x98 doesn't cause any visible/severe effects. Yet it would mean that the JIT cache isn't reset, so hooks may or may not be called, and that maybe 1 will have other effects that you just didn't notice yet. In any case, it's good if I can compare the libdvm.so's to find out how I can distinguish between them. |
|
You can find it at https://dl.dropboxusercontent.com/u/18073580/libdvm473-logs.tar.gz |
|
I wrote a thread in the german community and attached the modified version. I hope, this is OK for you. ( http://www.android-hilfe.de/root-custom-roms-modding-fuer-asus-memo-pad-fhd-10/549916-xposed-me302c-version.html#post7366980) |
|
Alles klar, danke! |
|
I checked the offset in the 4.7.3 file. It's 0x94, so neither version is good. It just doesn't seem to destroy anything. So I have to find a way to determine the offset dynamically... or if that is not possible, hardcode certain ROMs that have modified this structure. |
|
Area around the definition of the /* Compiled code cache */
void* codeCache;
/*
* This is used to store the base address of an in-flight compilation whose
* class object pointers have been calculated to populate literal pool.
* Once the compiler thread has changed its status to VM_WAIT, we cannot
* guarantee whether GC has happened before the code address has been
* installed to the JIT table. Because of that, this field can only
* been cleared/overwritten by the compiler thread if it is in the
* THREAD_RUNNING state or in a safe point.
*/
void *inflightBaseAddr;
/* Translation cache version (protected by compilerLock */
int cacheVersion;
/* Bytes used by the code templates */
unsigned int templateSize;
/* Bytes already used in the code cache */
unsigned int codeCacheByteUsed;
/* Number of installed compilations in the cache */
unsigned int numCompilations;
/* Flag to indicate that the code cache is full */
bool codeCacheFull;
/* Page size - 1 */
unsigned int pageSizeMask;
/* Lock to change the protection type of the code cache */
pthread_mutex_t codeCacheProtectionLock;
/* Number of times that the code cache has been reset */
int numCodeCacheReset;
|
|
|
|
I looked into the libdvm.so of the other firmwares with objdump. The really old one have a different dvmChangeStatus than in http://forum.xda-developers.com/showpost.php?p=46440353: I uploaded it to https://dl.dropboxusercontent.com/u/18073580/libdvm462.so (it's the same libdvm.so in three different firmware versions 4.5.7, 4.6.1, 4.6.2) |
|
You have just used different parameters, here is the same file dumped with Anyway, this function is no longer a problem because I don't use it anymore since some rewrite in version 2.4. The only pending thing now is getting the offset dynamically, then it should work. By the way, the offset in this file is also 0x94. |
|
they updated the source for kitkat baytrail maybe it can get fixed now.... https://github.com/android-ia |
|
Thanks! The reason for the crashes is already known, see my analysis above. I could even post a working test very. The difficulty is to find the correct offset at runtime, because unfortunately the field names are only known at compile time and they are mapped to offsets. If some vendors decide to introduce new fields, the offsets are no longer valid. So I need to find a heuristic to determine the offset which works on these devices AND all devices which don't have this issue. |
|
yeah sorry i read that after, i was just excited to finally see new source drop from android-ia, thanks. |
Some ROMs seem to be compiled with different settings or have been modified by the vendors, resulting in a different offset for the codeCacheFull flag than 0x78 = 120 as in AOSP. This can lead to boot loops: #6 Manual configuration is only a workaround, however it's better than compiling different variants. Automated detection would be best, however it's very complicated. Not only does it require intelligent algorithms to guess the offset from other, more significant fields, it would also have to be done at the right time. The structure in question isn't initialized in Zygote, and only after some delay when starting apps. The only thing we can do now is a quick sanity check. Booleans can only be 0 or 1, so if the current value is something else, then we were probably about to overwrite a pointer or something else.
|
My ME300C still goes to bootloop on a v58. Android version is 4.3. Build version is 5.0.21 |
Are you aware that support for these ROMs requires you to create a configuration file? Please see the FAQ on XDA for details. |
|
Yep. Adding |
|
That's actually a workaround for a different issue (I meant the one where you create a file called |
|
Can you post here a link to the method with |
http://forum.xda-developers.com/showpost.php?p=46440353
http://forum.xda-developers.com/showpost.php?p=51177359&postcount=9754
libdvm.so: http://forum.xda-developers.com/showpost.php?p=51192467&postcount=9775
The text was updated successfully, but these errors were encountered: