Automagic Forum

I wonder how to go over all the application and enable/disable notification based on a configure list.

I have thought the same using Control UI, to disable all data usage for both mobile data and wifi (built-in firewall). But it is really too painful. The script takes probably several minutes to finish and may not be disturbed by any other UI action. And it may have chance to fail if the speed is set too fast.

I try to find the root method and change the file directly, but not reflected by system. I don't know if notification setting also the same. The file should be in /data/system/notification_policy.xml
I wish to know too if there is method to control either the notification or the firewall thru execute root command.

It seems system just insert importance="0"to the xml as below:

<package name="com.knudge.me" importance="0" show_badge="true" app_user_locked_fields="0" uid="10245">

The issue is some background thread keeps a backup copy so even I killed setting before modification, it still reverts back.

I end up installing app https://play.google.com/store/apps/deta ... sOff&hl=en

That's the problem, the file only used as storage, not reflected by the system immediately.
There is adb shell cmd notification. But after trying to suspend the package name, it still didn't change the notification status.

And guess what? After reading your last comment about other app, I immediately remember that Automagic has that action already. Quick search on action, there is Set App Notification State (need root as the plugin too). Hahaha , so we have it built-in already. But unfortunately there is limitation. That action only can change one app at one time, so we have to loop over all the apps we need to change the state. Probably we can request to have multiple checkbox for this feature. So we only need 2 action to set all apps at once, 1 action to set group of apps that need to be on; and the other for off.

have some script to get all installed apps into a map and multi-select from them. The issues are
1. how do I initiate value based on the previous selection so that I don't start from scratch every time. Extended counter in the setting and minimize the action steps seems worked out.
2. While setting notification in the app loop, emergency stop is triggered. Not sure why.
3. While attaching exported flow here, I get error "upload was rejected because the uploaded file was identified as a possible attack vector". Thus zip format.

I need some time to study and recreate the flow for the choosing.
1. Save previous selection into glovar. Then for next time, put the selected app list from glovar to the default field. It must listformat,comma form too.
2. Because you loop upon so many apps at once. The flow element execution exceed 60 elements perminute, hence run into emergency stop. You should increase the Automagic Emergency Stop (AES) in the flow option. But you still can improve the efficiency of the element execution. Currently your flow has 5 elements per loop. It can be cutdown into only 3 per loop, by combining the expression and script into the single expression and script.
3. I also have the same problem from the beginning. That's why I usually publish the flow directly from Automagic app.

I worked out the whole flow except reading state from each app and save to globalvar.
Do you know how to read notification setting? I don't see it in package info.
I use global var for input and output of select flow in order to reuse it somewhere else.

Modify the script to move all previously selected item to show first.

It seems not included in the package_info. You can read the notification state in the /data/system/notification_policy.xml before. But you have to parse the value again using regex, to create a proper map of the notification state for each app. It is possible to parse it and use the notification state as the default value. But require much more task and of course root access (not everyone have it). Maybe it is much faster to maintain the database in Automagic and never change the notification manually again via app info setting anymore.

I have made the flow. This will parse the package_info into {app_name}\n{package_name} format for each element The reason I use list instead of map, is because app name can have duplicate name. When you create a map with the app name as the key, duplicate name will be replaced. And it also make confusion when selecting 2 choices with the same name "Settings". So I append the package name to differentiate them. Later we can parse out the package name by using regex.
Set App Notification State Loop

After that, the global_notification will contain the selected value from previous run, which will be used as the default value (preselected choices). You can init the value by creating it first with list type, leave it blank.

Pro Tip : Use {app,listformat,comma} as the default value, run it once, it will preselect every app. You can then unselect which app you don't want the notification to be on and OK. Edit again the default value back to {global_notification,listformat,comma}. I separate the loop into two part, one for enable and the other for disable. Why? Because using your current method, the most efficient loop must have at least 3 element execution per loop : 1 for the loop check, 1 to split the notification whether to disable/enable, and 1 for the action set notification state itself. If you have 300 apps, this will need 3 x 300 element executions = 900.

Using separated loop, I don't need the expression to split to whether disable/enable, hence only 2 element executions per loop. If I enable 200 and disable 100, this will need (2 x 200) + (2 x 100) = 400 + 200 = 600 only. It is 50% more efficient loop at runtime, even though it use more elements. I can use a much lower AES. In this case, I just use 1000, which should be enough. Because the flow itself takes around 20-30 seconds to finish.

My RN5 SD636, with about 250 apps, the flow finish in 26 seconds when using shortcut and 37 seconds when execute manually with the flow opened. This mean each loop takes around 100 ms, and additional 40 ms overhead if the flow is opened.