Some thoughts about AppOpsManager and 4.4

Android 4.3 introduced a new hidden feature: AppOps.
Android 4.4 improved this feature, but it is still hidden.

Someone talks about it as an "App Permission Manager".
We have very few information about it, but it is a lot more than a simple permission manager.

Currently there is no action to launch it.

You can see it in Manifest.xml:
https://github.com/android/platform_packages_apps_settings/blob/master/AndroidManifest.xml#L802

A simple way could be this:
 Intent intent = new Intent("android.settings.SETTINGS");
        intent.putExtra(PreferenceActivity.EXTRA_SHOW_FRAGMENT,
                "com.android.settings.applications.AppOpsSummary");
 startActivity(intent);


Here you can find info about apps which use location-permissions, contact-permissions, message-permissions....
In the list, for each app you can see the last use of this permission, and if you click on an item, you can see a full detail.

Pay attention!
You can disable permissions, but this can break your app!
Don't do it!!
Currently the devs can't check if a permission was removed.

With API 19 Google introduced new feature in 4.4. with this class: AppOpsManager.

Pay attention to comments inside it:
  This API is not generally intended for third party application developers; most
  features are only available to system applicatins.
I suggest you not use this class!
I don't know much about this class, however just to try...... 
    //Don't use this code! 
    AppOpsManager mAppOps = (AppOpsManager) getSystemService(Context.APP_OPS_SERVICE);

    PackageManager mPm = getPackageManager();
    PackageInfo mPackageInfo=null;
    try {
         mPackageInfo = mPm.getPackageInfo(packageName,
                    PackageManager.GET_DISABLED_COMPONENTS |
                            PackageManager.GET_UNINSTALLED_PACKAGES);
    } catch (Exception e) {//only for test!}

    int permission= mAppOps.noteOp(AppOpsManager.OPSTR_FINE_LOCATION,
                                 mPackageInfo.applicationInfo.uid,
                                 packageName);


You can get code from GitHub:

Comments

Post a Comment

Popular posts from this blog

AntiPattern: freezing a UI with Broadcast Receiver

Image
The worst thing that can happen to your app's responsiveness is an "Application Not Responding" (ANR) dialog. In android guidelines we can read: In any situation in which your app performs a potentially lengthy operation, you should not perform the work on the UI thread , but instead create a worker thread and do most of the work there. This keeps the UI thread (which drives the user interface event loop) running and prevents the system from concluding that your code has frozen. It's very important to understand what is Main Thread . When an Android app is launched, the system creates a thread for the application which is known as the main thread. If you run up any project under the debugger in Eclipse you will see the main thread. If your app ties up the UI thread for more than 5 seconds or a BroadcastReceiver does not complete within 10 seconds, Android will throw up the Application Not Responding (ANR) dialog which gives the user the opportunity t
Read more

NotificationListenerService and kitkat

Image
Android 4.3 (API 18) introduced NotificationListenerService . I published a post about it a few months ago. Android 4.4 (API 19) added new features, and now we can have a lot of extra info about a notification (before we need to use reflection to read some info). As in 4.3,to use the NotificationListenerService we have to extend the NotificationListenerService and implement onNotificationPosted() and onNotificationRemoved() methods public class SimpleKitkatNotificationListener extends NotificationListenerService { @Override public void onNotificationPosted(StatusBarNotification sbn) { //.............. } @Override public void onNotificationRemoved(StatusBarNotification sbn) { //.............. } } Then we must declare the service in the manifest file with the BIND_NOTIFICATION_LISTENER_SERVICE permission and include an intent filter with the SERVICE_INTERFACE action
Read more

How to centralize the support libraries dependencies in gradle

Working with multi-modules project, it is very useful to centralize the dependencies, especially the support libraries. A very good way is to separate gradle build files, defining something like: root --gradleScript ----dependencies.gradle --module1 ----build.gradle --build.gradle In gradleScript/dependecies.gradle : ext { //Version supportLibrary = '22.2.1' //Support Libraries dependencies supportDependencies = [ design : "com.android.support:design:${supportLibrary}", recyclerView : "com.android.support:recyclerview-v7:${supportLibrary}", cardView : "com.android.support:cardview-v7:${supportLibrary}", appCompat : "com.android.support:appcompat-v7:${supportLibrary}", supportAnnotation: "com.android.support:support-annotations:${supportLibrary}", ] } In the top level file build.gradle
Read more