Database Develop

[DEV GUIDE][2016.12.22] How-To SU

Guidelines for problem-free su usage
How-To SU is my guide on using "su" in your own programs (to execute commands as root). The guide covers the major common pitfalls and also provides example code, as I have been asked by several developers to provide.
I also did a presentation on this stuff at the Big Android BBQ 2012, so if you're looking for the article and code promised there, here it is!
The text is too long to copy here, but you can find it here:
http://su.chainfire.eu/
Example code is located on GitHub:
https://github.com/Chainfire/libsuperuser
If you are not an app developer, you have no business posting in this thread. This thread is for developer discussion on the article/example code only. In fact, I do not expect many posts in this thread at all - it's all rather straightforward, and this is not a helpdesk.
Moderators: Do not move this thread to a development subsection, 0-posters need to be able to reply to it.

Awesome job man, I definitely learned some new stuff. I've done a little bit differently than your implementation: instead of doing AsyncTask -> run su code inside I did this in my Root class:
Code:
class BackgroundThread extends AsyncTask<String, Void, Void> {
private String s;
public BackgroundThread(String command) {
s = command;
}
@Override
protected Void doInBackground(String... command) {
Process process = null;
DataOutputStream os = null;
try {
process = Runtime.getRuntime().exec("su");
os = new DataOutputStream(process.getOutputStream());
os.writeBytes(s+"\n");
os.writeBytes("exit\n");
os.flush();
process.waitFor();
} catch (Exception e) {
}
finally {
try {
if (os != null)
os.close();
else
process.destroy();
} catch (Exception e) {
}
}
return null;
}
}
And then receive the command in the parameter:
Code:
public void run(String command) {
new BackgroundThread(command).doInBackground();
}
Is this acceptable from your point of view?

No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:
new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...

that's a nice read
thanks for the guide

Chainfire said:
No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:
new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...
Click to expand...
Click to collapse
Hmm... I thought calling new BackgroundThread(command).doInBackground(); was doing it in the background thread... if I call new BackgroundThread(command).execute; the commands won't be called at all until I close the application/activity.
I don't do X new calls, for example in the BootService I just batch commands together and execute it once.
I'll use your code and see how it works.

Very nice reading. I always use AsyncTask for su commands, although I learned it the hard way
I remember few months back I couldn't figure out why supersu pops up when timeout is at 2-3 seconds
Sent from my HTC EVO 3D X515m using Tapatalk 2

I generally work with desktop apps. Is there a reason to not use Runnable?
Code:
public void liveBackgroundShellCommand() {
Runnable r = new Runnable() {
public void run() {
boolean LinkLaunched = false;
try {
String[] params = (String[]) Statics.LiveSendCommand.toArray(new String[0]);
Process process = new ProcessBuilder(params).start();
BufferedReader STDOUT = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader STDERR = new BufferedReader(new InputStreamReader(process.getErrorStream()));
This is how I set up a background shell. Then I just pass in the su -c command. Is there a disadvantage to this?

AdamOutler said:
I generally work with desktop apps. Is there a reason to not use Runnable?
Code:
public void liveBackgroundShellCommand() {
Runnable r = new Runnable() {
public void run() {
boolean LinkLaunched = false;
try {
String[] params = (String[]) Statics.LiveSendCommand.toArray(new String[0]);
Process process = new ProcessBuilder(params).start();
BufferedReader STDOUT = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader STDERR = new BufferedReader(new InputStreamReader(process.getErrorStream()));
This is how I set up a background shell. Then I just pass in the su -c command. Is there a disadvantage to this?
Click to expand...
Click to collapse
If this is about desktop Java, then I don't know. I don't use desktop Java, but in most languages and frameworks it is generally frowning upon to block the UI thread, and the UI thread is usually the main/default/first thread.
If we're talking about Android, then this may be bad, depending on what you are doing. A Runnable by itself says nothing about threading or being in the background, a Runnable is just a generic way to define some code you want to run somewhere, sometime.
The code you pasted here does start the process, but it does not wait for the process to exit or read/write to the streams. As such, this piece of code does not block, and is fine. 9 out of 10 times however, a piece of code like this is going to be followed by something like process.waitFor() or reading from STDOUT/STDERR in which cases it does block, and is thus holding up your UI thread and thus bad.
Furthermore, as detailed in the article, calling "su -c" can be errorprone.

Right. I generally launch in a Thread T=new Thread(..). I'be never used AsyncTask. I'm just wondering what its all about.

AdamOutler said:
Right. I generally launch in a Thread T=new Thread(..). I'be never used AsyncTask. I'm just wondering what its all about.
Click to expand...
Click to collapse
Ok, yeah that's fine. AsyncTask is pretty much a Thread wrapper with handy utility functions (onPreExecute, onPostExecute, onProgressUpdate) that is specifically aimed at running a short-lived task away from the UI thread, often with UI feedback (it's brilliant for use with progress dialogs, for example).

Chainfire said:
Ok, yeah that's fine. AsyncTask is pretty much a Thread wrapper with handy utility functions (onPreExecute, onPostExecute, onProgressUpdate) that is specifically aimed at running a short-lived task away from the UI thread, often with UI feedback (it's brilliant for use with progress dialogs, for example).
Click to expand...
Click to collapse
Ah ha! its like a SwingWorker() but with better functionality... Thanks Chainfire! I just looked and apparently it's not available on desktop or I would be switching immediately. That's a wonderful class.

Chainfire said:
Guidelines for problem-free su usage
How-To SU is my guide on using "su" in your own programs (to execute commands as root). The guide covers the major common pitfalls and also provides example code, as I have been asked by several developers to provide.
Click to expand...
Click to collapse
Great & sorely needed topic, thank you. I rarely check this forum, but stumbled in here. Hopefully busy devs of SU apps will be pointed here by someone.
I continue to have lots of problems with SuperUser/SuperSU apps that seem to be pre-configured or something to prevent SU access; and the user is never even prompted. But I don't think this is being discussed here.
At some point in the early development of ICS ROMs I noted that SU calls were taking much longer, perhaps about 0.1 seconds. So I optimized the 4-5 seconds and 40 or 50 calls (including blind chmod's for files that didn't exist on many devices) to about 2-4 calls for most devices.
I know I continue to be guilty of calling SU, and shell, and various other things from improper places, such as UI threads, onCreate etc. But I don't think these cause too much trouble in general, so putting these in threads or wherever is an exercise I save for an app re-design.
My app currently allows selection of "SU Type", but it doesn't seem to be needed anymore, now that I'm avoiding the quoting problems I've had previously.
I use the system() call from C/JNI in a lib. My best/default is like this, where CMD is the command, and noting that \" is " escaped in C:
system ("echo \"CMD\" | su -c sh");
This works, but writes to the filesystem every time:
system ("su -c \"sh /data/local/cmd\""); // Write CMD to cmd file first.
The simplest, but I was having more problems with this for whatever reason; perhaps quoting issues:
system ("su -c \"CMD\"");

thx
---------- Post added at 11:03 PM ---------- Previous post was at 10:58 PM ----------
it is great

pisy3 said:
thx
---------- Post added at 11:03 PM ---------- Previous post was at 10:58 PM ----------
it is great
Click to expand...
Click to collapse
I'm trying to convert my app to use your example classes for running root commands, as most of my app was implemented ok, but I needed to change a couple of bits based on your document. Once chaning I keep running into the following error:
11-20 22:16:39.770: I/System(31924): libcore.io.ErrnoException: kill failed: ESRCH (No such process)
11-20 22:16:39.770: I/System(31924): at libcore.io.Posix.kill(Native Method)
11-20 22:16:39.770: I/System(31924): at libcore.io.ForwardingOs.kill(ForwardingOs.java:77)
11-20 22:16:39.770: I/System(31924): at java.lang.ProcessManager$ProcessImpl.destroy(ProcessManager.java:257)
11-20 22:16:39.770: I/System(31924): at eu.chainfire.libsuperuser.Shell.run(Shell.java:100)
11-20 22:16:39.770: I/System(31924): at eu.chainfire.libsuperuser.Shell$SH.run(Shell.java:149)
11-20 22:16:39.770: I/System(31924): at com.rageconsulting.android.lightflow.util.RootUtil.runRootUnixCommand(RootUtil.java:49)
I'm calling my own helper method which is just a wrapper around your Shell class and it's getting called from an IntentService so I'm not quite sure why this happens.

You can ignore that.
By calling exit here, the process is usually gone.
When it tries to destroy the process in this line, the process is already gone, so it throws that error message as there is nothing to kill/destroy.
Before Android 4.0 this message was not even printed into the log.

Update the library code with some changes (like proper gobbling). See GitHub

Hello dear developers of the supersu. first thanks for good work. I don't know if anyone informed but after htc one s jb update there seem to be some compatibility problems.

The article has been updated to v1.20.
Changes are clearly marked in the "Table of Contents"
http://su.chainfire.eu/

Does the library support other superuser apps too?

mcnamaragio said:
Does the library support other superuser apps too?
Click to expand...
Click to collapse
Yes, it's all about best practises when calling the su binary - it should work with all superuser apps.

[Q] Modifying notification

Hi folks,
even though there are many nice 3rd party twitter clients available they are all missing an important feature: push notifications using GCM. The original Twitter app offers GCM based notifications but the app itself is more or less crap.
Therefore I thought about utilizing the original Twitter app for receiving GCM messages which create the Android notifications and then modify these notifications so that another (3rd party) app is started when clicking on them. I already managed to hook into the NotificationManager:
Code:
XposedHelpers.findAndHookMethod(android.app.NotificationManager.class, "notify", String.class, int.class, Notification.class, new XC_MethodHook() {
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
XposedBridge.log("NotificationManager.beforeHookedMethod(): param=" + param);
for (Object o : param.args) {
if (o instanceof Notification) {
Notification n = (Notification) o;
XposedBridge.log("NotificationManager.beforeHookedMethod(): notification=" + n);
}
}
}
}
);
At this stage, where simple things as changing Notification.tickeText work, I tried the following:
1) Creating a new PendingIntent and assigning it to Notification.contentIntent:
Code:
Intent LaunchIntent = context.getPackageManager().getLaunchIntentForPackage("it.mvilla.android.fenix");
PendingIntent contentIntent = PendingIntent.getActivity(context, 0, LaunchIntent, 0);
n.contentIntent = contentIntent;
This fails due to the fact that I did not succeed in getting my hand on a Context instance. Does anyone have got an idea on how to get a Context instance or can provide another possibility for creating the PendingIntend without a Context?
2) As the previous did not work due to a missing Context I tried to change the LauchIntent of the existing Notification. But I was not able to find the correct place - I did not even find the original LaunchIntent when studying the sources or even by dumping the notification by reflection.
I also started investigating on how to hook into the Twitter app itself. But as the source code is (of course) not public and additionally is obfuscated this seems to be even more complicated. In addition hooking into the NotificationManager is more generic and would allow - when adding configuration - the redirection also for other sources and targets.
As you see, I am somehow stucked. But I'm not hopeless respectively cannot imaging that it should not be possible. So now it's up to you to feed me with the correct ideas
So far and thanks in advance,
yaan04

yaan04 said:
1) Creating a new PendingIntent and assigning it to Notification.contentIntent:
This fails due to the fact that I did not succeed in getting my hand on a Context instance. Does anyone have got an idea on how to get a Context instance or can provide another possibility for creating the PendingIntend without a Context?
Click to expand...
Click to collapse
AndroidAppHelper.currentApplication() should do the trick. Otherwise see this, though if AndroidAppHelper fails most of these probably will, too.
yaan04 said:
2) As the previous did not work due to a missing Context I tried to change the LauchIntent of the existing Notification. But I was not able to find the correct place - I did not even find the original LaunchIntent when studying the sources or even by dumping the notification by reflection.
Click to expand...
Click to collapse
LaunchIntent?
yaan04 said:
I also started investigating on how to hook into the Twitter app itself. But as the source code is (of course) not public and additionally is obfuscated this seems to be even more complicated. In addition hooking into the NotificationManager is more generic and would allow - when adding configuration - the redirection also for other sources and targets.
Click to expand...
Click to collapse
Android API calls won't be obfuscated. Try searching for "NotificationManager" for example and see where it's used.

Yeah, AndroidAppHelper.currentApplication() provides a usable Context instance \o/
Thanks, GermainZ. Now I can go on...

[Q][Development] XSharedPreferences issue, no entries

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

how does xposed modify/affect ART?

Hi people,
I was wondering which parts of ART and what optimizations does Xposed disable. I read from one of @rovo89 GitHub that he needed to disable a couple of optimizations. Do these changes affect performance? If so, how can I make performance better?
Cheers!
-LLJY

It mostly disables method inlining and call sharpening. The latter would usually detect that a call to "myObject.toString()" will always resolve to one particular implementation, so ART would create a call directly to the native address of the compiled method. Both of these make it impossible to hook a method, as ART simply wouldn't look up the method anymore. I don't see a way to avoid this.

Little insight to demonstrate this. Consider this Java code:
Code:
package de.robv.android.xposed.smallapp;
public class MyClass {
private static int sMyField = 999;
public static int returnConstant() {
return 1234;
}
public static void main() {
sMyField = returnConstant();
}
}
This is the Dex code for the main() method:
Code:
0x0000: 7100 0700 0000 | invoke-static {}, int de.robv.android.xposed.smallapp.MyClass.returnConstant() // [email protected]
0x0003: 0a00 | move-result v0
0x0004: 6700 0600 | sput v0, I de.robv.android.xposed.smallapp.MyClass.sMyField // [email protected]
0x0006: 0e00 | return-void
And here is what ART (on Nougat / x86) compiles it to:
Code:
0x00001054: 83EC0C sub esp, 12
0x00001057: 890424 mov [esp], eax
0x0000105a: 8B08 mov ecx, [eax]
0x0000105c: C781B0010000D2040000 mov [ecx + 432], 1234
0x00001066: 83C40C add esp, 12
0x00001069: C3 ret
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.

rovo89 said:
Little insight to demonstrate this. Consider this Java code:
This is the Dex code for the main() method:
And here is what ART (on Nougat / x86) compiles it to:
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined.
some new opportunities. But that's still a long way, first hooking has to work at all.
Click to expand...
Click to collapse
Thank you for the response, I would just like to report that xposed adds a substantial amount of overhead compared to normal ART. Especially noticeable when ART is set to optimize everything.
Before flashing xposed, my phone running my own custom rom is noticeably faster compared to the iPhone 7. After flashing xposed, it lags behind quite abit.
I did loads of testing to come to this conclusion.
Just some feedback for you

_LLJY said:
I did loads of testing to come to this conclusion.
Click to expand...
Click to collapse
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.

rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
I tested Xposed on 3 devices, 2 ARMV7 and one ARM64. The Redmi note 4g(snapdragon 400) doesn't seem to be affected much at all. The Xperia Z5 (810) seems to slow down noticeably(I tested against a brand new Z5 with the same Rom) the Xiaomi mi3(800) does also get affected slightly although i haven't compared it against another new device. I will conduct a more scientific test where I actually time the devices using discomark to see how they do and put the results in a spreadsheet.

rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
on 6.0.1(nexus 5x) i don`t see any diference with or without xposed but seems on nougat will be a little complicate with the art modifications ! btw @rovo89 the xposed can be your phD theme (this is research)

Xposed sdk 23 v 86 does not work with cm 13 for i 9515 with newest kernel 3.4.113 anymore. Hope there will still be updates for xposed sdk 23????
Quote:
Originally Posted by friscoboi @sombree 20161115 got me stuck in a bootloop so far. I did everything as always with updates? Or does it take more than 30 minutes to reboot with the new kernel the first time?
It's because you're using xposed. And no, I'm not going to rebuild ROM with one of those unofficial fixes - you'll have to wait for fixed xposed
(Sorry to post here, but the older xposed thread is closed...)

rovo89 said:
Little insight to demonstrate this. Consider this Java code:
Code:
package de.robv.android.xposed.smallapp;
public class MyClass {
private static int sMyField = 999;
public static int returnConstant() {
return 1234;
}
public static void main() {
sMyField = returnConstant();
}
}
This is the Dex code for the main() method:
Code:
0x0000: 7100 0700 0000 | invoke-static {}, int de.robv.android.xposed.smallapp.MyClass.returnConstant() // [email protected]
0x0003: 0a00 | move-result v0
0x0004: 6700 0600 | sput v0, I de.robv.android.xposed.smallapp.MyClass.sMyField // [email protected]
0x0006: 0e00 | return-void
And here is what ART (on Nougat / x86) compiles it to:
Code:
0x00001054: 83EC0C sub esp, 12
0x00001057: 890424 mov [esp], eax
0x0000105a: 8B08 mov ecx, [eax]
0x0000105c: C781B0010000D2040000 mov [ecx + 432], 1234
0x00001066: 83C40C add esp, 12
0x00001069: C3 ret
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
Click to expand...
Click to collapse
Dalvik VM also uses JIT compiler
Sent from my GT-S7580 using Tapatalk

DodoGTA said:
This is the Dex code for the main() method:
And here is what ART (on Nougat / x86) compiles it to:
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
Dalvik VM also uses JIT compiler
Click to expand...
Click to collapse
You don't say

rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
I still haven't done actual tests due to time constraints but an interesting thing is that XDA labs does indeed take a fraction of a second longer to launch with Xposed. But it's barely noticeable, I had to time it.

_LLJY said:
I still haven't done actual tests due to time constraints but an interesting thing is that XDA labs does indeed take a fraction of a second longer to launch with Xposed. But it's barely noticeable, I had to time it.
Click to expand...
Click to collapse
if it helps, with xposed activated and deactivated (typically after a new rom install), activated it's perfectly fine, performance is a bit hindered but not so much that you notice it right away. Skip ahead a couple hours and it's laggy and slow, stuttering, apps don't open quite as fast, nor do they stay open (that's to do with another issue regarding xposed v87). But before that v87 update, that issue persisted.
But when i have xposed disabled (after flashing the new build), it's perfectly fine, performance is as snappy as a GS4 (SD600) would get you and apps open faster, don't lag or get bogged down. And they generally perform much better over time.
I can at least for me, confirm this since I've started using xposed (v70-76 i believe).
(Sprint Galaxy S4 SD600 16gb model, cm13 (12/4/2016 nightly) with ten modules installed.)
Do let me know if this helps at all with determining the performance hit with xposed enabled and with a decent amount of modules installed.

I'm gonna guess there's no new news about xposed for nougat

Shiftydogit said:
I'm gonna guess there's no new news about xposed for nougat
Click to expand...
Click to collapse
Correct. @rovo89 has not quite cracked the code on making it work with N just yet. He's working on it though so patience is required.

sjamie said:
Correct. @rovo89 has not quite cracked the code on making it work with N just yet. He's working on it though so patience is required.
Click to expand...
Click to collapse
Hopefully he gets it N seems like a pain in the grass for a lot of things we power users enjoy

Shiftydogit said:
Hopefully he gets it N seems like a pain in the grass for a lot of things we power users enjoy
Click to expand...
Click to collapse
Amen.

Wonder what's happening, I heard that Nougat xposed is unreliable with JIT?
I hope it gets fixed soon and gets out to the public.
Anyways, great job devs<3

Rotated Quickbits said:
Wonder what's happening, I heard that Nougat xposed is unreliable with JIT?
I hope it gets fixed soon and gets out to the public.
Anyways, great job devs<3
Click to expand...
Click to collapse
Maybe a new year present????

mitas35 said:
Maybe a new year present????
Click to expand...
Click to collapse
I'm going to like and respond to this post as it was only minutes away from the new years

All I'm hoping for, is that Android O doesn't mess with the compiler any more than N did, Android O Developer Previews are going to come before the official announcement on the 17 - 19 May 2017, and first betas are set to come in the summer, which aren't that far away...
If it does, then its going to be a long catch up game for @rovo89

Question What is the current state of unlocking fastboot?

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