Related
This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.
This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).
Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.
Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.
IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.
2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.
In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.
I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse
For my Xposed Module Play Store Chagenlog an update was released yesterday, this added a GUI as wel as some options. There have been quite a few reports about settings preferences not being applied. After some debugging, I found out that this XSharedPreferences simply doesn't have any entries and thus always returns the default values. I'm 100% sure the options are set (the preferences screen shows them correct and you can see them in the .xml) and the right file is being loaded. There are no errors in the Xposed Log or in the logcat.
I've found a workaround (only tested by me), unchecking and re-checking an option and then the preferences are read correctly. All my modules (actually most of all Xposed Modules) use this way to load an user's preferences, I have absolutely no clue what's causing this behaviour.
The source code is on GitHub, links to relevant files:
PlayStoreChangelog.java
SettingsActivity.java
SettingsFragment.java
settings.xml
For debugging purposes, I've added a snippet to dump the preferences beneath initializing XSharedPreferences. This says it loads the right file, the file exists but it contains no entries (size 0). So when trying to get values (getString, getBoolean etc), it only returns the default values.
Java:
sharedPreferences = new XSharedPreferences(BuildConfig.APPLICATION_ID);
XposedBridge.log(LOG_TAG + sharedPreferences.getFile().getAbsolutePath() + " exists: " + sharedPreferences.getFile().exists());
XposedBridge.log(LOG_TAG + " ---PREFS: " + sharedPreferences.getAll().size() + "---");
Map<String, ?> sortedKeys = new TreeMap<String, Object>(sharedPreferences.getAll());
for (Map.Entry<String, ?> entry : sortedKeys.entrySet()) {
XposedBridge.log(LOG_TAG + entry.getKey() + "=" + entry.getValue().toString());
}
Summary
The app uses a PreferenceFragment to set the preferences and XSharedPreferences to load them. The changes are written to the .xml file and shown in the GUI. The XSharedPreferences instance remains empty and does not contain any entries, thus it always returns the default value. I don't get why it doesn't work, I don't even get why the 'workaround' does work.
I'd really appreciate any help, I'm stuck on this one. No idea what causes it and whether it's a but in my code or something else.
I hope I gave enough information. Thanks in advance.
I'm really stuck on this one, I haven't got a clue what causes this. Maybe @rovo89, @MohammadAG, @GermainZ or @defim, you guys are the most experienced Xposed developers out here. Thanks in advance!
Could something like `sharedPreferences.makeWorldReadable();` (probably needs to be in initZygote) solve your issue? I can't personally think of any reason this might happen except a permission issue.
(Also make sure you're using the latest Xposed Bridge API. I remember there were some commits related to XSharedPreferences, although I can't remember what they were exactly and can't check right now.)
Permission problem sounds reasonable. PSC has for its xml file only set 660, so world readable is mission. After changing it by command line Play Store starts as expected. But i've to say that i use in no app the makeWorldReadable(), Xposed should do it by itself: http://forum.xda-developers.com/showpost.php?p=41976845&postcount=1586 But I also dont use settings fragment, which could cause it...
GermainZ said:
Could something like `sharedPreferences.makeWorldReadable();` (probably needs to be in initZygote) solve your issue? I can't personally think of any reason this might happen except a permission issue.
(Also make sure you're using the latest Xposed Bridge API. I remember there were some commits related to XSharedPreferences, although I can't remember what they were exactly and can't check right now.)
Click to expand...
Click to collapse
defim said:
Permission problem sounds reasonable. PSC has for its xml file only set 660, so world readable is mission. After changing it by command line Play Store starts as expected. But i've to say that i use in no app the makeWorldReadable(), Xposed should do it by itself: http://forum.xda-developers.com/showpost.php?p=41976845&postcount=1586 But I also dont use settings fragment, which could cause it...
Click to expand...
Click to collapse
First of al, both thanks you for your response, it's highly appreciated.
I've been testing with permissions, it indeed looks like a permission problem, because makeWorldReadable() solved it. I use the following line the SettingsFragment to make it World Readable, which has always worked, even though Context.MODE_WORLD_READABLE is officially deprecated because if security reasons:
Java:
getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE);
It creates a file with 660 permissions, with makeWorldReadable in initZygote it sets it to 664. This is my initZygote:
Java:
@Override
public void initZygote(StartupParam startupParam) throws Throwable {
sharedPreferences = new XSharedPreferences(BuildConfig.APPLICATION_ID);
XposedBridge.log(LOG_TAG + "Readable before: " + sharedPreferences.getFile().canRead());
sharedPreferences.makeWorldReadable();
XposedBridge.log(LOG_TAG + "Readable after: " + sharedPreferences.getFile().canRead());
}
The weird thing is, both readable before and after return true, which indicates it has the permission to read the file before makeWorldReadable(). But... it doesn't work without it
In the end, I created a snippet in SettingsFragment to solve it where the problem arises, instead of makeWorldReadable():
Code:
File sharedPrefsDir = new File(getActivity().getFilesDir(), "../shared_prefs");
File sharedPrefsFile = new File(sharedPrefsDir, getPreferenceManager().getSharedPreferencesName() + ".xml");
if (sharedPrefsFile.exists()) {
sharedPrefsFile.setReadable(true, false);
}
This still needs setSharedPreferencesMode(Context.MODE_WORLD_READABLE), otherwise the permissions will be reset to 660 when a preference changes, now they stay 664. So basically al it does it make it readable for others in addition to the setSharedPreferenceMode().
Thanks again for your replies, it really helped. I still think it's weird, especially since File.canRead() returns true, while it obviously can't read it. I hope it'll help others in the future.
I think I use the deprecated SettingsActivity for this reason. I can override getSharedPreferences so it always returns a world readable file, this avoids the permissions resetting when a preference changes.
Sent from my HTC One_M8 using Tapatalk
MohammadAG said:
I think I use the deprecated SettingsActivity for this reason. I can override getSharedPreferences so it always returns a world readable file, this avoids the permissions resetting when a preference changes.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Thanks for your response, just checked out one of your modules, saw you were using getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE); too. (and indeed SettingsActivity). This has always been sufficient for me using PreferenceFragment. To be sure it's world readable I now manually set the permissions on onPause as a workaround. Still weird because it has always worked flawless for me.
P1nGu1n_ said:
Thanks for your response, just checked out one of your modules, saw you were using getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE); too. (and indeed SettingsActivity). This has always been sufficient for me using PreferenceFragment. To be sure it's world readable I now manually set the permissions on onPause as a workaround. Still weird because it has always worked flawless for me.
Click to expand...
Click to collapse
Yeah, I also override getSharedPreferences in PreferenceActivity, that allows it to stay world readable.
Sent from my HTC One_M8 using Tapatalk
Sam code works for me in XInstaller. Try check it out, it is open source.
Be aware that using XSharedPreferences will probably lead to problems on Lollipop caused by more stringent SELinux rules.
M66B said:
Be aware that using XSharedPreferences will probably lead to problems on Lollipop caused by more stringent SELinux rules.
Click to expand...
Click to collapse
Good point, but it's too early to say. I'll wait for Xposed to be compatible (hope it will), than I'll look into what changes it'll require. That's something almost every Xposed developer will face ;p
Sent from my phone, please forgive any tpyos.
Yes, I think also Xposed should then handle with LOL XResources properly
Breaking XSharedPreferences means that *almost* every module is not going to work on Lollipop.
I also migrated my project to use PreferenceFragment and getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE) pretty much does nothing. After I change any setting, prefs file lose "world available" mode.
I checked out P1ngu1n_'s implementation using PreferenceFragment, but it still doesn't work for me. Do any of you have an idea why?
Here is my source
The only difference I can see is that I don't have an xml file for the preferences and that I'm adding the keys in the fragment.
I even checked the permissions and they seem to be fine.
asdfasdfvful said:
I checked out P1ngu1n_'s implementation using PreferenceFragment, but it still doesn't work for me. Do any of you have an idea why?
Here is my source
The only difference I can see is that I don't have an xml file for the preferences and that I'm adding the keys in the fragment.
I even checked the permissions and they seem to be fine.
Click to expand...
Click to collapse
If the permissions seem to be fine, than what doesn't work?
P1nGu1n_ said:
If the permissions seem to be fine, than what doesn't work?
Click to expand...
Click to collapse
That's what confuses me. I have the xml file under shared_prefs and it definitely has values. However, xposed won't read it unless I open the app itself.
Sent from my Nexus 5 using Tapatalk
the problem is, i use OP5T, and none of any 8.0/8.1 stock custom rom does support 18:9 scaling feature like in OOS, this feature named as "Full Screen Apps" under app category.
after a few googling, i came up with these method:
1.) add/inject/force this into manifest file of every installed app. or maybe doing some workaround with the packagemanager
<meta-data android:name="android.max_aspect" android:value="2.1" />
Click to expand...
Click to collapse
2.) playing inside AOSP source code, parsePackage method.
frameworks/base/core/java/android/content/pm/PackageParser.java.
Click to expand...
Click to collapse
i know nothing of creating xposed module, but before starting my journey, is it possible to do the first method with xposed?
after seeing module like Xinstaller, App Settings, and XAspect. i thought it may be possible with xposed to approach this.
really appreciate every kind of help, thanks before
I can see at least two solutions there.
The first one, probably the most simple.
1)
Hook parseMetaData method to add
android.max_aspect to returned bundle in after hook (if doesn't already exist)
2)
Hook setMaxAspectRatio
Get mAppMetaData of passed Package (owner.mAppMetaData) in before hook and add android.max_aspect to it (if doesn't already exist)
Edit: Apart from <meta-data> app dev can also specify aspect ratio within <Activity> element in the manifest.
This has higher priority over <meta-data> so the best solution would be to hook setMaxAspectRatio of Activity class and modify maxAspectRatio parameter to desired value in before hook.
Inspired by the recent post on the headlines describing how to enable Android Messages For Web by fiddling with some settings, I took and consolidated what I learned there, plus some other testing, into a handy-dandy Magisk Module that *should* work to enable MFW.
*HOWEVER*, I'm doing something wrong, and need a bit of help.
Repo is here:
https://github.com/d8ahazard/Magisk_Messages_For_Web
Basically, I'm just copying the sqlite binary to system, and then firing the commands to update some bools in a preference DB, then force-closing the messaging app so they take effect.
But for some reason, the script doesn't appear to be running. I'm trying to fire it in the services section. I can see that the bit where I'm setting permissions on sqlite3 is working, but I don't know why the sql commands aren't being executed.
Is there some way to output directly to the Magisk log from a module/script? I think if I can see what's happening there, I'd be set.
If I execute the service script manually in shell, it works:
Code:
marlin:/magisk/AMW # ./service.sh
Enabling Android Messages for Web (Hopefully)
Executing command '"UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%messaging%' AND name LIKE '%PhenotypeOverrideRollout%'"'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%messaging%' AND name LIKE '%bugle_phenotype__enable_multi_device%';'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%com.google.android.apps.messaging%' AND name LIKE '%MultiQueueRollout__launched__%';'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%com.google.android.apps.messaging%' AND name LIKE '%MultiDeviceRollout__launched__%';'
Command status is 0
Records updated successfully!
Restarting messaging app
I know I'm close...I just don't know what's missing!
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
julienbdx said:
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
Click to expand...
Click to collapse
Yeah, that is literally just adding one more line to my script, and would more than likely make the material redesign permanent.
At least, modifying the settings needed for MFW in db versus the phenotype.xml preferent makes MFW permanent. I'd assume the issue described in the theme thread is the exact same thing.
All I need is for someone to explain to me why the damned services.sh script isn't executing. I've even tried putting the commands in post-fs script instead...same thing. I add a line at the very end to 'touch /sdcard/hasMFW' so I know the script ran, but no 'hasMFW' file every shows up in /sdcard.
Someone...anybody...help?
@topjohnwu
julienbdx said:
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
Click to expand...
Click to collapse
There, I've pushed to git a version that has the commands that *should* enable material design as well.
Also, tried moving to post-fs.sh, still nothing works...
https://github.com/d8ahazard/Magisk_Messages_For_Web/commit/10319c338943d8b77b8c8523f31cc276bc4e5d23
Just FYI,
Modifying the flags table in PhenoType.db under GMS isn't permanent either (certainly better than a Shared_Prefs edit). It gets reset still. We're still trying to understand what causes it to reset.
MishaalRahman said:
Just FYI,
Modifying the flags table in PhenoType.db under GMS isn't permanent either (certainly better than a Shared_Prefs edit). It gets reset still. We're still trying to understand what causes it to reset.
Click to expand...
Click to collapse
That's good to know.
Ideally, if this would fire properly as a service, functionality would then be restored on reboot.
However, from what I'm seeing in my tests on my Pixel XL, with the values set the way I've done - I've not seen any breakage in functionality - even over numerous reboots.
digitalhigh said:
That's good to know.
Ideally, if this would fire properly as a service, functionality would then be restored on reboot.
However, from what I'm seeing in my tests on my Pixel XL, with the values set the way I've done - I've not seen any breakage in functionality - even over numerous reboots.
Click to expand...
Click to collapse
Yes, we've tested it too. It'll survive multiple reboots and FCs but eventually it reverts. We've narrowed it down to a service in GMS that checks every 24 hours.
MishaalRahman said:
Yes, we've tested it too. It'll survive multiple reboots and FCs but eventually it reverts. We've narrowed it down to a service in GMS that checks every 24 hours.
Click to expand...
Click to collapse
Interesting. What's the service name called? I've been poking around in the APK itself...
What I'm noticing is that my wife and a friend of mine both have Pixel 2 devices, and they "just have" the feature...which isn't all that surprising.
So, I'm wondering if the service is checking device props and enabling the feature that way. If so, then Magisk would again be an ideal candidate for fixing that issue.
LMK the service name, I'm no stranger to reversing smali.
Have decided to rejoin XDA after a while off to see what sort of response I get to this.
A browse of the forum tells me that there is no known way to unlock fastboot, I was wondering what methods had been explored in an attempt to do this?
More specifically there are 2 potential methods I'd like to ask about.
1: I have seen mentioned in a comment here a tool I stumbled across a few months ago while messing around with another device,
edl/README.md at master · bkerler/edl
Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :) - edl/README.md at master · bkerler/edl
github.com
There is one option in particular that I think is of interest,
edl modules oemunlock enable -> Unlocks OEM if partition "config" exists, fastboot oem unlock is still needed afterwards
2: After a quick browse of the disassembled Oppo deeptesting app I can see a number of references to a class that is only accessible via reflection 'android.engineer.OplusEngineerManager'
and it contains a method 'fastbootUnlock'. Has anyone tried to access this class and its methods at all?
Maybe none of these things will be of any use, but before I spend too much time exploring them, I was interested to hear if anyone else had explored these at all? If so what progress was or wasn't made?
A little update for anyone who is interested:
So I have spent a little bit of time this morning seeing what I can do with the 'OplusEngineerManager' class. I made very simple app to see what access I could get to this class. After adding a library to allow the use of reflection to access non sdk classes I was able to get a list methods from the class, but so far have not been successfully invoke any of them, despite there being no exceptions caught.
User154 said:
A little update for anyone who is interested:
So I have spent a little bit of time this morning seeing what I can do with the 'OplusEngineerManager' class. I made very simple app to see what access I could get to this class. After adding a library to allow the use of reflection to access non sdk classes I was able to get a list methods from the class, but so far have not been successfully invoke any of them, despite there being no exceptions caught.
Click to expand...
Click to collapse
I took a look at the fastbootUnlock method itself (at /system/framework/oplus-framework.jar) and I believe that even if we could invoke it, it wouldn't work because it uses some sort of token (generated be Oppo?). I might be wrong though, I don't have much experience working with decompiled code, and the code I looked at was Realme one (I guess its same as Oppo).
daniml3 said:
I took a look at the fastbootUnlock method itself (at /system/framework/oplus-framework.jar) and I believe that even if we could invoke it, it wouldn't work because it uses some sort of token (generated be Oppo?). I might be wrong though, I don't have much experience working with decompiled code, and the code I looked at was Realme one (I guess its same as Oppo).
Click to expand...
Click to collapse
Its great that someone else is looking at this! I hadn't posted another update as I haven't made a huge amount of progress, and I wasn't sure anybody would be interested.
The fastbootUnlock method returns a boolean and takes 2 parameters, a byte array and an int. From what I can see it is the only method of the OplusEngineerManager class that the deeptesting app calls. It contains 2 calls to the fastbootUnlock method. Once where it calls it with an empty byte array and the int is 1. I was actually able to invoke the method from my test app in this way and got a false return value (rather than just getting null like the other methods I tried to invoke). The second is contained within a method of the deeptesting app that takes a string as its parameter. It then converts this string to a byte array which it passes as the paramter for the fastbootUnlock method along with the int of 1.
Edit:
The second call to fastbootUnlock uses the length of the byte array as the int and not 1. Please forgive me it was late when I wrote this and I was not looking at the source.
Thats about as far as I am with it at the moment, the next task is to find out what that string it passes is exactly, and is it something that needs to be generated by Oppo.
I would imagine the realme framework woukd be similar, if you would like to compare I can provide the full list of methods from the OplusEngineerManager class?
Hey guys, I would be interested in helping you somehow.
I have no prior experience with unlocking a device. (besides actually doing it with the tools provided by anyone else).
But I own an oppo find x3 pro, if you need me to do some testing for you, let me know
Thank you for your reaserch and trying to unlock the fastboot!
xarf903 said:
Hey guys, I would be interested in helping you somehow.
I have no prior experience with unlocking a device. (besides actually doing it with the tools provided by anyone else).
But I own an oppo find x3 pro, if you need me to do some testing for you, let me know
Thank you for your reaserch and trying to unlock the fastboot!
Click to expand...
Click to collapse
Hi, thanks for your reply. At the moment there isn't too nuch to test, but if I do manage to find a way I will need plenty of testers, so thank you
A small update:
I have found that the method in the deep testing app which takes a string and then ends up invoking the reflected fastbootUnlock method is called by a handler associated with one of the app's activities.
The handler gets the string extra from the intent which starts the activity, and then passes that as the parameter when calling the method.
The next problem is that I cannot find anywhere in the deep testing app that starts this activity. I can see as part of, what I believe to be, the normal flow of the deep testing app that an activity in the startup wizard is called, so I wonder if the startup wizard then starts the activity of interest in the deep testing app. This will be the next thing I look into
Edit:
I have looked into this more and it turns out most of this is wrong. The activity is started from within the deeptesting app and not the startup wizard
User154 said:
A small update:
I have found that the method in the deep testing app which takes a string and then ends up invoking the reflected fastbootUnlock method is called by a handler associated with one of the app's activities.
The handler gets the string extra from the intent which starts the activity, and then passes that as the parameter when calling the method.
The next problem is that I cannot find anywhere in the deep testing app that starts this activity. I can see as part of, what I believe to be, the normal flow of the deep testing app that an activity in the startup wizard is called, so I wonder if the startup wizard then starts the activity of interest in the deep testing app. This will be the next thing I look into
Click to expand...
Click to collapse
Great, from my side I tried running the fastbootUnlock method as you did, and got the same result (false). I looked at the logs and there was a selinux denial for finding the engineering service as my app is an untrusted app, so our only way to run the fastbootUnlock method is through the deep testing app I guess.
daniml3 said:
Great, from my side I tried running the fastbootUnlock method as you did, and got the same result (false). I looked at the logs and there was a selinux denial for finding the engineering service as my app is an untrusted app, so our only way to run the fastbootUnlock method is through the deep testing app I guess.
Click to expand...
Click to collapse
Do you mind if I see the logs? I have had no such denial that I can see.
How have you enabled access to hidden apis?
Have you used any of the permissions from the deeptesting app?
User154 said:
Do you mind if I see the logs? I have had no such denial that I can see.
How have you enabled access to hidden apis?
Have you used any of the permissions from the deeptesting app?
Click to expand...
Click to collapse
2022-08-30 14:30:02.115 669-669/? E/SELinux: avc: denied { find } for pid=22831 uid=10866 name=engineer scontext=u:r:untrusted_app_29:s0:c98,c259,c512,c768 tcontext=u:object_r:engineer_service:s0 tclass=service_manager permissive=0
2022-08-30 14:30:02.115 22831-22831/com.danieml.unlockme E/Unlockme: False
There are the logs. I enabled hidden apis, yes, didn't add any extra permissions though. By the way, did you use some specific keys for signing the app (platform keys for example)?
daniml3 said:
2022-08-30 14:30:02.115 669-669/? E/SELinux: avc: denied { find } for pid=22831 uid=10866 name=engineer scontext=u:r:untrusted_app_29:s0:c98,c259,c512,c768 tcontext=u:object_r:engineer_service:s0 tclass=service_manager permissive=0
2022-08-30 14:30:02.115 22831-22831/com.danieml.unlockme E/Unlockme: False
There are the logs. I enabled hidden apis, yes, didn't add any extra permissions though. By the way, did you use some specific keys for signing the app (platform keys for example)?
Click to expand...
Click to collapse
I had a closer look at the logs and I can see that sadly I am getting the same SELinux error.
I can't see much of a way around it at the moment.
I have made a thread in general should anyone wish to discuss this further. Most of this is applicable to all Oppo devices and there are people that have looked at this in different ways and found different things out when trying to unlock fastboot on other devices. I think it would be useful to have somewhere to discuss unlocking fastboot on Oppo devices in general.
[DISCUSSION] A thread to collate and share what is known about unlocking fastboot on Oppo devices
Admin: Please move/delete this thread if it is in the wrong place or against the rules. I wanted to create a thread to discuss unlocking fastboot mode on Oppo devices in general, rather than discussing it in terms of any one device in...
forum.xda-developers.com