App Ops tab is empty on some devices

[muntashirakon]

App Ops tab is empty on some devices

[nerd190]

All is working perfectly! well done buddy!!!
So... does that mean that OnePlus use IFW component blocking rather than AppOps for certain apps? i.e Google Play Services. ???

I'll give you the pleasure of closing this issue! "ITS NOW FIXED!" Thank you! :D

[MuntashirAkon]

AppOps are generated directly using root, so no permission is required. But it might have some compatibility issues. Using shell/terminal run this command:

appops get io.github.muntashirakon.AppManager

It should have the following output:

VIBRATE: allow; time=+5d10h42m0s640ms ago; duration=+4s523ms
READ_CLIPBOARD: allow; time=+5d10h42m8s852ms ago
WRITE_CLIPBOARD: allow; time=+5d10h42m2s587ms ago
GET_USAGE_STATS: allow; time=+18h28m13s314ms ago
TOAST_WINDOW: allow; time=+5d12h45m26s263ms ago; duration=+3s766ms

[nerd190]

stdout:

VIBRATE: allow; time=+2h17m36s572ms ago; duration=+13ms
WRITE_CLIPBOARD: allow; time=+2h17m35s243ms ago
GET_USAGE_STATS: allow; time=+2h17m47s958ms ago
TOAST_WINDOW: allow; time=+4h58m44s885ms ago; duration=+3s990ms
READ_EXTERNAL_STORAGE: allow; time=+2h1m57s599ms ago
WRITE_EXTERNAL_STORAGE: allow; time=+2h1m57s599ms ago

[MuntashirAkon]

The output is perfectly fine. Displaying app ops requires some time (2-3 seconds even on the fastest phone). Have you tried using swiping from top (swipe to refersh) and waiting until the progressbar went away? If you have and the problem is still there, I'll consider this to be a bug.

[nerd190]

yes I pull to refresh and wait, after one second progress bar is finished, it says "no app operations", I then wait a few more seconds, still nothing, I repeat this again a few times on different apps, same again, no app ops.
Thank you!!!

[MuntashirAkon]

This is probably caused by some error while parsing the output. Do you have adb installed on your computer? If you have, I can send you an app with some logging capabilites.

[nerd190]

Yes I have a PC, a terribly old, 32-bit laptop with an atom-cpu and 1GB RAM! :'(
OS: Windows 7 / Lubuntu (dual-boot).
Not sure if it will run it?... but willing to try!!!

[MuntashirAkon]

Not sure if it will run it?... but willing to try!!!

I should probably save logs to a file in the external storage then. (I used to have an HP Pentium 3 laptop with 512MB RAM and I used it upto 2015!)

[MuntashirAkon]

Try this app. After installing the app, open any app's app ops tab and wait a second or two. In the meantime the log file will be created at /sdcard/Android/data/io.github.muntashirakon.AppManager/cache/appops_log.txt. Send me this log file.
AppManager_v2.5.4 (194).apk.zip

[nerd190]

great idea making a debug build for me! thank you!
I installed, opened the first app (AdAway, from Fdroid), navigated to AppOps, nothing, so I pull to refresh, nothing still, so I try the same with another app (Another Monitor, from Fdroid), again I pull to refresh and wait.
The log:

[COARSE_LOCATION: allow, READ_EXTERNAL_STORAGE: allow; time=+9h32m8s987ms ago, WRITE_EXTERNAL_STORAGE: allow; time=+9h32m9s44ms ago, READ_CALENDAR: allow, WRITE_CALENDAR: allow, CALL_PHONE: allow, PROCESS_OUTGOING_CALLS: allow, READ_CALL_LOG: allow, ANSWER_PHONE_CALLS: allow, WRITE_CALL_LOG: allow, ADD_VOICEMAIL: allow, USE_SIP: allow, ACCEPT_HANDOVER: allow]

Anything that I can possibly do to help I will try! (not as I am really desperate, but because I LOVE this project! you put so much time in to this for us, so should we! more than glad to help out however I can) Thank you so much!

[MuntashirAkon]

It seems there was an error while parsing the data. Try the attached app again. Only use Another Monitor this time so that I can understand the difference. This time the logs should be different at the end.
AppManager_v2.5.4 (195).apk.zip

[nerd190]

Thank you!

Just opened Another Monitor only.

We have a denial for MANAGE_IPSEC_TUNNELS

[COARSE_LOCATION: allow, READ_EXTERNAL_STORAGE: allow; time=+13h40m33s816ms ago, WRITE_EXTERNAL_STORAGE: allow; time=+13h40m33s871ms ago, READ_CALENDAR: allow, WRITE_CALENDAR: allow, CALL_PHONE: allow, PROCESS_OUTGOING_CALLS: allow, READ_CALL_LOG: allow, ANSWER_PHONE_CALLS: allow, WRITE_CALL_LOG: allow, ADD_VOICEMAIL: allow, USE_SIP: allow, ACCEPT_HANDOVER: allow, READ_PHONE_NUMBERS: allow, GET_USAGE_STATS: default, GET_ACCOUNTS: allow, CAMERA: allow, READ_SMS: allow, WRITE_SMS: ignore, RECEIVE_SMS: allow, RECEIVE_MMS: allow, RECEIVE_WAP_PUSH: allow, SEND_SMS: allow, READ_CELL_BROADCASTS: allow, BODY_SENSORS: allow, USE_FINGERPRINT: allow, READ_CONTACTS: allow, WRITE_CONTACTS: allow, RECORD_AUDIO: allow, WRITE_SETTINGS: default, WAKE_LOCK: allow, TURN_ON_SCREEN: allow, REQUEST_INSTALL_PACKAGES: default, REQUEST_DELETE_PACKAGES: allow, CHANGE_WIFI_STATE: allow, BIND_ACCESSIBILITY_SERVICE: allow, RUN_IN_BACKGROUND: allow, RUN_ANY_IN_BACKGROUND: allow, INSTANT_APP_START_FOREGROUND: default, START_FOREGROUND: allow; time=+1d3h29m21s914ms ago; duration=+57s606ms, SYSTEM_ALERT_WINDOW: default, ACCESS_NOTIFICATIONS: allow, READ_CLIPBOARD: allow, WRITE_CLIPBOARD: allow, TOAST_WINDOW: allow; time=+4d1h35m44s148ms ago; duration=+4s15ms, PICTURE_IN_PICTURE: allow, MANAGE_IPSEC_TUNNELS: deny]

appops_log.txt

[MuntashirAkon]

For some reasons READ_PHONE_NUMBERS op is not returning true result. Check if it's true by running the command like this one below:

appops get org.anothermonitor READ_PHONE_NUMBERS && echo success 

[nerd190]

stdout:

No operations.
Default mode: allow
success

[MuntashirAkon]

That's odd. Try this and send me the log as usual.
AppManager_v2.5.4 (197).apk.zip

[nerd190]

OK, navigated to Another Monitor - App Ops...
I see App Ops!!!

I didnt try switching any off yet, I closed the app and collected the log as usual.
This ones larger so I will just attach it (there are some failed ops still).
appops_log.txt
Thank you.

[MuntashirAkon]

Try something like this:

appops get org.anothermonitor READ_PHONE_STATE && echo success 

[MuntashirAkon]

And to test if the switch buttons actually work, first turn on/off any switch and then refresh to see if it still stays on/off.

[nerd190]

appops get org.anothermonitor READ_PHONE_STATE && echo success

stderr:

Error: Unknown operation string: READ_PHONE_STATE

Seems strange... makes me think OnePlus may of changed this value to something different for OxygenOS?
When I was going to write the bash script I told you about, I did ALOT of research and I do remember reading that vendors can have different values / values not found in other ROMs.
Could this be the case here possibly?
Is there anywhere on my system I can query available ops? or a command?
If not, fortunately they are open source so maybe we could search OnePlus's commits to find the changes to the relevent files?

[nerd190]

OK! the value is:

OP_READ_PHONE_STATE

appops get org.anothermonitor OP_READ_PHONE_STATE && echo success

No operations.
Default mode: allow
success

We are getting there buddy! :D

P.S I tried turning off all available app ops, rebooted to recovery, wiped cache & dalvik, rebooted and ALL the available app ops have persisted!

[MuntashirAkon]

appops get org.anothermonitor OP_READ_PHONE_STATE && echo success

It's better to use constants instead, I think. This should yield the same result:

appops get org.anothermonitor 51 && echo success

They seem to change constant names a lot.

[nerd190]

Yes, this will be the best way, to do it with constants.

appops get org.anothermonitor 51 && echo success

Works perfectly!
Only small downside I see, is that the values of these ops will then show as: 51
Rather than its title: OP_READ_PHONE_STATE
But to be honest... constants are the most "valuable" to see within the app for users, perhaps its possible to include both, view as:

1. Constant value (bold)
2. OP name (most popular) /
3. Known aliases (other)

Examples:

51 READ_PHONE_STATE / OP_READ_PHONE_STATE

51 (READ_PHONE_STATE / OP_READ_PHONE_STATE)

(51) READ_PHONE_STATE / OP_READ_PHONE_STATE

Something like shown above? this way provides all available info to the user?

[MuntashirAkon]

Suppose this way provides all available info to the user?

These constants are “hidden” from user apps and hidden APIs are not guaranteed to work due to restrictions that Android puts in each new API. And constants can be changed but not their value. So, my idea is to use the constants instead of their names and use the default name (ie. the name that appears here) instead of the custom name that the OS might be given or old names that appears in the old APIs.

And what exactly is the output of appops get org.anothermonitor 51 && echo success?

[nerd190]

appops get org.anothermonitor 51 && echo success

Works perfectly!
The link you kindly shared makes good reading!
I noticed a few things:

• Seems my op: OP_READ_PHONE_STATE is AOSP after all.
• MODE_FOREGROUND = 4 allows perms only IF user has app on foreground and then revokes them once the app is backgrounded! wow.

Most importantly though:

This API is not generally intended for third party application developers; most features are only available to system applications.

Whilst this is no problem at all for rooted users like me (systemless-ly with Magisk), "most features" will not be available to those who cannot install this to /system, although, I have installed system apps via ADB in the past, meaning root may not be essential, I'm guessing it may have to be a priviliged /priv/app though.
Anyway, when that time comes, to test this out, I will unroot my spare device and see exactly what is not available as to help find out!

[MuntashirAkon]

Anyway, when that time comes, to test this out, I will unroot my spare device and see exactly what is not available as to help find out!

I'm trying my best to provide most of the features to non-root users. I may consider solutions like Shizuku for non-root users but I think most of the users of this app may use Android 9 or 10 (nerds never use old version of any OS) where this solution doesn't work. Android even limits the reflection utility in 10 and 11. In 11, it's almost impossible to use hidden API to set anything (you can still get some of the information). If your target API is > 28, you'll need android.permission.UPDATE_APP_OPS_STATS which is only granted to system apps (probably requires the same signature as the ROM). The lost-cause-AppOps branch of this repo has a implementation using hidden API which is abandoned since it doesn't work properly: if I query using hidden API, some ops go missing in newer versions of Android (which I think is intentional) and I cannot set mode to any op since I don't have android.permission.UPDATE_APP_OPS_STATS permission.

My next solution was to use appops tool using op names. But apparently, many vendor choose to modify the constant names as well. So, I guess I have no choice but to parse /data/system/appops.xml to get the modified values and the default values can be retrieved from the AppOpsManager class or via appops tool in order to provide compatibility. This requires much effort than I previously anticipated, and a complete implementation may take several days. So, I'll just make some small modifications just to ignore the errors (at least other app ops will be visible in the App Ops tab) until I fully implement the solution.

[nerd190]

I agree 100%, and thank you once again!

[nerd190]

Hello mate! just an update from me since the last version was released, it is to do with app ops still not showing but in a different context.

• App Ops not showing for blocked apps.

What I did:

I updated my version to the latest release, went to RCX (an open source, r-clone app that unfortunately, contains google firebase) and no app ops are showing, I think this is due to app ops are blocked on this app already, as all the other apps in App Manager (not being blocked already) show app ops perfectly still.

What I tried:

• Wiped app's data & removing contents of AppManager's Android/Data/ folder so a fresh install, opened app, still nothing for RCX.
• Opened AppOpsX and allowed everything to RCX, wiped data/cleared Android/Data/... folder, opened app, but still no app ops showing for RCX.

Observation:

It could possibly be that I (cant remember!) modified some values from AppOpsX, and App Manager doesnt like it. So I tested some more...

Further observation:

I have noticed that if I change app ops / perms in App Manager, that both AppOpsX & Watt are aware of this, and show these disallowed options as greyed-out and available to re-enable.
Is it possible that App Manager may not be aware and in fact, already blocked ops are causing it a problem? So I tested more...

I tried:

Navigate to go to an app not neing blocked by any of these apps at all, and as expected, App Manager shows all of it's app ops perfectly, then if I uses AppOpsX to block even a few ops, then open App Manager and go to app ops, it no longer lists any ops at all.

1. It shows no ops at all.
2. It doesnt list ops that are not being blocked.

Conclusion:

Perhaps, these other two apps query available app ops in a different way, thats where I would look.
(If only I could read Java!) :'(

Also:

As I have tried allowing all ops again from AppOpsX, I see no way of me fixing this currently (no way to revert, without wiping phone and starting again) so I also think this could affect your backup/restore ops feature you have implemented, or (perhaps, in fact the opposite!) it could be the only way (us / App Manager) can control these ops, as the interface may not show ops but perhaps it will still read the ops from its .xml file fine???
We could test this theory...

Hope this helps buddy, we will succeed! 😁

[MuntashirAkon]

This is really weird behavior of app ops. But there's nothing unsurprising about it though since app ops are relatively a new concept and may change dramatically in each API. I'm currently running a GSI rom on Android 10 where app ops loads just fine even after I change some values in AppOpsX. Clearly further investigation is required. Also, I wasn't able to make a working build of AppOpsX (which is broken after v1.2.5 as the dev was trying to replace root with Shizuku). His last release from F-Droid works but I couldn't able make any working build using API 29. My guess is AppOpsX only works when it is built with API 28 or less. I've tried similar approach like AppOpsX (ie. using the hidden IAppOpsService.aidl), but as I described above, I get only a few results unlike AppOpsX. This is probably because of the restriction placed on Android to prevent accessing the hidden API via reflection. In Android 11, reflection gets even more restrictive. So, I decided not to use the hidden API in my app.

AppOpsX is really a over-complicated app (I never understand why people make simple things so much complicated!), and it's very difficult to understand how it works. Had I able to make any working build, I could at least understand that which part of the code works.

appops.xml stores only the values that are altered. You still need to fetch the mode of other ops via hidden API or appops tool.

[MuntashirAkon]

It seems the problem is with the appops tool itself. I've reported a bug in the Google Issue Tracker. Let's see what they have to say about it.

[MuntashirAkon]

@5c0tt-b0t Could you please test this build. This should solve most of your issues.
AppManager_v2.5.8 (269).apk.zip

[nerd190]

Apologies for not being so active lately, have been very busy! thank you for messaging me, this build is literally perfect apart from only one app what one?
of course... google play services.
I can see all values for the apps I have modified now, apart from google play services, clicking the activities/ops button from the apps screen gives an instant force close, almost like google done this intentionally! I tried other google apps, chrome, even android 'account' app, all other google apps apart from play sevices app are viewable/editable.
This issue is 99.9% fixed now, just seems to be OnePlus with google play services app only, the rest is perfect.
I will capture the error in a logcat once I get home soon!

THANK YOU!

(If the logcat doesnt give you anything, then I may try backing up & wiping my phone to test if perhaps, disabling app ops from a newer version of the app helps with keeping them revealed)

[MuntashirAkon]

Thanks for testing it and I'm glad that it finally worked. Apart from logcat (for crash logs), please attach the output of appops get com.google.android.gms.

[nerd190]

Ok, so first appops command:

COARSE_LOCATION: allow; time=+9d20h47m55s560ms ago
FINE_LOCATION: allow; time=+9d16h42m28s42ms ago
READ_CONTACTS: allow; time=+10d5h49m46s788ms ago
WIFI_SCAN: allow; time=+10d5h58m1s538ms ago
READ_SMS: allow; time=+10d5h52m12s884ms ago
WRITE_SMS: ignore; rejectTime=+10d5h57m14s652ms ago
WRITE_SETTINGS: deny; rejectTime=+1d23h58m4s341ms ago
SYSTEM_ALERT_WINDOW: deny
WAKE_LOCK: allow; time=+1d23h57m4s607ms ago; duration=+1m1s568ms
MONITOR_LOCATION: allow; time=+10d5h52m24s142ms ago; duration=+7m19s305ms
GET_USAGE_STATS: ignore; rejectTime=+2m49s471ms ago
OP_READ_PHONE_STATE: allow; time=+10d5h52m12s884ms ago
USE_FINGERPRINT: allow; time=+1d23h58m4s693ms ago
READ_EXTERNAL_STORAGE: allow; time=+3h9m45s760ms ago
WRITE_EXTERNAL_STORAGE: allow; time=+3h9m45s760ms ago
CHANGE_WIFI_STATE: ignore; time=+10d2h57m2s982ms ago; rejectTime=+5d17h1m29s283ms ago
PICTURE_IN_PICTURE: deny
RUN_ANY_IN_BACKGROUND: ignore

Cannot be 100% on this... I am pretty sure I would have denied "monitor location" and "read phone state", but it was some time ago now, so perhaps I just forgot to!
Anyway... The log (filtered for "errors" only):

07-09 17:20:49.675 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedlauncher.libre.dev/ch.deletescape.lawnchair.LawnchairLauncher/2
07-09 17:20:51.179 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.MainActivity/269
07-09 17:20:51.189 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.MainActivity/269
07-09 17:20:54.156 E/RichInputConnection(4116): Nest level too deep : 1004
07-09 17:20:54.355 E/RichInputConnection(4116): Nest level too deep : 1004
07-09 17:20:54.572 E/RichInputConnection(4116): Nest level too deep : 1004
07-09 17:20:54.749 E/RichInputConnection(4116): Nest level too deep : 1004
07-09 17:20:56.361 E/ActivityTrigger(1339): activityStartTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.AppInfoActivity/269
07-09 17:20:56.362 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.AppInfoActivity/269
07-09 17:20:56.375 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.AppInfoActivity/269
07-09 17:20:56.589 E/PhoneInterfaceManager(2311): [PhoneIntfMgr] checkCarrierPrivilegesForPackage: No UICC
07-09 17:20:56.591 E/PhoneInterfaceManager(2311): [PhoneIntfMgr] checkCarrierPrivilegesForPackage: No UICC
07-09 17:21:00.185 E/ActivityTrigger(1339): activityStartTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.AppDetailsActivity/269
07-09 17:21:00.186 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.AppDetailsActivity/269
07-09 17:21:00.202 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.AppDetailsActivity/269
07-09 16:58:34.218 E/AndroidRuntime(27641): FATAL EXCEPTION: main
07-09 16:58:34.218 E/AndroidRuntime(27641): Process: com.thirtydegreesray.openhub, PID: 27641
07-09 16:58:34.218 E/AndroidRuntime(27641): java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Enum.ordinal()' on a null object reference
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at com.thirtydegreesray.openhub.ui.fragment.d0.a(Unknown Source:91)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at com.thirtydegreesray.openhub.ui.adapter.base.z.a(Unknown Source:2)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at com.thirtydegreesray.openhub.ui.adapter.base.a0.onClick(Unknown Source:17)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.view.View.performClick(View.java:6669)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.view.View.performClickInternal(View.java:6638)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.view.View.access$3100(View.java:789)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.view.View$PerformClick.run(View.java:26145)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.os.Handler.handleCallback(Handler.java:873)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.os.Handler.dispatchMessage(Handler.java:99)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.os.Looper.loop(Looper.java:193)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at android.app.ActivityThread.main(ActivityThread.java:6898)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at java.lang.reflect.Method.invoke(Native Method)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:537)
07-09 16:58:34.218 E/AndroidRuntime(27641): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
07-09 17:21:00.377 E/AndroidRuntime(26972): FATAL EXCEPTION: Thread-5
07-09 17:21:00.377 E/AndroidRuntime(26972): Process: io.github.muntashirakon.AppManager, PID: 26972
07-09 17:21:00.377 E/AndroidRuntime(26972): java.util.ConcurrentModificationException
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at java.util.ArrayList$Itr.next(ArrayList.java:860)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at io.github.muntashirakon.AppManager.storage.StorageManager.hasName(StorageManager.java:93)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at io.github.muntashirakon.AppManager.compontents.ComponentsBlocker.hasComponent(ComponentsBlocker.java:137)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at io.github.muntashirakon.AppManager.fragments.AppDetailsFragment.getNeededList(AppDetailsFragment.java:383)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at io.github.muntashirakon.AppManager.fragments.AppDetailsFragment.access$1700(AppDetailsFragment.java:75)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at io.github.muntashirakon.AppManager.fragments.AppDetailsFragment$ActivitiesListAdapter.lambda$reset$4$AppDetailsFragment$ActivitiesListAdapter(AppDetailsFragment.java:575)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at io.github.muntashirakon.AppManager.fragments.-$$Lambda$AppDetailsFragment$ActivitiesListAdapter$7Dw1Llvp9ld-XJVd0rHsIW8B8aM.run(Unknown Source:4)
07-09 17:21:00.377 E/AndroidRuntime(26972): 	at java.lang.Thread.run(Thread.java:764)
07-09 17:21:00.392 E/system_server(1339): Invalid ID 0x00000000.
07-09 17:21:00.395 E/system_server(1339): Invalid ID 0x00000000.
07-09 17:21:00.398 E/system_server(1339): Invalid ID 0x00000000.
07-09 17:21:00.404 E/system_server(1339): Invalid ID 0x00000000.
07-09 17:21:00.416 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedio.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.MainActivity/269
07-09 17:21:01.584 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedlauncher.libre.dev/ch.deletescape.lawnchair.LawnchairLauncher/2
07-09 17:21:01.585 E/ActivityManager(1339): Found activity ActivityRecord{9671d9b u0 io.github.muntashirakon.AppManager/.activities.MainActivity t-1 f} in proc activity list using null instead of expected ProcessRecord{30b3ce4 26972:io.github.muntashirakon.AppManager/u0a113}
07-09 17:21:01.634 E/InputDispatcher(1339): channel 'cbc1029 io.github.muntashirakon.AppManager/io.github.muntashirakon.AppManager.activities.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
07-09 17:21:04.054 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedcom.pluscubed.matloglibre/com.pluscubed.logcat.ui.LogcatActivity/11
07-09 17:21:04.064 E/ActivityTrigger(1339): activityResumeTrigger: not whiteListedcom.pluscubed.matloglibre/com.pluscubed.logcat.ui.LogcatActivity/11

[MuntashirAkon]

java.util.ConcurrentModificationException is not related to app ops. It's related to component blocking. I'll add a fix as soon as possible.

[MuntashirAkon]

@5c0tt-b0t try this.
AppManager_v2.5.8 (272).apk.zip

[MuntashirAkon]

So... does that mean that OnePlus use IFW component blocking rather than AppOps for certain apps? i.e Google Play Services. ???

No, this was an issue with App Manager itself (though I'm not sure why Google Play Services is causing this explicitly).

I'll keep it open for a bit long until I fully improve the App Ops tab itself. As you have described earlier, I need to display the op constant value as well as the name (if available). I also need to display the current mode (allow, ignore, deny, etc) as well as last access/reject time and duration.

[MuntashirAkon]

Closed via c42b373