how to turn on / turn off developer mode in Android from app? - android

I want to create an app to turn on/turn off Android developer mode. This will be on a rooted device. What api's do need to call?

I know i am answering it very late but i will surely help other who are searching on this.
To enable developer options programatically :
Settings.Global.putString(this.getContentResolver(), Settings.Global.DEVELOPMENT_SETTINGS_ENABLED, "1");
To disable :
Settings.Global.putString(this.getContentResolver(), Settings.Global.DEVELOPMENT_SETTINGS_ENABLED, "0");
But to access this Settings.Global... , it requires a permission
android.permission.WRITE_SECURE_SETTINGS
But normally , This permission is only granted to system app
You can also grant this permission to user app using ADB
Since you said your app would be running on a rooted deice , so have access to the shell , so you can grant this permission to your app by running the below shell command
pm grant <your.package.name> android.permission.WRITE_SECURE_SETTINGS

I don't think it is possible. Since it is part of the Settings.Secure.
Secure system settings, containing system preferences that applications can read but are not allowed to write. These are for preferences that the user must explicitly modify through the system UI or specialized APIs for those values, not modified directly by applications.

Related

Grant USB permissions as device owner

A device owner can grant runtime permissions to a third-party app using DevicePolicyManager.setPermissionGrantState() to avoid user prompts.
But is there any way for a device owner to grant USB permissions as well, so that this app gets access to plugged USB devices without user prompt ?
I've tried to call UsbManager.grantPermission() (with reflection) but it raises a SecurityException since it requires the MANAGE_USB permission which is granted only to system apps (and not to device owner, obviously).
NB: I'm looking for a solution working on a non-root & non-custom Android system, the device owner app is set using Android Enterprise provisioning methods.
There is a special system config to disable USB permission dialogs:
https://github.com/aosp-mirror/platform_frameworks_base/blob/8ff4a5a5b510e724b25ac00369696594bb0c9fdc/core/res/res/values/config.xml#L2283
Maybe you can also change it at runtime with root privileges using setprop.
Another way is to customize the UsbUserSettingsManager class, specifically this method: https://android.googlesource.com/platform/frameworks/base.git/+/master/services/usb/java/com/android/server/usb/UsbUserSettingsManager.java#178
I assumed that as a device owner you have full control over your ROM source code.
It's a bit old, but hopefully it helps s.o. else.
I've been using this for granting permission to apps
public boolean setPermissionGrantState (ComponentName admin,
String packageName,
String permission,
int grantState)
Link: https://developer.android.com/reference/android/app/admin/DevicePolicyManager#setPermissionGrantState(android.content.ComponentName,%20java.lang.String,%20java.lang.String,%20int)

Should a data application signed with the vendor key be able to run 'su'

Background: I am developing for a signage device which is to be remotely operated. I need an application that can
Fetch and install new packages
Reboot the device (for troubleshooting)
I have an unrooted Android device. I also have files which I am told are the platform keys.
I have developed an application which attempts to kick off the su process.
Process p = Runtime.getRuntime().exec("su");
Before I signed the application with the platform keys this was throwing an IOException, with the message being Permission Denied.
I signed the application with these platform keys, and I am still getting the Permission Denied exception.
Here are three contradictory statements. Which one of these statements (if any) is correct?
Statment 1: This should work. The application, even though is is stored in /data/app, should be able to run su. Either I have the wrong keys, or there's some other entry I need to add to the manifest to get it to work.
Statement 2: This shouldn't work. Even though it is signed with the platform key, the application is in /data/app, so it's a data application, not a system application. Data applications cannot run su on an unrooted devices. If this application was installed into /system/app, then it would be able to run su. (And I can't get it into /system/app because it's unrooted, so I'm stuck).
Statment 3: This will never work. If the device is not rooted, then NOTHING can run su, even if it is a signed system app.
Android shouldn't even have a su binary if you didn't flash some sort of root method to the device, such as Magisk or SuperSU.
Even if it does have a su binary, I wouldn't expect it to work, for one of two reasons. Assuming that your device comes with a preinstalled su binary, who's managing it? If it's unmanaged, it should just deny all requests. If you flash a root method, then it's up to that manager to decide if your app gets access to su, regardless of whether you have signature-level permissions or nor (the root manager uses a different signature, after all).
And why would you even need access to su as a signature app? You have total access to the device anyway. If you need to run a command, you should have no problems no matter what you run, as long as it's done from your platform-signed package. But since you have full access, the native APIs should let you do everything you need.
As for the IOException returned when you try to execute su in a Process, that's just a weird Android quirk. If there's no su binary installed, it'll sometimes return command not found and other times permission denied, depending on the device.
The point I think I'm making is that, unless your app is the root manager, you could be part of the system_server and still have the same access to su as everyone else. For which statement I agree with, I think #3, although I don't fully agree with it, because chances are su just doesn't exist, or it's a dud binary.
I've explained why #1 shouldn't be true, but #2 is just incorrect. If you look at the platform manifest, every permission that requires a privileged app can also be granted to signature apps. So even if you did move your app to /system/priv-app/ (/system/app/ won't make it privileged), it wouldn't make a difference. Basically, if your app is signed by the platform signature, it doesn't matter where it's installed.
EDIT:
You can easily reboot by just running reboot as a command, since you have signature-level access to the system, but it's a little more elegant to use the proper API for this. If you use the API, you get the shutdown animation, but you also let the system shut down gracefully, stopping services and sending the ACTION_REBOOT broadcast to any apps that might be listening for that.
To use the API, first add the following permission to your AndroidManifest:
<uses-permission android:name="android.permission.STATUS_BAR_SERVICE" />
Now, where you need to call the reboot action, use the following code:
IStatusBarService bar = IStatusBarService.Stub.asInterface(ServiceManager.getService(Context.STATUS_BAR_SERVICE));
bar.reboot(false); //using true here will reboot to Safe Mode
This method is a hidden method, so if you're using Android Studio to edit and compile, it'll error out. You can use reflection, or use Android Hidden API to access it directly.
This is how System UI implements it in the power menu: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/packages/SystemUI/src/com/android/systemui/globalactions/GlobalActionsComponent.java
This is the class that implements IStatusBar service: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/statusbar/StatusBarManagerService.java#L969
I'd go with Statement 3. This will never work on an unrooted Android device. At least, not on recent Android OS versions (I have no idea if this might work on really old Android devices).
"su" is an application -- there has to be an "su" binary on disk in order to execute it, and Android does not by default provide an "su" binary for security purposes. When you use thirdparty rootkits, they install their own "su" binary to provide a mechanism for the user to elevate themselves to root privileges.
If your app is signed with a special key and granted elevated privileges from startup, why would you need to execute "su" anyway?

Getting into root mode via an App for a device that is not rooted

I'm trying to read the MSR information from an android device with userDebug build , and it requires root permission. I have tried adding :process = Runtime.getRuntime().exec("su"); and when i debugged the program ,the variable process is getting initialized with NULL. And I have made some function call to read the MSR value by specifying its path /dev/msr*,and when i run the program the log window shows Permission denied. So is there any way to get into root permission via an app without having a rooted android device?
So is there any way to get into root permission via an app without having a rooted android device?
By definition, no.
process = Runtime.getRuntime().exec("su");
su command is to run the shell commands in Super user mode.
If the device is rooted, this command causes SuperUser to show a dialog, which lets you either Allow or Block it from root access.
So is there any way to get into root permission via an app without
having a rooted android device?
There is no official way to do this. If your app needs SuperUser access, then you can build one click root method like rooting apps and can ask the user to root first.

Android M: Programmatically revoke permissions

I am currently playing around with android m's new permission system.
What i am planning is to add a screen to my in-app settings where the user can grant or revoke permissions.
The screen would look like the regular system settings screen, but will have additional information why my app needs the specific permission. This settings screen would be an addition to the regular permission handling as suggested in the Documentation.
The workflow would be:
granting permission: open the systems dialog to grant/revoke (like suggested here)
revoking permission: revoke it programmatically
So my question is, can permissions be revoked programatically?
I searched a lot, but didn't manage to get some results.
You can't do anything (at least until now). In addition, there isn't any intent action to open the activity system settings for your app. My suggestion is to open a "feature request" on the developer preview issue tracker.
You can revoke permission from ADB Shell.
if you consider writing shell script and doing all this under programatically then YES, else NO
Grant and revoke permissions
You can use new ADB package manager (pm) commands to grant and revoke permissions to an installed app. This functionality can be useful for automated testing.
To grant a permission, use the package manager's grant command:
$ adb shell pm grant <package_name> <permission_name>
For example, to grant the com.example.myapp package permission to record audio, use this command:
$ adb shell pm grant com.example.myapp android.permission.RECORD_AUDIO
To revoke a permission, use the package manager's revoke command:
$ adb shell pm revoke <package_name> <permission_name>
Starting API 33 (Android 13) you can programmatically revoke previously granted runtime permissions via the revokeSelfPermissionOnKill APIs. E.g.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
context.revokeSelfPermissionOnKill(Manifest.permission.POST_NOTIFICATIONS)
}
Triggers the asynchronous revocation of a runtime permission. If the
permission is not currently granted, nothing happens (even if later
granted by the user).
There is also a function which takes a collection of multiple permissions to revoke.
Be sure to also put a version code guard around this as there currently doesn't seem to be a warning in the IDE. Unfortunately this hasn't been added to ContextCompat yet.
No Programmatically it is not possible in Android M Preview with new permissions Model.
But Manually you can do as given.
revoke permissions manually
for some special permission like SYSTEM_ALERT_WINDOW.
you need this :
adb shell appops set <package_name> SYSTEM_ALERT_WINDOW allow

How can I disable Android USB debugging programmatically

There is a bug on some Samsung Android Phones causing USB-debugging to automatically be turned on if the USB is plugged in. This is obviously a security issue. I want to write a program which will disable USB debugging so that I can start it whenever usb-plug is inserted.
Any ideas on how to do this?
It seems to be impossible. I think I must use Settings.System with ADB_ENABLED, but ADB_ENABLED is a Secure-System-Setting which cannot be changed by a normal application. :-(
On the other hand, there is the permission android.permission.WRITE_SECURE_SETTINGS, so it looks like I can alter it. Can I get it on a rooted phone?
If someone has an idea on how to fix this security issue, it would be great.
I don't think it is a security issue.
First, it is the responsibility of a developer to only make debug messages available that do not compromise his application in the later.
Secondly, debug messages that are used for development should probably have another debug level than for production.
Third, if your application exposes data via adb that compromisses your application, maybe there's something wrong in the app design in the beginning?
Fourth: It is not recommended to toggle settings that the user should be able to configure. I would hate to see manything I configured go on and off by starting an app. Of course, you mentioned the Bug with Samsung. But I think they should be able to fix this.
Regards, Chris
To achieve this , you require android.permission.WRITE_SECURE_SETTINGS permission.
Without root : From ABD execute adb shell pm grant <package-name> android.permission.WRITE_SECURE_SETTINGS
With root : Root access means we can execute shell commands without adb, so workaround for that :
try {
Runtime.getRuntime().exec(new String[]{"su","-c",String.format("pm grant %s android.permission.WRITE_SECURE_SETTINGS",BuildConfig.APPLICATION_ID)});
} catch (IOException e) {
// handle IOException
}

Categories

Resources