Tags: wskplho/XposedBridge
Tags
Ensure dexopt on Marshmallow This is a follow-up on 01c3244. The same issues occur also on Marshmallow. It seems that they usually don't show up because adjustCpuAbisForSharedUserLPw already compiles the providers. Especially LG's providers don't seem to be processed there and therefore cause bootloops. Fixes rovo89/Xposed#100.
[Xposed] mParseState is a long in >Android 5.0 https://android.googlesource.com/platform/frameworks/base.git/+/896043d67d3ac75760bd99db8a1561e31ebee1e1%5E%21/#F3
[Xposed] mParseState is a long in >Android 5.0 https://android.googlesource.com/platform/frameworks/base.git/+/896043d67d3ac75760bd99db8a1561e31ebee1e1%5E%21/#F3
[Xposed] mParseState is a long in >Android 5.0 https://android.googlesource.com/platform/frameworks/base.git/+/896043d67d3ac75760bd99db8a1561e31ebee1e1%5E%21/#F3
[Xposed] mParseState is a long in >Android 5.0 https://android.googlesource.com/platform/frameworks/base.git/+/896043d67d3ac75760bd99db8a1561e31ebee1e1%5E%21/#F3
Ensure that apps used during the boot process are compiled Android has (at least) five points in time where apps are compiled: 1) Quite early when the PackageManagerService is started. 2) Once the UI comes up ("Android is upgrading" screen). 3) In a background service called "BackgroundDexOptService". 4) When an app is installed. 5) When the app is actually started. Phase 1) is used for /system/framework and other non-app "libraries". At this time, the system also scans the app directories and identifies apps that need to be (re-)compiled. These apps are then handled in phase 2). After that, all apps are usually compiled, with the exception of builds with type "eng", where only recently used apps are compiled immediately and the remaining ones are compiled in phases 3) or 5). Phase 5) is usually not needed because the app has been compiled in one of the previous phases. Unfortunately, there is at least one category of apps that is needed early during the boot process, the System Content Providers. They're loaded between phase 1) and 2), but aren't compiled at that time yet, which leads to errors. Actually that's not completely true: On most ROMs, side-effects of other early package processing seem to compile them. But even if not, phase 5) kicks in and should compile the app. However, that doesn't work correctly. The phase assumes that it's only needed for "eng" builds, when not all apps have been compiled in phase 2). It quits early if it doesn't detect such a situation. This patch hooks into the methods that triggers the compilation of the app and pretends that the call came from phase 3) if it detects that phase 2) hasn't run yet. This ensures that the System Content Providers are compiled shortly before they're required. Not sure why this doesn't seem to occur without Xposed - maybe the circumstances are slightly different. Fixes rovo89/Xposed#53.
PreviousNext