Jelly Bean has removed the ability to read the logs of other apps (according to this I/O talk), which is a sensible security improvement. However, I need to read ActivityManager-logs for my app to work (to see which app is currently starting). To do this, I was using
private static final String clearLogcat = "logcat -c";
private static final String logcatCommand = "logcat ActivityManager:I *:S";
//...
which no longer works, as I can only read my own application's logs in Jelly Bean. Is there an alternative solution to finding out when another app is starting (apart from root)? I understand why we shouldn't be able to read other applications' logs (kind of - it should be the other developers' resposibility to make sure that no personal information is logged, not mine by being prevented from reading the log), but I don't understand why the ActivityManager, a framework class, is included in that policy...
Thanks,
Nick
There is an extensive discussion of this issue going on here. Unfortunately, it's "expected behavior" and as such won't be fixed. The only current solution (for reading the logs from within an application on JB and above) is to manually grant the permission to the app through adb:
adb shell pm grant <pkg> android.permission.READ_LOGS
A such-granted permission:
survives reboots
survives application updates (i.e. "adb install -r")
does not survive if the application was uninstalled and then installed
again
It's obvious that this isn't something that a normal user can be expected to do. A GUI-solution (where users can grant this permission from the Settingsmenu of their device) is promised by the Android team, but unfortunately the functionality was removed before the "fix" was implemented.
First of all, ActivityManager isn't an application... it's a class that makes up part of the Android application framework.
Second of all, if the Android team deliberately went out of their way to prevent this from working, then I doubt there is a security loophole around it. The fact is that third party applications should not have to rely on logcat logs in order to work properly. If you give some details about your reason for needing to read these logs, maybe we can help point you to a better solution.
Related
Note: This was originally posted on Android Enthusiasts Stack Exchange but is now moved here because it was found to be off-topic there
Kaspersky Safe Kids, a parental control app, has a feature where it would pop up every time it detects an event that the child was not meant to do (open an app, open anything related to its settings, search something banned on Google and Youtube -- interestingly enough, it doesn't work on other Chromium-based browsers). I've been trying to figure out how it can detect events for my own app, but the usual culprits like the permissions GET_TASKS and READ_LOGS are depreciated (I'm trying to target, and Kaspersky works on, Android 10+). For the actual overlay, I thought it used SYSTEM_ALERT_WINDOW, but in my own experiments in an emulator, when I revoked that permission, it was still able to pop up. So, how does it work, and what permissions do they (and I'm guessing other similar control and productivity apps) work?
The app is Device Admin, so that may play a role, but looking at the permissions a Device Admin has, none of them look like the permissions Kaspersky has.
EDIT: In the comments, Mike M. noted that the app uses Accessibility Services (don't know how I missed that), which makes sense as Accessibility allows you to do quite a lot, including showing your own UI. Coincidentally, a review on the app itself states that the process ends at random times (not sure which process though), probably because it was not whitelisted. I then took a look at its permissions and this one stood out: android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. This permission allows it to be whitelisted, so that power saving modes don't kill the background processes. For the accessibility itself, android.permission.BIND_ACCESSIBILITY_SERVICE is the permission used to grant it (for the record, you must use adb shell appops set com.kaspersky.safekids android.permission.BIND_ACCESSIBILITY_SERVICE [allow|ignore|deny], not adb shell pm [grant|revoke] com.kaspersky.safekids android.permission.BIND_ACCESSIBILITY_SERVICE (though the android may have to be replaced with Manifest) as BIND_ACCESSIBILITY_SERVICE is a signature permission. For completeness, for Admin, it's android.permission.BIND_DEVICE_ADMIN.
I was able to narrow down the exact permission used -- using ADB OTG (I didn't have a computer near me, so I used my spare Pixel) I did appops set com.kaspersky.safekids BIND_ACCESSIBILITY_SERVICE ignore (I belive deny would work too). Restarted it, and no more pop up. Changed the ignore to allow, then rebooted, and it worked again.
I wish to know is it possible to write an android app that when it runs at the background, it can track user activities?(Such as what other app did the user used, what phone number did user dial, the GPS location for user, etc) Cause I am not sure can a single android app react to other application, does anyone know the answer? Thanks
In the general case, no, you can't. And users would probably prefer it so.
Once this has been said, there are certain partial solutions. Sometimes the system is so helpful that it will publish Intents reflecting user actions: for example when the user uninstalls an app -- with the caveat that you don't get that intent on the app itself being uninstalled.
It used to be the case that before Jelly Bean (4.1) apps could read the log that other applications publish and try to extract info from there, but it was a cumbersome, error prone, ungrateful task. For example, the browser shows nothing when it navigates to a certain page. You may read the logs for a while with adb logcat to get a feeling of what was possible and what isn't. This action requires the relevant permission, which cannot be held by regular apps now.
Thanks to #WebnetMobile for the heads up about logs and to #CommonsWare for the link, see the comments below.
Yes you can.
You can look here for instance about phone info:
Track a phone call duration
or
http://www.anddev.org/video-tut_-_querying_and_displaying_the_calllog-t169.html
There is a way to let Android and users know you are using and accessing their data for them to determine if they will allow it.
I am unsure you can simply access any app, but in theory if you know how to read the saved files that might be possible.
For instance Runtime.getRuntime().exec("ls -l /proc"); will get you the "proc" root folder with lots of data you might need there. This might have been changed, I am not sure, and I also don't know what you need.
Perhaps to get running process try:
public static boolean getApplications(final Context context) {
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
List<RunningTaskInfo> tasks = am.getRunningTasks(1);
}
For this to work you should include this in your AndroidManifest.xml
<uses-permission android:name="android.permission.GET_TASKS" />
See more about it: http://developer.android.com/reference/android/app/ActivityManager.html#getRunningAppProcesses%28%29
You certainly could but I think reporting that data back to you, unbeknownst to the user, via the internet, would be considered spyware and almost certainly illegal in most jurisdictions.
Fortunately spying users at that level should not be possible. Certain features can be achieved with abusing bugs in android which sooner than later will be fixed. I see absolutely no reason for you to know what number I am calling and where I've been lately. It's basically none of your business.
Let's say I have taken over development of an Android app, and my boss asks me why our app requires certain permissions to be displayed to users who buy the app on the Android Market.
Are there any tools or tricks I can use to determine what code triggers each permission, so I can figure out why our app functionally needs those permissions? In particular, I am interested in these permissions:
Phone Calls - Read phone status and identity
System Tools - Retrieve running applications - Allows app to retrieve information about currently and recently running tasks, May allow malicious apps to discover private information about other apps.
The app is a GPS tracking app, and it's not obvious why this permission might be needed.
It would also be helpful to get any tips on why this permission might be needed, even if you can't tell me how to directly analyze the code to find out.
Here is how I would track these down.
Step 1 - Find the manifest permissions declared in your AndroidManifest.xml
Basically everything inside the <uses-permission /> tags e.g.:
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
Step 2 - Search developer.android.com for classes that use these permissions
Let's take the case of READ_PHONE_STATE, the goal is to find which packages require this permission. A simple search on the dev portal for "READ_PHONE_STATE" starts our search, we are looking for classes here, in the top 5 search results I see the following classes:
TelephonyManager
PhoneStateListener
Click on the classes and get their package names:
android.telephony.TelephonyManager
android.telephony.PhoneStateListener
Step 3 Find classes in your project that import these packages
A simple grep will do, or a Ctrl-H in eclipse, File Search -> Containing text
Step 4 Comment out the import and see what breaks
These are likely candidates for why the permission is required. Confirm the methods in question by looking at the dev portal to validate that the permission is indeed required by that method.
Finally you should be able to tell your boss, READ_PHONE_STATE is required because we call function XYZ which gives us UVW.
Remove a permission and see where the app fails. The answer will be in the logcat output.
That's not an ideal solution though, since you might not know what you need to do in the app to trigger that permission.
I suspect "Read phone status and identity" means that the app is using the device IMEI or similar identifying information to uniquely identify the device to ensure that the app is only being run on a registered device. Or it might just be used as a sort of cookie to track the owner. Look for that code. And remove it, because that's the wrong way to do it. If you need to identify a specific android device, use ANDROID_ID from the Settings.Secure class. http://developer.android.com/reference/android/provider/Settings.Secure.html
As for "Retrieve running applications", I find that one somewhat suspicious. A very common way to implement GPS tracking is to launch a separate service in its own process. This way, if the app should crash, the service will keep going and can be re-attached. In this case, it's possible that the app is using the "Retrieve running applications" to identify and kill the service process. But if so, it's a clumsy way to do it.
With the latest build tools, you can run lint check which will highlight for you all the android SDK method calls which are requiring permissions.
See announcement here http://android-developers.blogspot.com/2015/07/get-your-hands-on-android-studio-13.html and documentation here https://developer.android.com/tools/debugging/annotations.html#permissions .
This is based on android annotations and after some adoption time 3rd party libraries can integrate permission annotations also
The answer for your boss is "because certain API features/calls/methods we use in our app require calee to hold certain permissions. It is for security reasons, and that's the way Android works". As for mentioned permissions - you have to check the code to see if these permissions are really required. Read phone status and identity may indicate your app try to get IMEI or something like this to uniquely identify device. Retrieve running applications - see no reason for GPS tracking app to hold this. But maybe you use 3rd party lib/code that uses this.
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.
I see a couple threads on this, but none really speak to what I would like to do. I am trying to write an application that will deny another application the ability to connect to the internet (IE Firewall). Based on algorithms I am creating it will determine that application as being malicious. The app would be on a rooted phone. I would then like to either
Strip all permissions from the Application
Deny it specific permissions (Internet Access)
Force Uninstall that application.
I know there are several programs already out there, but I would like to code this myself :]]
With that being said could anyone point me in the right direction?
Thank you!
EDIT: So I have found this:
public static void killRunningPackage(final Context context, String packageName)
{
ActivityManager activityManager = (ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE);
activityManager.killBackgroundProcesses(packageName);
}
What argument do I pass in for a context? I looked at contexts online but I didnt really understand them
Build Perspective
Even with a rooted phone, because this is handled by the frameworks, I highly doubt that you can achieve something like this.
Specifically unless you have the source and can compile the source of a new phone, you cannot do this.
SDK Perspective
Also another thing about this is you can't "strip" an application of its permissions BECAUSE its in the Manifest.xml which gets embedded into the .apk of an application, which is a binary and is registered with the PackageManager.
This is far beyond the scope of the SDK.
What you CAN do is kill an application if it isn't to your liking. The PackageManager would be your best option, however; that is as far as you can go.
Update
Check this out:
http://android.amberfog.com/?p=98