Topic: AppOps

[muntashirakon]

Topic: AppOps

[MuntashirAkon]

That would be a good idea!

Implemented. Default app ops will be shown by default, you have to use the corresponding option to toggle the list. This option will be stored in the app preferences.

[fabianski7]

thank you!

[MuntashirAkon]

The current idea is to use a hybrid method: Parsing appops.xml for fetching Op information and setting informatioon via appops util. However, extactly when this xml file is modified is a question.

[MuntashirAkon]

On appops.xml

Latest appops.xml has the following format: (This DTD is made by me and by no means perfect, has compatibility issues)

<!DOCTYPE app-ops [

<!ELEMENT app-ops (uid|pkg)*>
<!ATTLIST app-ops v CDATA #IMPLIED>

<!ELEMENT uid (op)*>
<!ATTLIST uid n CDATA #REQUIRED>

<!ELEMENT pkg (uid)*>
<!ATTLIST pkg n CDATA #REQUIRED>

<!ELEMENT uid (op)*>
<!ATTLIST uid
n CDATA #REQUIRED
p CDATA #IMPLIED>

<!ELEMENT op (st)*>
<!ATTLIST op
n CDATA #REQUIRED
m CDATA #REQUIRED>

<!ELEMENT st EMPTY>
<!ATTLIST st
n CDATA #REQUIRED
t CDATA #IMPLIED
r CDATA #IMPLIED
d CDATA #IMPLIED
pp CDATA #IMPLIED
pu CDATA #IMPLIED>

]>

The instructions below follows the exact order given above:

• app-ops: The root element. It can contain any number of pkg or package uid
  • v: (optional, integer) The version number (default: NO_VERSION or -1)
• pkg: Stores package info. It can contain any number of uid
  • n: (required, string) Name of the package
• Package uid: Stores package or packages info
  • n: (required, integer) The user ID
• uid: The package user ID. It can contain any number of op
  • n: (required, integer) The user ID
  • p: (optional, boolean) Is the app is a private/system app
• op: The operation, can contain st or nothing at all
  • n: (required, integer) The op name in integer, ie. AppOpsManager.OP_*
  • m: (required, integer) The op mode, ie. AppOpsManager.MODE_*
• st: State of operation: whether the operation is accessed, rejected or running
  • n: (required, long) Key containing flags and uid
  • t: (optional, long) Access time (default: 0)
  • r: (optional, long) Reject time (default: 0)
  • d: (optional, long) Access duration (default: 0)
  • pp: (optional, string) Proxy package name
  • pu: (optional, integer) Proxy package uid

This definition can be found at com.android.server.appop.AppOpsService.java.

EDIT: The tag st is probably not available in old version of Android. But this isn't a problem since we're only interested in getting Ops.

[MuntashirAkon]

Parsing appops to get app ops

appops tool can be accessed via adb or using root. We'll parse the value of this command in order to get the op values we need.

Relevant command:

appops get <package-name> [<op-name>]

Parsing the command: (stdout only)

1. Empty output: Denotes an error. The exit values should be less than 0.
2. No operations.: The app has no operation and exit value is 0. There may be another line describing Default mode: <mode-name>) depending on whether <op-name> is given
3. The output containing op name and mode name with exit value 0. Each line has the following format: (Conventional shell format)

   [Uid mode: ]<op-name>: <mode-name>[; time=<time> ago][; rejectTime=<time> ago][ (running)][; duration=<time>]

Where:

• <op-name> is the name of the op. Currently, there's no way to convert op-name to op value without implementing some new function (a working example is com.android.server.appop.AppOpsService.Shell#strOpToOp(String, PrintWriter)) but the opposite conversion can be done via android.app.AppOpsManager#opToName(int).
• <mode-name> is the name of the mode. Like <op-name> there's no way to convert mode names to mode values by default but possible through implementing some new function (a working example is com.android.server.appop.AppOpsService.Shell#strModeToMode(String, PrintWriter)) but the opposite conversion can be done via android.app.AppOpsManager#modeToName(int)
• <time> is a formatted time and described in android.util.TimeUtils#formatDurationLocked(long, 0). The format is given in summary below: (regex format)

  ^(\s*0|(\+|-)(\d+d)?(\d{1,2}h)?(\d{1,2}m)?(\d{1,2}s)?\d{1,3}ms)$

  Here, d=days, h=hours, m=minutes, s=seconds and ms=milliseconds.

EDIT: Regex to parse a single line:

(?:Uid mode: )?(\w+): (\w+)(?:; time=(?:\s*0|([+\-])(\d+d)?(\d{1,2}h)?(\d{1,2}m)?(\d{1,2}s)?(\d{1,3}m))s ago)?(?:; rejectTime=(?:\s*0|([+\-])(\d+d)?(\d{1,2}h)?(\d{1,2}m)?(\d{1,2}s)?(\d{1,3}m))s ago)?( \(running\))?(?:; duration=(?:\s*0|([+\-])(\d+d)?(\d{1,2}h)?(\d{1,2}m)?(\d{1,2}s)?(\d{1,3}m))s)?

Capture groups:

• 1: op-name
• 2: mode-name
• 3-8: time
• 9-14: rejectTime
• 15: running
• 16-21: duration

[MuntashirAkon]

Using appops to set app ops

Relevant command: (definition of these names are described above)

appops set <package-name> <op-name> <mode-name>

Parsing the command: (stderr only)

1. Empty output: Denotes success or failure. If success, the exit value is 0, otherwise less than 0.
2. Error: Package name not specified.: This output with exit value -1 denotes no package name was specified
3. Error: Operation not specified.: This output with exit value -1 denotes no operation was specified
4. Error: No UID for <package-name> in user <user-id>: This output with exit value -1 denotes that the package name doesn't exist for the given user
5. Error: Mode not specified.: This output with exit value -1 denotes no mode was specified
6. Error: Mode <mode-name> is not valid: This output with exit value -1 denotes that the given mode was invalid

Beaware that the exit status 0 does not necessarily mean that the mode is applied. You need to run appops get <package-name> <op-name> (which gives results like in the previous discussion) and parse the output to make sure.

[MuntashirAkon]

Code reference to the above tutorial: com.android.server.appop.AppOpsService.Shell#onShellCommand(Shell, String)

[MuntashirAkon]

Creating AppOpsService class

com.android.server.appop.AppOpsService is a special class which extends com.android.internal.app.IAppOpsService.Stub (it's there but not included in the source). But we don't need all of the features. In fact, we'll do a simple class with only a few public methods. An example interface is given below:

package io.github.muntashirakon.AppManager.appops;

interface IAppOpsService {
    int checkOperation(int code, int uid, String packageName);
    List<AppOpsManager.PackageOps> getOpsForPackage(int uid, String packageName, int[] ops);
    void setMode(int code, int uid, String packageName, int mode);
    void resetAllModes(int reqUserId, String reqPackageName);
}

As seen in the last method, it is probably needed to parse user id as well but currently we'll only use the user ID 0. To get user IDs, we can simply parse /data/system/users/userslist.xml.

EDIT: Detailed implementation is added in e3df598.

[fabianski7]

Maybe I'm wrong, but that function seems to be bugged.

Look at that comparison:

These are the permissions that the Look4Sat application needs, according to App Opps (Shizuku working mode):

Screenshot

AppManager shows a completely different list, with many permissions that the app does not use or request:

Screenshot 1 2 3

[MuntashirAkon]

AppManager shows a completely different list, with many permissions that the app does not use or request:

Obviously. Android allows many operations by default and you want to disable them too, not just the one's that has been modified. For instance, if requested, all apps can RUN_IN_BACKGROUND anytime they want either using the system alarm service or broadcast receiver or even a constantly running high priority service that the OS won't be killing even in battery saving mode. Even my list is not perfect as there might be other operations that might be allowed by default which I'm not currently aware of (every vendor modifies that section a lot).

[fabianski7]

your explanation about the RUN_IN_BACKGROUND permission makes sense, but there are others the application won't use, like the camera one. In the android settings, it only lists the location as needed.

Having that many permissions to manage for each app generates additional work for the user that is not needed.

[MuntashirAkon]

there are others the application won't use

Excuse me, but who told you that these operations won't be utilised by the app? I mean, do you trust the developer? The developer, maybe, will supply you an update one day which utilises this feature or they could just send sensitive info collected using these already allowed operations as a crash report or something.

Having that many permissions to manage for each app generates additional work for the user that is not needed.

Most permissions are now just wrappers around operations. Then there are normal permissions that are granted by default and, hence, is not listed in the permissions section in Settings. Hence, you'll never know unless you cared to look at the whole manifest (not just uses-permissions or permissions as they can be specific to activity as well).

What I can do, however, is that include a filter button in the app ops menu where you can only filter currently allowed app ops and another to exclude already denied app ops. Nothing more than these. I don't want users get the illusion that denying only these permissions will make that app safe to use.

[fabianski7]

The developer, maybe, will supply you an update one day which utilises this feature or they could just send sensitive info collected using these already allowed operations as a crash report or something.

In the case I showed (about the camera), if the developer updates the app asking for this new permission, the user will receive a notification when opening the app asking whether or not this new permission is confirmed.

About the other permissions that android doesn't ask the user for, what you said really makes sense.

What I can do, however, is that include a filter button in the app ops menu where you can only filter currently allowed app ops and another to exclude already denied app ops

That would be a good idea!