I'm trying to access the Usage_Stats_Service in lollipop through this :
final UsageStatsManager usageStatsManager=(UsageStatsManager)this.getSystemService(Context.USAGE_STATS_SERVICE);
I can go to the Context class and see how this constant exist but Android Studio keeps saying that it is not a valid constant.
I have tried to use the literal string too but it seems getSystemService has a constraint to only accept #ServiceName constants.
I have spent almost 2 hours into this without finding out what is hapenning. Any help is welcomed.
Android Studio keeps saying that it is not a valid constant.
It isn't a publicly available constant because USAGE_STAT_SERVICE is hidden using the #hide annotation in the source code. This is supported by the lack of USAGE_STAT_SERVICE in the documentation.
getSystemService has a constraint to only accept #ServiceName
constants.
This is due to "attribute inspection" and should not affect compilation. It can be turned off.
I've also successfully gotten an instance of UsageManagerService using a direct string.
UsageStatsManager manager = (UsageStatsManager) getSystemService("usagestats");
Additionally, it is worth noting that the permission required,
android.permission.PACKAGE_USAGE_STATS
is simply flagged by Studio as a permission that can't be granted (technically true based on the documentation) so Studio at this time, does not know about "special" permissions such as these.
Usage Access can be granted in
Settings > Security > Apps with usage access
Related
I have encapsulated permission check into utility method and now I am receiving
Call requires permission which may be rejected by user: code should
explicitly check to see if permission is available (with
checkPermission) or explicitly handle a potential
SecurityException
error.
Like this:
Is it possible to smart control this error, for example, by adding some annotation (not just completely disable checking)?
Is it possible to smart control this error
This is not error per se but warning generated by static code analyser, most likely by bundled Lint. If that is so, you can suppress it by using #SuppressWarnings() annotation. See official docs on that: Suppressing Lint Warnings
I'm preparing my app to target Android 6.0 Marshmallow.
When setting the target api to 23, the app immediately crashes upon launch. There is no useful information in the logcat output. (It gives a "Requested window does not exist" IllegalStateException, but still, nothing actually useful like class name or line number.)
This is fine (not really), I eventually narrowed it down to my launch activity where I get the user's device IMEI code (TelephonyManager.getDeviceId()). There needs to be a runtime permission request added. I understand this.
However, the app has something like 60 classes across numerous activities, so there is a lot of code to sort through. How can I possibly search through the code to find all of the cases where runtime permissions are required?
Surely Google must have thought of an easy way for developers to track down where the permission requests are required? I thought perhaps commenting out the permissions in the manifest would trigger a compile-time error where the permissions are used, or something of the sort, but nope.
My current method is by going through the app and when it crashes, do like the above with my launch activity and very slowly narrow down where it is. This is extremely inefficient and time-consuming. I'm tempted to just leave it at API 22 for now, but I know sooner or later this will have to be done.
Delete all AndroidManifest.xml permission.
Analyze -> Run Inspection by Name ->Constant and Resource Type Mismatches in Android Studio.
You can detect permission.
But this detection is not perfect...
Because this detects only method that contains this xmls files.
https://android.googlesource.com/platform/tools/adt/idea/+/master/android/annotations/android
https://android.googlesource.com/platform/tools/adt/idea/+/master/android/annotations/android/accounts/annotations.xml#118
What worked for me is this :
Analyze -> Run Inspection by Name -> Missing Permissions
There are many Android Permissions and generally each permission is mapped to a linux group id in AOSP and that is how the access control mechanism works. The mapping can be seen from the platform.xml file. However all the permissions are not mapped to a group id, there are many permissions whose mapping is missing from platform.xml file.
Like FLASHLIGHT, SET_ORIENTATION, SET_WALLPAPER, READ_SMS, SEND_SMS and so on. I'm curious to know how the systems works for these permissions.
Thanks in advance!
The system uses the platform defined permissions for some kernel GIDs, such as for the log or radio. But, not all Android permissions are used to lump packages into assigned group IDs. Some are enforced by by the framework before you can start components, others are checked at runtime. They are typically checked within the framework service code running within a process which has privileges to do what you are requesting. Though that's not necessarily a requirement. In fact, you can even define and enforce your own permissions. The calls in use are checkCallingPermission() and enforceCallingPermission(), or one of their variants. These are typically used over Binder type service calls, though not necessarily. Here are some additional details you may find helpful: http://bit.ly/1k9vGM1
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 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.