Bootloop devices with framework/*.jar files android 9.x

[ale8530]

Hello @anestisb , with the new vdexextractor 0.51 for android 9.x I found a bootloop of the device, I would like to understand if this problem can be caused by a problem of conversion from cdex.

Partial error:-->https://pastebin.com/rDXuzSZ7

Logcat complete-->https://drive.google.com/open?id=14aYKhuW2pJrxGI0v6TO-a2rrqAgJzRWY

Files framework-->https://drive.google.com/open?id=102DLsG1OLd4Dz2cVicaD_MsJ5neoBqYY

Is it possible to check if it is a conversion problem?

Thanks for help

[ale8530]

anestibs to help I can confirm that the problem is caused by files framework/boot-*.vdex

[anestisb]

It seems that Android 9 is also modifying some field/method access flags as part of the optimization process. Therefore I need to implement the UnHideAccessFlags() methods to revert back to the original flags. Issue does not appear to affect the apps since runtime enforces relaxed verification, which is not the case though for the framework jars.

Will pick it up asap. Thanks for reporting.

[anestisb]

Btw the compact_dex_converter binary has an optional -v flag which can be used to verify the StandardDex file after conversion. This might be helpful to early catch any issues before repacking into ROMs.

[ale8530]

Log error convertion .cdex to cdex.new.-->Log_vdex.zip

[anestisb]

@ale8530 commit https://github.com/anestisb/vdexExtractor/commit/6f69698ba310599dfbf7f7253773956d2c2f99cd should fix your issue. Can you please pull latest from master and try again?

[ingbrzy]

can not compile binary after latest commit 6f69698ba310599dfbf7f7253773956d2c2f99cd

./make.sh make: Entering directory/home/roms/miui_v5/roms/vdexExtractor/src' rm -f .o rm -f /*.o rm -f vdexExtractor make: Leaving directory /home/roms/miui_v5/roms/vdexExtractor/src' make: Entering directory/home/roms/miui_v5/roms/vdexExtractor/src' gcc -c -std=c11 -D_GNU_SOURCE -Wall -Wextra -Werror -c dex.c -o dex.o In file included from dex.h:29:0, from dex.c:23: dex_modifiers.h:118:5: error: initializer element is not constant kAccCompileDontBother | kAccDefaultConflict | kAccPreviouslyWarm; ^ dex_modifiers.h:123:39: error: initializer element is not constant kAccEnum; ^ dex_modifiers.h:129:40: error: initializer element is not constant kAccConstructor | kAccDeclaredSynchronized; ^ dex_modifiers.h:135:5: error: initializer element is not constant kAccPublic | kAccFinal | kAccSuper | kAccAbstract | kAccSynthetic | kAccEnum; ^ dex_modifiers.h:142:5: error: initializer element is not constant kAccPublic | kAccInterface | kAccAbstract | kAccSynthetic | kAccAnnotation; ^ dex_modifiers.h:144:1: error: initializer element is not constant static const u4 kAccVisibilityFlags = kAccPublic | kAccPrivate | kAccProtected; ^ make: *** [dex.o] Error 1 make: Leaving directory /home/roms/miui_v5/roms/vdexExtractor/src' [-] build failed

[anestisb]

@ingbrzy should be fixed in https://github.com/anestisb/vdexExtractor/commit/480c8d153829d714a971103d90e741d6882ca4b9

[ingbrzy]

@anestisb confirmed.. binary built and no more flags issue.. good job! Thank you

[ale8530]

Ok no error with compact_dex_converter, but test new now

I'll let you know if I have bootloop

[ale8530]

Rom no booted i have this message when launch command:

Compact _cdex_converter -v *. cdex

Output message:

Ignoring bad checksum

This can cause startup problem?

[anestisb]

@ale8530 the bad checksum warning is generated from an intermediate Dex file that is generated before the actual checksum is repaired. It's safe to ignore (thus the "Ignoring" in the message). It must be something else (not necessarily related to deodexing) that is causing the issue.

[ale8530]

anestibs i have fixed no problem your tool

Thanks for your support

[russel5]

@anestisb about ignoring bad checksum. Is your dex converter fix it or not? If i'm using your dexrepair tool it fix all cdex.new files. Why i'm asked in this closed issue, because i'm don't understand why after each reboot phone always recreate dalvik cache. That's why i'm asked it here, because only one thing left, it's bad checksum in dex files or may be not. How do you think why this happend?

[anestisb]

@russel5 the cdex converter uses libdexlayout which is configured to repair the checksum of the output Dex file. You shouldn't need to repair anything generated from the converter. You can verify that the output Dex files are OK by running them against dexdump.

There must be another reason that results the ART ignoring the cache when loading the runtime (or some apps). For most type of errors ART prints the reason that it invalidates the cache in logcat. I think you should research the root cause there.