Skip to content

Tags: wskplho/XposedBridge

Tags

v82

Toggle v82's commit message

Verified

This tag was signed with the committer’s verified signature.
rovo89 Robert Vollmer

v81

Toggle v81's commit message
Add v81 API

v80

Toggle v80's commit message
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.

v79

Toggle v79's commit message
Fix creation of ResourcesKey objects on Marshmallow

The token parameter is gone, so we're back to the signature of SDK17 & 18.
CM13 will need two additional parameters though.

v78

Toggle v78's commit message
Fix creation of ResourcesKey objects on Marshmallow

The token parameter is gone, so we're back to the signature of SDK17 & 18.
CM13 will need two additional parameters though.

v71

Toggle v71's commit message
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.