I'm building an Android embedded system which requires direct use of USB devices. The app will start when the device boot up. However, when accessing USB device normally, I have to request permission first. I don't want that permission popup comes up. I know there is a way to use intent-filter to directly get permission after user authorize it the first time but I don't know if this is the most ideal way. My device is a rooted android development board so basically I can change anything in the system. I know all the permission data is stored in /data/system/packages.xml but the USB permission is not real user-permission. I want to know if there is a place like /data/system/packages.xml that stores all the usb permissions like this:
For app: com.aaa.app, vendorId="1111" and productId="1111", permission="true".
I think there should be such a place to store this info cus the intent filter needs this. Anyone knows which file I should look at in the system? Thanks
After some investigation, finally found the place where this file is stored by myself. If you look at Android source code and locate com.android.server.usb.UsbSettingsManager (https://github.com/android/platform_frameworks_base/blob/4b1a8f46d6ec55796bf77fd8921a5a242a219278/services/usb/java/com/android/server/usb/UsbSettingsManager.java), all the USB related permission functions are here. And then you can search for mSettingsFile, you will find some code lines:
mSettingsFile = new AtomicFile(new File(
Environment.getUserSystemDirectory(user.getIdentifier()),
"usb_device_manager.xml"));
Then dig into the Environment class getUserSystemDirectory method, you will find the usb_device_manager.xml file is usually (system and ENV variable dependent if you look at the source code of Environment) located at
/data/system/users/0/usb_device_manager.xml
where 0 is the userId. This may very in your case. If I give the app the USB permit, then inside the file, it will show like this:
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<settings>
<preference package="com.xxxx.testusb">
<usb-device vendor-id="1003" product-id="9220" class="0" subclass="0" protocol="0" manufacturer-name="Unknown" product-name="BlendMicro 8MHz" serial-number="" />
</preference>
</settings>
If you uninstall this app, then this entry will be removed automatically.
Here is a more detailed explanation I found just now. https://groups.google.com/forum/#!topic/android-platform/3duEI8rFERo
Related
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?
I want to read the status file of all processes in an Android system. I check the permission of /proc/pid/status files, it is -r-r-r-, seems like it could be read from every user, and I have turn seAndroid off.
In shell, it works fine, but when I read the file in an application (.apk), it always return "no such file". I think maybe it is the permission issue, but I don't know why, what blocks an application from reading this file.
I have been searching for code through which I can fetch Device's name defined by user for his own device .
Have gone through various stackoverflow questions , but none seems to work for me ?
Image as seen in below : Will require Thanks Thanks (SM-T211 ) from android code
Try this:
String ownerInfo = Settings.Secure.getString(getContentResolver(),
"lock_screen_owner_info");
As of Android 4.4.2 the owner info value is moved to lock screen database,/data/system/locksettings.db to which 3rd-party apps have no read/write access. That's, there is no reliable way of reading owner info for later Android versions except for rooted device.
You need to get build.prop file of system which is possible either if your device is rooted or if your has system privileges....
heres the code you may follow to get and edit build.prop
Check this App in Play Store. build.prop Editor. Since it's open source, and the code is extremely simple, you can use it as a stating point: https://github.com/nathanpc/Build.prop-Editor
Try this :
BluetoothAdapter myDevice = BluetoothAdapter.getDefaultAdapter();
String deviceName = myDevice.getName();
Make sure you add to your manifest:
<uses-permission android:name="android.permission.BLUETOOTH"/>
In my application i have to write the Data to USB stick(Pendrive) from the application.
My application will support to write the data to Local memory and USB stick(Pendrive).
Currently i am able to write the data to Local memory ,but i am unable to write to USB stick(Pendrive).
Do we need to add any extra permission other than WRITE_EXTERNAL_STORAGE?
Is writing to USB stick(Pendrive) through app possible?
I am able to ready the files which are there in the USB,i am not able to write the data.
Here is the folder path where i want to write the data.
"/storage/usb1/TestFolder"
Can i get some help on this?
In order to write some data to USB, we need
uses-permission android:name="android.permission.WRITE_MEDIA_STORAGE"
By referring some links i got to know that the above permission can get by Provider of the device.
So we can apply above mechanism to get it done.
I've created a sample project using BackupRestore. I went to register for a key at Android Backup Service. I got the following:
Your key is:
AEdPqrEAAAAIW4p30C1GTNjzBOqWrb0clI7_OCWxm3ddIgkKhw
This key is good for the app with the package name:
com.example.android.backuprestore
Provide this key in your AndroidManifest.xml file with the following element,
placed inside the <application> element:
<meta-data android:name="com.google.android.backup.api_key"
android:value="AEdPqrEAAAAIW4p30C1GTNjzBOqWrb0clI7_OCWxm3ddIgkKhw" />
When I launch the app and choose "Bacon" + "Tomato", I can see pending backups using dumpsys backup. So I force run it (bgmr run => pendings disappear) and uninstall the app.
When I restore it, logcat tells me "No restore data available" and of course, the settings aren't displayed with the correct info.
Any ideas what I could be doing wrong ?
When you uninstall the app the backup data got removed. Lookup logs for
BackupManagerService: Removing backed-up knowledge of <app package>
Seems that backup/restore process can vary from manufacturer and device. Testing Backup and Restore document can simple work by uninstalling and installing using a nexus device, but I would not expect the same behavior and consistency on every device.
See also this answer https://stackoverflow.com/a/13648673/1598308
Had the same error, only years later. It's probably because you are using Google Transport instead of LocalTransport. Google imposes a rate limit of 24 hours for every backup, so it's trying to create a backup, but it doesn't, and the restore fails.
Run adb shell bmgr list transports to see the transports.
Run adb shell bmgr transport android/com.android.internal.backup.LocalTransport to change the transport to Local.