This repository has been archived by the owner on Jun 1, 2023. It is now read-only.
SettingsProvider classes not found, results in boot loop #53
Labels
Comments
|
Thanks for the detailed report. One thing I noticed is that the system says that the odex file needs to be recompiled for Xposed, but there's no invocation of dex2oat afterwards. I'll have to have a closer look into this. |
|
I'm happy to provide more information or install test builds if you tell me what is needed. |
Closed
|
@xinluh Could you send me your /system/framework/arm/services.odex please? |
|
Here is /system/framework/arm/services.odex |
|
Could you test this please? https://www.dropbox.com/s/qahj2hed1e4rlez/xposed-v71-sdk21-arm-test2.zip?dl=0 |
rovo89
changed the title
|
I would love to test, but I need the arm64 build, I think (installer error: Wrong platform: arm64, expected arm). Here is the services.odex from /system/framework/arm64, in case you need it: |
|
Same here, unfortunately I need arm64 build as well. |
|
Here's the test build for arm64: https://www.dropbox.com/s/ilor9it1be7r6ec/xposed-v71-sdk21-arm64-test2.zip?dl=0 |
|
Still boot loops with the same error of SettingsProvider not found, and there is still no dex2oat call after DexFile_isDexOptNeeded for SettingsProvider (in fact, for quite a few other packages, too, not sure if that is the expected behavior). Here is the full log: I notice something funny with the build though. Initially a 32-bit binary is found: but later the build becomes 64 bit: |
|
Oh, I forgot that I had disabled flashing the XposedBridge.jar for my tests... Here are new builds: |
|
The phone boots! It is taking a long time to optimize apps, so I'll report back when everything loads up. EDIT: phone runs fine and the few modules I install also seem to work fine. |
|
I can confirm letv also boots with test3 version! |
|
Guys, i'm running LeTV x600 with version 4S. Rovo do you have an uninstaller for this v71 build? |
|
All right, i just checked the uninstaller in xda forum, seems version agnostic, so i'm going to try this build now! |
|
And it booted! First it optimized 170 apps, then 55, 35 and then 17(?!). Oh man... this would be so great if GravityBox worked on this! |
|
Gravity for Lollipop installed and seems to be working, i mean, at least it changed some battery text on the status bar! This is great. However doing a TWRP backup right now just in case some stuff goes nuts. Thanks Rovo! |
|
I modified your xposed.prop since I'm on 5.1.1, as I got the maxsdk error. Not surprisingly, it didn't boot on my G Stylo, not even past the T-Mobile splash screen that then goes to LiveBoot. Wiped cache and dalvik after the flash as well. I doubt you want the log since it's happening on 5.1 when this was built for 5.0, but I took one anyway. However, your changes might be good for romracer and his unofficial 5.1 builds, that might get Xposed working on many of the current LG devices, including the G4. Can I ask what you found out from all of our services.odex files and what you've changed in xposed? I love the technical details! |
|
The commit message contains many details. Feel free to ask if anything is still unclear. I asked for the services.odex files because I thought I had identified a possible cause, but then I realized it must be something else. |
|
@xinluh @leloch @sansanca or anyone else who is running a stock ROM on an affected LeTV or LG device: I recently made some changes which might affect your device. To ensure that Xposed still works, I'd like to have some testers. For those who want to test: https://www.dropbox.com/sh/gketc1pry8ovy33/AACEqJME6LijmlFzrRlkAnwja?dl=0 |
palmzeed
added a commit
to palmzeed/XposedBridge
that referenced
this issue
Jun 5, 2016
* Revert "Hard-limit log file size to 5 MB" This reverts commit afcc3e1. * v55: Prepare for modularization and ART In case no suitable libxposed_*.so was found or the initialization failed, the native methods are not registered, so make sure that this situation doesn't crash the system. Also retrieve the current runtime and use a different entry point for non-Zygote executions. Requires changes in the binary. * Move XposedBridge.jar to /system/framework With enforced SELinux, Zygote usually cannot read/execute files in /data/data. By locating XposedBridge.jar next to the system code, we can be pretty sure that access is always possible. This might also help to avoid issues where the system partition is wiped, but /data still holds an older version of XposedBridge.jar. * Adjustments for Lollipop code changes Some internal methods have changed, so hooks need to be adjusted. Also, the code for the system_server process is now stored in a separate file and accessed with a separate classloader (not the boot classloader), so the hook needs to be placed in two steps. * No longer write the log to file from Java code Due to SELinux, it's pretty much impossible to open file for writing in the Zygote process and keep writing to it from application and system processes. On 64-bit ROMs, it's even more complicated because there are two Zygote processes. Messages will still be written to logcat and are captured from there in native coding. * Differentiate between the two Zygote processes on 64-bit ROMs Only one of these processes starts the system_server process, so it only makes sense to place some hooks or trigger certain actions for this primary process. Modules can check this in initZygote() via a new flag in the parameters. Generally, it's strongly recommended to place any hooks for system_server in handleLoadPackage() for the "android" package instead. * Work around SELinux restrictions This commit introduces various classes and helpers to access files even when SELinux is active and enforcing. Depending on the process/context (Zygote, system_server, normal app), different approaches have to be used, most of them realized via native services. The intention is to abstract the very complex logic and the choice of the right service by providing a common interface for them. XSharedPreferences is adapted to handle this in the background, so modules loading their preferences via this class shouldn't need to be updated at all (provided they store the preferences world-readable, which has been a requirement already in most cases). Modules are free to use the SELinuxHelper class and the services retrieved from it to access files in /data/data/ themselves. The API is pretty much finished, although breaking changes are still possible until the first stable version of Xposed for Lollipop has been published. * v60 Let's skip some numbers due to the big changes. * v61: Keep loading Xposed even if modules.list doesn't exist Otherwise, the installer will show an error message to the user. Also, make sure that stack traces are logged with ERROR priority. * Use packageName "system" for system dialogues The actual package name from the activity info is "android". However, the same name is also used for the system_server. It has been a common pattern to check for this package name before hooking any system services. Now, this check would also be true for certain system dialogues and break existing modules (causing ClassNotFoundExceptions). For the very few cases where a module needs to hook into this process, it can simply check for package name "system" instead. * Make sure that only system_server uses the BinderService The android:ui process is running with the same UID, but in the system_app context, so it should be treated like a normal app. * Handle modified ResourcesKey constructor in CM12 The constructor has been changed in this commit: CyanogenMod/android_frameworks_base@ccb9dc1 * Use error messages from native code in BinderService * Adjust exception texts for ZygoteService to match BinderService * v62 * Hook getTopLevelThemedResources() CM11 has introduced this method with Change-Id If04e82a13250f520d70b58991586c8ce38f0ecb1. Especially on CM12+, the SystemUI (and possibly other parts of the system) use this method to retrieve a Resources object. We need to hook it and replace the result with an XResources object. * Introduce a counter for method depth This can be useful to determine at which depth we are in recursive/similar methods and perform certain actions only for e.g. the outer call. * Use a different approach for API stubs Instead of using a file retrieved from a compiled AOSP tree, just use stubs of those classes and methods that are actually needed by Xposed. This allows to add ROM-specific and version-specific methods. * Override getDrawable() variantes with Theme These methods have been introduced in Android 5.0 and need to be overridden in order to ensure proper resource replacement. * Look for Drawable replacements just once There might be recursive calls, but it's enough to check for replacements in the first call. * Fix call to parsePackageLite() for Android 5.0+ The method signature has changed, taking a File instead of a String as the first argument. Both signatures are present in the HiddenAPIStubs.jar, so no reflection is required. Fixes #34. * v63 * Use SELinux services even in permissive mode. This should fix some cases when a ROM is set to enforcing later. The native daemons are running anyway whenever SELinux is detected. See #33. * Use API stubs instead of reflection in SELinuxHelper * v64 * Get rid of the version number See the native part for details. * Don't hook resources in the Sygic process They have implemented low-level resource class replacements themselves, which conflict with Xposed's. Fixes rovo89/Xposed#54. * 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. * [Xposed] mParseState is a long in >Android 5.0 https://android.googlesource.com/platform/frameworks/base.git/+/896043d67d3ac75760bd99db8a1561e31ebee1e1%5E%21/#F3 * Adjustments for Android 6.0 / Marshmallow For now, this limits the changes done in 01c324 to Android 5.x. The PackageManagerService methods have changed since then and it's unclear whether this workaround is still needed for 6.0. * Cleanup of ART-specific code There's no need to determine parameter and return types for ART as they're ignored by invokeOriginalMethodNative() anyway. * 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. * Move to Gradle/Android Studio * Make gradlew executable * Fix linting error Parcelable implementations must define a CREATOR or lint complains and aborts the build of the `hiddenapistubs` project. * Bump Gradle version to 2.10 * Add hiddenapistubs to app.iml This hack is required to make the additonal/modified classes known in Android Studio and give them more priority than the Android SDK. After hours of debugging, this seems to be the only way to fix it. * Reorganize imports with Android Studio defaults * Fix/suppress some Lint warnings and inspections * 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. * Rename stubs to hiddenapi in build.gradle * Cosmetics: Remove unnecessary semicolons in build.gradle * Generate Javadoc and API stubs The Javadoc is pretty basic for now and will be improved later. The API stubs are packed into jar file for modules to reference, and another jar file is created for the source code. The Doclava and JSilver jars have been compiled from the current AOSP master branch (bb5631fc) with a few patches and after reverting commit d865937f (default/static interface methods support). The Android API txt is taken from AOSP prebuilts/sdk/api. * Add Doclava template from SDK/AOSP This is taken from build/tools/droiddoc/templates-sdk on the master branch: https://android.googlesource.com/platform/build/+/8f7d4b747434da86ebcb9d6174beda6a4008dcea/tools/droiddoc/templates-sdk/ * Customize Doclava template for Xposed * Hide internal classes and methods from the API * Also hide overridden Android SDK methods There's not much value of having methods like XResources.getDrawable() in the Javadoc. Let's concentrate on the added methods instead, which are more visible now. * Add API history files Previous API levels have been reconstructed from the Git history. Internal classes/methods that should have never been used by any module (and which were therefore hidden later) were removed. * Add getCallback() to IXUnhook All classes implementing this interface already had this method. * Make XC_* implement IXposedHook* XC_LoadPackage and XC_InitPackageResources already had the same abstract method that the corresponding interface defines, so there is no effective change. * Add Javadoc for everything except XposedHelpers and XResources * Add Javadoc for XResources * Add Javadoc for XposedHelpers * Add Javadoc for packages * Add introduction to the API reference * Clean up unhooking methods Modules should always use the IXUnhook instances that are returned from the hooking methods. Also hooking LoadPackage and InitPackageResources should be done using the interfaces for the method class, not with stand-alone classes. This will need further cleanup in the future. Remove/hide unused methods, deprecate unhookMethod() to give the very few modules using it a chance to switch. * Deprecate some resource hooking variants Less is more, having just two instead of three variants makes the docs easier to read. There's another variant which can be used without logic changes. The methods are deprecated now and will be removed completely in the future. * Remove IXposedHookCmdInit from the API * Add v81 API * Add find{Class,Method,Constructor,Field}IfExists() helpers They make it easier to place hooks conditionally. * Force recompilation on Huawei devices They have added several checks that disable the recompiliation of pre-optimized APKs. This must be undone when Xposed is active. Fixes rovo89/Xposed#72. * Simplify isThemeable checks using the new APIs * Add v82 API * Don't force apps to compile during the boot process This change reverts the following commits: 01c3244 f5967d5 They have become obsolete by a change in Xposed's ART libraries which allows the system to use the dex from .odex files in interpret-only mode (i.e. the compiled code is ignored). This works out-of-the-box on stock ROMs where the image checksums match (because the image hasn't been recompiled) and no Xposed version check prevents the usage of the .odex file. * Warn developers when Xposed API classes have been compiled into the APK Just a warning for now, even though this can cause strange behavior. However, quite a lot of modules are compiled incorrectly and I want to give the developers time to react. * Address some Lint warnings * Remove unnecessary condition The whole code block is only executed for SDK21+, no need to check it again. * Bump various tools versions Gradle wrapper: 2.10 -> 2.13 Android Gradle Plugin: 1.5.0 -> 2.1.0 Android Build Tools: 23.0.2 -> 23.0.3 * Warn developers when Instant Run is enabled in Android Studio Instant Run replaces the application with a bootstrap application that can communicate with Android Studio and dynamically exchange methods In order to achieve this, actual classes are not stored directly in the APK's classes.dex, but within a file called instant-run.zip in the APK. Therefore, these classes can't be found by Xposed unless it would simulate the same bootstrapping that takes place when the app is started. Let's avoid the misleading ClassNotFoundException and instead print a proper error message asking the user to disable Instant Run.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For device:
There seems to be something wrong with permission:
So eventually boot failed since essential services cannot find SettingsProvider:
e.g.
How to fix this?
Full logcat: http://paste.ubuntu.com/11938673/
The text was updated successfully, but these errors were encountered: