Develop Reference

How to determine the needed permission for my app

I'd like to know if there is any way to determine the permissions my app needs.
There is a similar question here:How do I determine why my Android app requires certain permissions?
But the answer states, that you basically have to find out yourself and I can't believe this.
Is there really no way to tell Eclipse to take a look at my code and determine the needed permissions or something like this? There should be no problem to automate this.
Or is there a way to test permissions on a device. When I install my app on my local device I'm not asked for any permissions.
Any help is really welcome.

This should work:
boolean crashes = true
while (crashes) {
ReadLogCat()
AddPermissionFoundMissingAccordingToLogCat()
crashes = TryAgain()
}
PS: This is pseudocode ;)
PPS: You didn't copy this to Eclipse, did you? Just kiddin' ;)

Believe it.
The app crashes and tells you the reason why: it expected some permission(s) declared in its manifest file.
It normally tells you in 2 ways: in a Dialog (FC Dialog) and in the LogCat.

You have to define permissions according to what your apps doing, if it's accessing the internet, it needs permission to do it. If it wants to locate you via GPS, it needs a permission for it and no you can't automate it, not officially anyway.
Think your app as a virtual child, you need to grant it permission to do stuff or else it won't do anything. So you have to pretty much decide yourself.
But you need not worry, if you're missing a permission, the log will let you know which one it is.

well i won't consider this as official solution for this problem
usually when i miss any permission in my application say i am using internet connectivity or get tasks but i didn't declared them in manifest
when i run my app i get it in log cat saying internet permission and get tasks permissions are required for this app to run
hope that answer your question

Is there really no way to tell Eclipse to take a look at my code and determine the needed permissions or something like this?
If you have a test suite that adequately tests your app, running the test suite will tell you the needed permissions, because your tests will crash if you do not have them.
Or is there a way to test permissions on a device. When I install my app on my local device I'm not asked for any permissions.
The permissions that you see on install are based on your <uses-permission> elements in your manifest, not some analysis of the app beyond that. Hence, this will not help you. That being said, installing your app by any means other than adb, such as downloading the app from a Web server, will pop up the permissions dialog, so you can see what prospective users will see at install time.

Can I use android app to track user activities?

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.

How do I determine why my Android app requires certain permissions?

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.

Reading ActivityManager-logs on a Jelly Bean device?

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.

Android application must not run on rooted devices

I'm writing an application that must not run on rooted devices. I want to store some secure data and which is possible only on non-rooted devices as nobody can access files in /data/data/package-name.
Does anyone know:
1) Is it possible to prevent the installation of an application on rooted devices? I read something about the "copy-protection mechanism" of Android Market. This feature seems to be outdated and replaced by the licensing feature. However, licensing is only possible for paid application and mine is free...
2) Is it possible to check programmatically whether a device is rooted or not? If it would be possible to do so I could simply stop the application if the device is rooted.
Any help regarding this topic is appreciated!

Execute
Runtime.getRuntime().exec("su");
and check the result code.
In other words, if you can exec su, then you have root access. it doesn't matter if the user allows or denies it, you have your answer.

I think your approach is a bit flawed. First of all, the user can first install your application and data, then "root" the device (even if rooting wipes the data, one can make the backup first). Next, the general rule is that whatever is in user's hands is not yours anymore. The hacker will find a way to get to your data sooner or later.
If you care about secure data, don't put it to device. As Android is net-centric device (yes, I know, that's subjective, but it was initially developed and positioned as such), accessing the data online is not uncommon.

What I would say is to run su and then check the output. If the user allows your app to have root, then use root to uninstall your own application (one way might be to place a script into init.d and then force a reboot).
If the user DOES NOT allow your app to run as root, then:
They DENIED your app permissions.
They are not rooted.
Now, denying permissions (and rooted) means that they have some sort of SUPERUSER management app, and that's where this next part comes in.
I would then proceed to use PackageManager to retrieve a list of all packages and then check them against the handful SuperUser management apps available, namely the ones by Koush, ChainsDD, and Chainfire
The relevant package names are:
com.noshufou.android.su
eu.chainfire.supersu
com.koushikdutta.superuser

Use those methods which will help you check for root
public static boolean findBinary(String binaryName) {
boolean found = false;
if (!found) {
String[] places = { "/sbin/", "/system/bin/", "/system/xbin/",
"/data/local/xbin/", "/data/local/bin/",
"/system/sd/xbin/", "/system/bin/failsafe/", "/data/local/" };
for (String where : places) {
if (new File(where + binaryName).exists()) {
found = true;
break;
}
}
}
return found;
}
private static boolean isRooted() {
return findBinary("su");
}
Now try to check whether the device is rooted.
if (isRooted() == true){
//Do something to prevent run this app on the device
}
else{
//Do nothing and run app normally
}
For example you can force stop the app if the device is rooted

If you are trying to protect data for the user, it's their business to worry about other apps.
If you are trying to protect data from the user, what business do you have putting it on their device?
To answer your question, they are in control of the machine so expect them to be able to trap any call to an API checking 'Is this rooted?' and lie to you. Instead, encrypt the data on the client with a key known to the client, but make it non-obvious where and how you are doing it. Generally make things annoying for whoever is looking.
Enjoy the ensuing game of whack-a-mole. Every time someone cracks into it, you'll make a better fix, they'll make a better crack, and all along the way you will be raising the barrier for cracking it.
Don't fight against freedom - why should you turn away customers with free devices anyway? - instead, if you want a particular outcome, make it so Bother To Get Data > Value Of Getting Data. Then it won't happen. If you truly must have fool-proof security, keep the data server-side.

I believe that one of the 'drawbacks' of the traditional copy protection was that it did not allow the application to be installed on rooted devices, but it also has its own share of problems and will be deprecated soon.
As for client-side checks, you simply cannot rely on a programmatic approach to detect if you're running on a rooted device or not -- anything that is in client-side code can and will be hacked and removed. You'd be surprised at how easy it is to modify even Proguard-obfuscated code. At best, you force the hacker to spend a few hours or days to edit the code and recompile. This is security through obscurity, and not a viable protection mechanism.

1) no. how would you deny installation? why would a rooted device deny installation of something the user wants to install on the fs? being the whole point of rooting that you can make the device do basically whatever.
2) no. not for your purposes. you can check if you can gain root for your application through the usual methods. so you can make a check for a positive but you cannot prove programmatically that it is not rooted, from within your app.
also, what you are asking if you can make perfect copy protection drm system - you might also be missing the point that the user can alter your application, removing your root check. if you have a checksum/crc check of some kind, the user can fake the result of that as well.