I'm using method freeStorageAndNotify() with permission android.permission.CLEAR_APP_CACHE to delete system cache of all installed applications. But the method started throwing InvocationTargetException from the android marshmallow 6.0 version.
After googling the issues I found the same issue as reported here:
Android M reflection method freeStorageAndNotify exception
So here the conclusion was, freeStorageAndNotify() stopped working since google has raised the method's signature level now to signature|system.
But now the question is how other third-party apps like 'Clean master' are still able to delete system cache of all installed applications by taking accessibility permission from the user for 6.0 devices?
I don't think that 'Clean master' actually uses Accessibility Permissions to clean installed apps cache.
But, if you're interested, this goal can be achieved by using AccessibilityService in your application.
Within your class that extends AccessibilityService you have this callback:
#Override
public void onAccessibilityEvent(AccessibilityEvent aEvent) {
AccessibilityNodeInfo rootNode = aEvent.getSource();
//...
}
Here you can invoke
rootNode.findAccessibilityNodeInfosByViewId()
or
rootNode.findAccessibilityNodeInfosByText(),
it will return all matching AccessibilityNodeInfo objects (sub-nodes) in tree. Then, you just need to detect which of them is Button (node.getClassName()) and call subNode.performAction(AccessibilityNodeInfo.ACTION_CLICK).
On Android M, you first need to to open system's App Info screen (you can find instructions here How can I start android application info screen programmatically?) for the concrete app and, by the scheme described above, perform sequential clicks on the buttons "Storage" —> "Clear cache".
In order to clear cache for all installed apps you probably have to iterate through the all installed apps (List<ApplicationInfo> installedApplications = context.getPackageManager.getInstalledApplications(0);)
and repeat the procedure mentioned above.
The system cleaner I'm using has access to the STORAGE permissions. This permission gives the app authority to clear any data in the shared external storage directory.
http://developer.android.com/reference/android/Manifest.permission_group.html#STORAGE
I don't think any 3rd party app can actually clear system cache anymore unless the device is rooted and the app is designed for rooted devices.
those apps only do the same thing all the time. use it on an old device and a new device the results are the same. the only help i have seen is that they can kill or restart some background processes, not to clean the cache. therefore no API can restrict their trick..
Related
I understand that when you install an android app you need to accept the permissions requested by the app. When you run the app, when it comes to the point that app really about to use that permission and perform a task, the android system has to check again "whether this app is allowed to perform this task?". I need to perform some task (log the event) at this moment. How can I do this?
There is a catch. I want to identify these instances (moments) for other running apps (not for my app)
(Ex: I want to know when DropBox app is about to access the internet.)
I need to perform some task (log the event) at this moment. How can I do this?
You can download the Android source code, modify it to incorporate your desired security flaw, compile the results into a ROM mod, and install that ROM mod on your own device.
This is not possible via the Android SDK.
There is a catch. I want to identify these instances (moments) for other running apps (not for my app) (Ex: I want to know when DropBox app is about to access the internet.)
You are welcome to install and use a firewall package on your rooted Android device and perhaps hook something up that way, for this specific scenario. In general, what you seek is not possible, for blindingly obvious privacy and security reasons.
Android users can go to the "manage application" (AKA "applications manager") screen, choose an app and make a choice of what to do there using the "App-info" screen.
I wish to make an app that allows the user to make those choices in even an easier way (maybe even batch operations).
How do I access each of the features there? Which permissions would I need and for features that are not available via the API, how could I get them via root access?
The features I'm talking about are:
Force stop.
Uninstall last updates.
Disable.
Uninstall - for this I actually know how to do it, but it needs confirmation of course:
final Uri packageURI=Uri.parse("package:"+packageName);
final Intent uninstallIntent=new Intent(Intent.ACTION_DELETE,packageURI);
Toggle "show notificaions".
Clear data
Clear cache
Clear defaults. I would also like to know how to set as default and get all registered intents and their currently default apps (which will handle them).
View app storage usage in both external & internal storage (and cache)
If you don't know what I mean, here's a screenshot of the app-info page:
I've also found some interesting Android permissions that existed ever since API 1, but I can't find any examples of how to use them. Such permissions are CLEAR_APP_CACHE , DELETE_PACKAGES , and CLEAR_APP_USER_DATA.
What I have found is a Samsung code example (available here) that has a permission of CLEAR_APP_CACHE, but I can't find where they use it, if at all.
I am trying to write a simple android app that switches off my phone screen. When I am runnning this app I get Security Exception: Permission denial app requires android.permission.DEVICE_POWER. I know that this is a protected permission but my phone is rooted. What do I specify that I can use this permission? I have already tried declaring DEVICE_ADMIN permssion along with the DEVICE_POWER permission but it still doesn't work.
Rooting potentially lets you circumvent or modify the android security model, but it doesn't necessarily mean you get special privileges for an android API which enforces it. You cannot ordinarily run an application itself as root, while code in a helper executable which you could start as root will have substantial difficulty interacting with the Android APIs.
What you are trying to do may really not be a very good idea. But if you really want to do it, you would need to either install your own build of Android so that you have a (self generated) key matching that which you used to sign the platform, which you can then use to sign your application, or else try to install your application on the system partition.
If all you want to do is turn the screen off, then why don't you use the PowerManager? According to the documentation, the goToSleep() function will force the device to go to sleep.
This question has been asked before at How does Android enforce permissions?. While the discussions there are good, the question is still not fully answered.
In the development environment, exceptions are thrown when the app tries to do something that requires permissions not declared in AndroidManifest.xml. So how does the run-time system implement the run-time checking?
I guess it's most likely done in the core framework, which may or may not need support from native code. But I don't know what source code files in AOSP are relevant to this.
Android uses a lot of the standard Linux(-kernel?) mechanisms especially when it comes to hardware restrictions.
Every app gets assigned a new unique (Linux-)user id and whenever the app process is created the system creates it with that user id. The id will never change unless you remove the app. That means for accessing the lower system levels your app will appear as a certain user and every (Linux-)permission system that works with users will also apply to your app.
If you request WRITE_EXTERNAL_STORAGE in the manifest your app will also become member of the (Linux-)group (called sdcard_rw) that has permissions to write to that storage. Permissions on the filesystem are enforced to only allow writing to the system user (=owner) and the sdcard_rw group, anyone else (=other) may only read. See also Is Google blocking apps writing to SD cards
By doing that Android has to do pretty much nothing except for setting the correct UID/GIDs of the processes it spawns once the app starts and the rest is handled at lower levels. Apps that are not member of a certain group simply don't get access to certain hardware.
List of permission <> group mappings: platform.xml
There are also some (Android software) restrictions that are based on either the signature of your app and / or simply by looking up the permissions your app requested: e.g. ContextImpl#checkPermission() - but those permissions have to be checked at every entrypoint to code that allows restricted actions.
From time to time people discover ways to e.g. turn on GPS programmatically because a check like that is missing somewhere.
With regard to your second paragraph, "exceptions" are runtime faults. Permissions are not enforced at build time, only at run time.
Accessing hardware, low level operating system resources, and system files generally requires the app userid to be a member of an appropriate group which it may be assigned by the package manager as a result of having a corresponding android permission. (Familiar examples of that would be network sockets, and the sdcard write which zapl mentioned, but also system-only things like talking directly to the GSM modem or reading the raw touchscreen coordinates).
For the majority of android operations that are done by way of calling library functions which are stubs for interprocess communication to services running in a different process, the platform code running in the more privileged process on the receiving end of the ipc request checks with the package manager to find out if the calling application has the necessary android permission.
Many special permissions are only available to apps signed with the system signature - even if another app claims those in its manifest, they will not be applied by the package manager.
This question already has answers here:
Is it possible to detect Android app uninstall?
(8 answers)
Perform a task on uninstall in android [duplicate]
(4 answers)
Closed 7 years ago.
I though it was not possible but I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called.
I would like to replicate this behavior in my App.
I tried with an Activity listening to "android.intent.action.DELETE" Intent, as suggested here:
How to know my app is uninstalled from the device...?
But as I'm about to uninstall my app, the chooser pops up asking to pick my application or the package uninstaller. How can I avoid this?
Is there a different way to intercept your application UNINSTALL event? (before answering that it is not possible, please try to uninstall NQ Mobile Security and see what happens. On my Android 2.3.4 it shows a nice screen saying that is not safe to go without a security app).
I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called
They must be exploiting some security flaw in Android. I will research it and see if I can get it fixed. Apps are not supposed to get control at uninstall time.
Thanks for pointing this out!
Is there a different way to intercept your application UNINSTALL event?
I sure hope not.
Opera Max is an app that does something similar - after being uninstalled opens a webpage.
How do they do this?
By using libevent, from native code, they watch /data/data/com.opera.max directory to be removed and then post good old action.VIEW broadcast when it happens.
Install their app, run it, and on rooted device from adb shell remove /data/data/com.opera.max directory
UPDATE: I created a sample app that shows how it works. BTW it doesn't work with recent (KitKat+ I think) Android versions: https://github.com/pelotasplus/ActionAfterUninstall
I'm pretty sure that they are monitoring the LogCat to intercept when the Activity Manager calls the PackageUninstaller. I think they kill the task and start their own Activity.
It's pretty clever but it's definitely exploiting a security hole in Android.
They are likely asking for a very critical permission that the user is granting them unknowingly. Look at the "Permissions" tab for this app (as of 6/15/2012): https://play.google.com/store/apps/details?id=com.nqmobile.antivirus20&hl=en.
The list of permissions this app gets is downright chilling. Among other things:
SYSTEM TOOLS RETRIEVE RUNNING APPS Allows the app to retrieve
information about currently and recently running tasks. Malicious apps
may discover private information about other apps.
CHANGE/INTERCEPT NETWORK SETTINGS AND TRAFFIC Allows the app to change network settings
and to intercept and inspect all network traffic, for example to
change the proxy and port of any APN. Malicious apps may monitor,
redirect, or modify network packets without your knowledge.
PREVENT TABLET FROM SLEEPING PREVENT PHONE FROM SLEEPING Allows the app to
prevent the tablet from going to sleep. Allows the app to prevent the
phone from going to sleep.
CHANGE YOUR UI SETTINGS Allows the app to
change the current configuration, such as the locale or overall font
size.
MODIFY GLOBAL SYSTEM SETTINGS Allows the app to modify the
system's settings data. Malicious apps may corrupt your system's
configuration.
DISPLAY SYSTEM-LEVEL ALERTS Allows the app to show
system alert windows. Malicious apps may take over the entire screen.
MOUNT AND UNMOUNT FILESYSTEMS Allows the app to mount and unmount
filesystems for removable storage.
CHANGE NETWORK CONNECTIVITY Allows
the app to change the state of network connectivity.
CHANGE WI-FI STATE Allows the app to connect to and disconnect from Wi-Fi access
points, and to make changes to configured Wi-Fi networks.
-- Update --
I also found that the Android Package Manager pretty much just deletes a package if it is asked to do so. The only check it performs prior to doing so is whether the package being deleted is currently registered as having an active device admin:
try {
if (dpm != null && dpm.packageHasActiveAdmins(packageName)) {
Slog.w(TAG, "Not removing package " + packageName + ": has active device admin");
return PackageManager.DELETE_FAILED_DEVICE_POLICY_MANAGER;
}
} catch (RemoteException e) {
}
See line 6900 in PackageManagerService in the AOSP source here.
For this, the application must be explicitly registered as a device admin by the user. See notes on device administration here: http://developer.android.com/training/enterprise/device-management-policy.html.
As per https://stackoverflow.com/a/26829978/1317564, here is some example code that does it: https://github.com/zzljob/android-uninstall-feedback/blob/master/library/jni/feedback-uninstall.c. This won't actually stop the uninstall from taking place, but does provide a way to catch it and take some action. I'm honestly surprised that this works in Android and the team may have plugged the gap in recent releases.