-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not work when trying to access via Xposed on an app targeting Android 11 #22
Comments
Hmm... I don't think this is fixable at the library level. As you mentioned, one bypass would be to hook whatever in the system performs this validation and allow the access through, but that feels really hacky (and frankly goes against the spirit of RemotePreferences in the first place, i.e. using only standard Android APIs). My preferred approach would be for Xposed (or whatever Xposed-compatible framework people use these days) to merge permissions of the module into any hooked apps, as if they were defined in the manifest. I don't know how technically feasible that is though. Short of that, there would need to be some kind of globally accessible service that can proxy requests between the hooked app and module app. I think that's the path some newer frameworks like LSPosed use to implement their version of XSharedPreferences. If one were to go down that path, might as well just depend on XSharedPreferences instead. So yeah, tough spot to be in. Permissions in Xposed are fundamentally broken today, I don't know how to fix this :-( |
LSposed and EdXposed both implement a self-hook for module apps that redirects the shared prefs to /data/misc/<xposed dir>/<pname>/ which is then set as global readable. It's working for what I need thankfully, but is I think the only remaining hack that will work on Android 11. Shame this method won't work any more, but I fully understand your reasoning and support not wanting to mess with system permissions to get around it. There's also a proposal of a new "Xposed Service" that might resolve this, where modules could bind to a service. |
Recently I found this undocumented property Edit: It doesn't seem to work if you install the apk via normal means, only if you have a shell on your device/ADB and run |
I've found a solution for this problem, I'm bridging through the gap with Intents. If you now think "wow, that does sound hacky" then that is because, yeah, it is. But as far as I can see it is the only solution which will readily work on any version, and will most likely keep working for the foreseeable future. @apsun Would you be interested in having this as a second option in RemotePreferences? I'd like to type up a MR for this. The basic idea is that we use Intents to bridge the gap between the apps. That comes with a few gotchas you need to be aware of. for simplicity I'll talk in terms of XPosed (so "App" to denote the standalone app of the module, and "Module" to denote the part that is being injected into the target app):
All of these are manageable. In my current prototype I'm using two |
However, an accidental feature is that other apps can also easily control the module through these preferences, as they only need to send the correct Intent. I consider that a feature (as Tasker or Automate can be used to change the preferences based on custom conditions), but your mileage might vary. |
@RobertZenz interesting, although I'm not sure how much that would have in common with RemotePreferences (the vast majority of code in this library is just to adapt SharedPreferences to the ContentProvider API). I think it would be better suited to a new library rather than trying to shoehorn it into RemotePreferences :-) |
Well, it would still be remote, but instead of a Content Provider as mechanism, it would be an Intent Receiver. I can (and did) implement |
To be clear, I was thinking of simply having both mechanism available side by side. So that you Using the Content Provider API still makes sense if one has control over the app manifest of the receiving application, but the Intent Bridge would be the alternative if one does not. |
I've created a Pull Request with my solution, whether you want to use it or not is up to you, it's completely okay if not. Maybe someone else will pick it up in that case. Consider the source under MIT, of course. |
So you mean like if hooking some value in target app by remotepreference and if target app target sdk is 11 then value will not hook? |
It will hook fine but you won't be able to get remote preferences from your module, it will fail to load the provider with that error. |
Thanks to inform this issue after reading your issue i recently test same thing coz i also add remotepreference instead of new Xshared and in my test i found if target app target sdk 11 then its giving SecurityException :Failed to find provider pkg name for user 0; expected to find a valid ContentProvider for this authority i got this error in logs and whenever i try old version of that app which have target version 10 then its not giving any error so i m little bit confuse so what mean of this error target app can't read preference value by remotepreference? |
Yes, the app you are hooking can't read the preferences as it's getting blocked by the system. You must use XSharedPreferences in a modern Xposed implementation like LSposed. |
What about if target sdk version 12? Then it will work? |
I checked myself its work in android 12 this issue present in android 11. |
I don't understand this issue carefully. Doesn't this library work on android 11 phones? |
As title, the library doesn't work when the app Xposed is injecting into targets Android 11, due to App Visibility changes.
Logcat shows this error:
E ActivityThread: Failed to find provider info for com.kieronquinn.app.darq.provider.remoteprefs
It works perfectly fine with apps not targeting 11. Examples I can reproduce on are LinkedIn (targets 11) and Snapchat (targets 10)
From research, this can be resolved by adding a
<provider>
to the<queries>
tag in the target app's manifest, but obviously we don't have access to that so it can't be done. Might have to be done on boot by injecting into the server.The text was updated successfully, but these errors were encountered: