I want to modify my viber database on my app.
i use this code:
File f = new File("/data/data/com.viber.voip/databases/viber_messages");
boolean b1 = f.setExecutable(true, false);
boolean b2 = f.setWritable(true, false);
but b1,b2 are false.How can it be done?
i use "android.permission.WRITE_EXTERNAL_STORAGE" permission
You can't modify other apps. Your app is sandboxed, that prevents it from modifying other apps. To quote the docs here:
true if and only if the operation succeeded. If the user does not have permission to change the access permissions of this abstract pathname the operation will fail. If the underlying file system does not support execute permission and the value of executable is false, this operation will fail.
The permission "WRITE_TO_EXTERNAL_STORAGE" allows you to write to e.g. the SD card or other spaces that are "user- visible".
To modify other apps it's required that your phone is rooted and you must use something like a shell. Take a look a libsuperuser here. It gives you the option to create a superuser shell (su permissions). You could copy the db into the directory of your app to modify it (remember to set the required permissions).
Related
For a survey I want to monitor user-compelled changes in the Android M application permission settings.
I decided to create a FileObserver watching /data/system/users/0/runtime-permissions.xml. This file holds all information but only has read/write access for the system -rw-------. chmod won't work because access privileges are restored on every change. So my monitoring app needs system permissions.
I followed this method to deploy my app directly to priv-app directory. Works like a charm, app is considered a system app, but still does not have permission to read the above-mentioned file. File.canRead() fails just as File.exists().
Is there maybe something I have to add in the AndroidManifest.xml to make it work, or is making use of the priv-app folder a complete wrong guess? Do I have to sign the application? For final deployment I wanted to add the application to a custom rom using some kind of kitchen.
I have an app that requires root access. I'm using the following code to request the permission:
Process p = Runtime.getRuntime().exec("su");
What this does is: when the user has granted the root access to the app, it displays the root sign (#) in the statusbar ( which is normal ). The symbol remains in the statusbar even after the app goes to the background or even after that activity is finished. I want the symbol to appear when the permission is granted, and releasing the granted root access after performing the operation, so it removes the symbol from the statusbar.
HideItPro does it so I know it's possible, but I couldn't find a way pf doing it. Can anyone help me how to do this ?
PS: I'm using RootTools sdk for root operations.
Android's permission system is different than traditional Linux. On normal, commercial devices there is no access to "root" and there is no su command. You have to have a rooted ROM for that functionality.
Question about Android runtime permissions. AFAIK, android grant dangerous permission at runtime. I reset my phone, then adb pull /data/system/users/0/runtime-permissions.xml, I found android.ui.system has already granted many dangerous permissions. can anybody tell me how it does?
The mechanism to insert dangerous runtime permissions into the /data/system/users/0/runtime-permissions.xml file via a user-confirmed dialog applies only to third party applications, and is not relevant for built-in applications.
For built-in/system applications and framework components, all
permissions are granted by default when a new user is created or
when the device boots and a systemReady event is fired.
You can see the AndroidManifest.xml from AOSP, where all types of required permissions are written for system components.
For third party apps, when the user grants any runtime permission, it gets added into the file /data/system/users/0/runtime-permissions.xml. The permission gets removed from the file when the user revokes it from any third party app. In the case of a full factory reset, runtime permissions of all third party apps are removed, as /data/system/users/0/runtime-permissions.xml gets deleted (data partition wipe).
But even after a factory reset, /data/system/users/0/runtime-permissions.xml contains runtime permissions (even dangerous ones) for system apps, see the default permissions: runtime-permissions.xml.
And it happens because:
All the default permissions are granted from
PackageManagerService, via these two methods:
newUserCreated() //this get called when new user is created
systemReady() //this get called when device is booted
and the above methods internally invoke:
DefaultPermissionPolicy.grantDefaultPermissions();
Have a look at How DefaultPermissionPolicy triggers
And if you see DefaultPermissionPolicy's implementation, it
contains all the relevant method to load all type of permissions for
System components.
Specifically DefaultPermissionPolicy.grantDefaultPermissions()
internally calls
grantPermissionsToSysComponentsAndPrivApps(userId);
grantDefaultSystemHandlerPermissions(userId);
and it internally invokes grantRuntimePermissionsLPw(), which
performs all the remaining work.
Privileged Permission Allowlisting
Device manufacturers had little control over which signature|privileged permissions could be granted to privileged apps. Starting in Android 8.0, manufacturers must explicitly grant privileged permissions in the system configuration XML files in the /etc/permissions directory.
Android allow system apps present in these directories(system/product/vendor/oem/ | _ext) to whitelist their permissions via writing a XML file.
XML file content:
<permissions> <privapp-permissions package="x.y.z"> <permission name="android.permission.PACKAGE_USAGE_STATS" /> </privapp-permissions> </permissions>
Android.bp file:
prebuilt_etc { name: "x.y.z.xml", system_ext_specific: true, src: "x.y.z.xml", sub_dir: "permissions", }
Add 'x.y.z.xml' to PRODUCT_PACKAGES to make this part of final image (same as for an app)
On target: XML file can be found under 'partition/etc/permissions/priv-app'
PackageManager parse all the XML files and whitelist the permissions mentioned for the package name while install the app on boot.
I am upgrading my Android app's Target SDK Version to 23 (Android M) which has the new Runtime permissions (https://developer.android.com/training/permissions/requesting.html). My app has declared WRITE_EXTERNAL_STORAGE in its manifest, which must now me requested at runtime. Of course, I'd like to only request it when necessary.
I have an abstraction for different storage types, one implements local storage through normal File I/O (not the Android Content Provider stuff). In this class, I get a file path (like /mnt/sdcard/... or /data/data/...) and before accessing that file (read and write mode), I want to check if I have to call RequestPermissions for WRITE_EXTERNAL_STORAGE.
So the question is: What's the safest and simplest way to determine whether a file can be read and written without that permission (e.g. because it's inside getExternalFilesDir()) or not?
You can see here that you only have to ask for WRITE_EXTERNAL_STORAGE when your application needs to write to external storage.
But:
Starting in API level 19, this permission is not required to
read/write files in your application-specific directories returned by
getExternalFilesDir(String) and getExternalCacheDir().
First of all I recommend you to avoid requesting permissions using Intents, because it's a best practice and improves a lot the user experience.
If you can't use an Intent to avoid writing with your app, and you know that some day the user will have to write externally, I think the better would be to ask for the permissions the first time the user takes the "write in external storage" path.
As far as I know, in API23 you only have to ask for permissions once, so I think the easyest way would be to ask for the permissions at the first time that the user needs the functionality, I think that then when he'll execute it again, permissions would remain accepted. You can check your granted permissions with the procedure shown here.
Here you can read:
The user is prompted to give permission once, either at run time or at
install time (depending on the user's Android version). After that,
your app can perform the operation without requiring additional
interaction from the user. However, if the user doesn't grant the
permission (or revokes it later on), your app becomes unable to
perform the operation at all.
I am trying to know if I can get root privileges with a system app to execute commands.
In this code:
getApplicationInfo().uid
In the documentation I can read that the uid is the kernel user-ID that has been assigned to this application; currently this is not a unique ID (multiple applications can have the same uid).
But how is this assigned?,
And the uid assigned to system apps,
does it has more privileges than normal apps to execute commands?
For all practical purposes, your Application's process will never be executing as uid=0 or root, as it has irreversibly changed to an ordinary user ID before a single line of code written by you executes.
When people make "root" apps, they are not changing the application process itself back to root - that is simply not possible. Instead, what they are doing is executing a new helper process which runs as root. Underneath the java level, this is ultimately done by calling an exec() family function on a file which has the setuid bit set. This file might either be the helper program itself, or more commonly it is a "root shim" such as a hacked "su" which in turn runs the specified helper program as root. Such a helper program is almost always native code, and is probably not registered with the Android framework to be able to utilize Android-level functionality.
System Applications do not run as root either. What they have that third party apps do not is special Android-level Permissions which cause platform services that do run as root or other privileged user id's to privileged things on their behalf. A few android permissions can also confer membership in user groups which have special access - some of these are available to third party apps (Internet permission for example) and some are not.
Basically, (I am not delving into the entire Linux explanation about uids. It can be easily found if you are interested). The uid in android is comprised of 2 parameters:
Application id
User id
The formula is this:
uid = app_id+100,000 * user_id
app_id is basically a random number (not REALLY random, but is different from device to device) that is assigned ti each application and the user_id, which is used on tablets running JellyBean, is assigned per user on the device (users are assigned a number starting user 0 , user 1, ...user n - for every new user defined on the device).
Applications can share an id as explained here: http://developer.android.com/guide/topics/manifest/manifest-element.html
Of course an app can't have the same uid for two different users, but the same app can have the same uid as another app the same user possesses.
System apps run are the only apps that may actually have access to services that other users may not have access to. They are located on the device under /system.
In order to write a system application you need to download the AOSP from Google, and compile it yourself with your app included.