EAP version 1.36.0-dev

[Desmanto]

clickById() is ok, i will go with your choice.

For Hardware Key Event, I just afraid some will test the flow using a very high AES value. So besides a red label warning about possibility locking out, there can be an advice too, to make sure we have extra backup input possibility. At my phone, I have some kind of floating navigation, called quick ball. I can press home, back, recent and screenshot; and won't blocked out by this trigger. Maybe suggest additional bluetooth keyboard/mouse or similar input device can be a good choice too.

Other method I have been thinking is to add extra option in the Features & Permissions or Workaround, new option to disable all flows which have this trigger upon startup. This probably will disable other triggers too, when they are located in the same flow. But I think better safe than sorry. We can always use the Automagic startup trigger, add some delay about 1 minute, before enabling those disabled flow, so we have 1 minute window to disable it if somethings go wrong. But this really complicate things up. Probably too difficult to explain it to other users.

Other solution (again ) is to make something like xposed feature. Since we can only get into safe mode to fix things up (when we got locked out by this trigger), maybe Automagic need to detect some disabler file. After we get into safe mode, we can create a file named : acc_disabled.txt in the /sdcard/Automagic/ (or Automagic default folder, if we have changed it). The next time we boot normally, when Automagic detect this file existence, It will immediately disable the accessibility services, thus hardware key event won't block us out anymore. We can fix things up and delete the acc_disabled.txt and enable the accessibility back.

I am going to try the fingerprint later, still so many new features haven't been explored yet.

Regards,
Desmanto

[Desmanto]

Hi Martin,

Since I don't have LOS in any phone (plan to flash it actually), what is the difference between Set LineageOS System Setting vs Set System Setting? I check a while, both seems to be the same.

I have problem with the set System Setting action in RN5, MIUI 9.5.13.0, Oreo 8.1. Most of my Set System setting action from LP 5.1 won't work anymore. Example turning on GPS by changing the location provider value doesn't work anymore. But I still can use root for that.

But there is not alternative for some other, example the new android nougat 7.0+ default demo mode, Settings > Additional Settings > Developer options > Demo mode > Turn on. I need this, so I can turn the demo mode on before taking screenshot, making all of my screenshots' statusbar clean and consistent throughout the tutorial.


I can set the value : system - sysui_tuner_demo_on to 1, but the system doesn't honor/reflect the new changed value. So actually Automagic successfully changed the value (0 to 1). But the demo mode statusbar still won't appear. If I go to the setting, I can see it is enabled already, so the action success; but the changes not reflected by the system. If I tap this, it will turn off and the demo mode still off. Only turning it on by the real setting will show up the demo mode statusbar.

Then I try in Bliss Nougat 7.1, the demo mode value is stored at global - sysui_tuner_demo_on. But it fail to toggle the value too. But unlike MIUI, changing other value such as modifying the navbar to show extra IME button works fine. So at least some of the secure setting still can be reflected immediately. While the same navbar setting (swapping the button or adding new button) doesn't change anything in MIUI. Maybe MIUI 9 require additional permission to change those secure settings value, or we need to force the SystemUI to reread the value after we change it.

Tried using adb shell

Code: Select all

adb shell settings put system sysui_tuner_demo_on 1

also face the same thing. So I think if adb fail, then no other app can do it too? Is it true? Is there anything we can do to force the system to reread the value we've changed? I have tried some like manually turn off screen and on. Turn on auto rotation, toggle the wifi/bluetooth but still nothing changed. If there is really nothing we can do, then I will resort to Control UI as my last option.

==============
As another request maybe, since this is related. Because the set system setting is not working reliably in MIUI 9.5.13.0, I've been working on a flow since last week : to capture all system setting value - do some changes in the real setting - and recapture the values again, compare to see any changes. I haven't finish the flow yet, only part of it, but have prooftest the concept.

Suddenly today tasker came out with new Custom Setting feature. It can do exactly the same thing I want. The concept is the same, save the current secure setting value - we make changes in real settings - go back to the app and see what have changed. This make us easier to find the secure setting we need, since we can pick up the one we have changed only.

If it is possible to do the similar things built-in, then I don't need to create the flow for it anymore. It will make life easier for others too, to find the correct setting value for their different devices. But of course the risk is still the same, just easier to map the corresponding secure setting value to the setting we need.

Regards,
Desmanto

[Martin]

Hi Desmanto

LOS uses their own settings database in addition to the regular one so the new action can be used to change the values in the other database. I'm not actually sure why LOS (respectively Cyanogen) decided to separate the values into two databases. Maybe it's easier for them to merge the code from AOSP into their own code base.

You can use Execute Root Command: settings list system resp. settings list global or settings list secure to get the value of all system settings.
I'll consider to add wildcard support to trigger System Setting Changed so you could listen for all changes to the settings database and build a flow to process or show the changes.

Android does not listen for changes to all system settings. Some settings are only used to remember the last applied value across device reboots. Changing such settings via action Set System Setting won't take effect immediately. Often such settings can only be changed by invoking some kind of system service that will activate the option and will also change the value in the settings database. It might also depend on ROM/version if a setting value is tracked or if a special service needs to be called.

Regards,
Martin

[Desmanto]

Hi Martin,

I see, the LOS probably have their own specific setting that is available only at that ROM. Still considering whether to flash it, with the MIUI 10 is so close already, too lazy to do the backup restore again, not mentioning adjusting all necessary flows. (especially the one with Control UI).

Oh wait. How can I forget that Automagic already has the Trigger : System Setting Changed ? Yes, it only lacks wild card support. After we have it, it is much flexible then. I can simply attached my variable logger script and I can tracked any changes happened across a span of time. Or I can popup the input dialog to choose the value I need and coupled it with control UI to pick the value for me, much easier life then.

Using settings list global/secure/system doesn't work anymore in Oreo 8.1 (it works in Bliss Nougat 7.1). In Oreo 8.1 it return with something like :

cmd: Failure calling service settings: Failed transaction (2147483646)

For my current flow, I simply cat the content and parse the value using regex and save it into the map.

Code: Select all

cat /data/system/users/0/settings_global.xml

Do the same for secure and system category. Using findAll() (this is one of the best function I use frequently) and capture the grouping, save it to glovar map, ready to be compared later. I shall continue my flow then, since I still need to query all possible values. Sometimes looking at the list can give me inspiration about new trick up my sleeve.

For those value not honored by the system, guess I have to deal with it then. I probably need to find the alternative using the intent action. Probably the system broadcast something when it changes the value. Let see if I can find it later. And if nothing found, last resort is always Control UI. Thanks for the confirmation.

So in the end, I only need the wildcard support in the Trigger : System Setting Changed. Can't wait to see it in the stable build.

Thank & Regards,
Desmanto

[Martin]

A new EAP version is available.

Changes in this update:

• added script functions takeScreenshot and lockScreen to action Control UI
• extended action HTTP Request to optionally use a defined network interface
• added possibility to specify wildcards in trigger System Setting Changed to allow detection of all changes
• added setting to specify the amount of time to wait for accessibility events
• optional light theme (Android 6+)

Download: Automagic.apk (2018-07-08)

Regards,
Martin

[anuraag]

added setting to specify the amount of time to wait for accessibility events

Thanks Martin. Accessibility working as i expected.

[Desmanto]

- I thought takeScreenshot and lockScreen is available for all, but turns out only for Android P. But good to see this function, because it means accessibility is going to stay.
- So far testing, HTTP using certain interface is working. It will throw error if the interface is not connected, so we can catch the error and turn on that interface if needed
- Wildcard support in System Setting changed is another waited addition. I tried and it will pop up the setting name directly in debug dialog. Need at least 3 triggers for all 3 categories, but it is much easier now to log the changes.
- time to wait for acc. >> I wonder if this correlate to the speed of UI event detection. So far, I measured about 500 ms latency before the trigger UI event happens. If this is set to 100 ms, means the latency will be 100 ms, but the accessibility service will query 5 times more per second. Is that right? Wonder will it drain the battery significantly faster. And does it correlate to the widget refresh speed too? (since it is also 500 ms before next refresh)

[anuraag]

- time to wait for acc. >> I wonder if this correlate to the speed of UI event detection. So far, I measured about 500 ms latency before the trigger UI event happens. If this is set to 100 ms, means the latency will be 100 ms, but the accessibility service will query 5 times more per second. Is that right? Wonder will it drain the battery significantly faster. And does it correlate to the widget refresh speed too? (since it is also 500 ms before next refresh)

I wonder how you measured yourself? Did you measure for tasker also? I was having a problem where automagic fails to trigger if executed repeatedly for 3-8 times.

[Desmanto]

I create 2 simple flows and save the datetime in glovar.

1st flow
Trigger : Shortcut
Action : Script

Code: Select all

global_measure = getDate();

Action : Launch App : Settings

2nd flow
Trigger : App Task Started : Settings
Action : Script

Code: Select all

dif = getDate() - global_measure

Action : Notification on Screen : {dif}

2 test flow.png (55.78 KiB) Viewed 24568 times

And second run, I change the App Task Started trigger to UI Event - Window Opened - Settings.

Basically, what it does it to put a start anchor time, launch the settings. Wait until the launch of setting detected by Automagic accessibility (triggered the 2nd flow). Check the time and subtract it. Toast the difference (in miliseconds). Execute the flow using the shortcut, as if we test the flow inside Automagic, it will be slower, caused by the flow progress redraw.

The reason I know it is about 500 ms, is because I ever tested it using Xposed module - app context (at previous phone), and get the result around 200 ms only if using the plugin, while using built-in Automagic trigger gives around 700+ ms (there is 500+ ms difference, see the gray color).

Comparison of latency.png (8.97 KiB) Viewed 24568 times

I try at my current phone, and got about 750-800 ms at my RN5 MIUI 9.5.17.0 Oreo 8.1. Seems to be a bit slower. I then tried tasker with a similar flow context, as you have suggested. I use Profile > app and Profile > Event > UI Event > New Windows (similar to UI event trigger). Profile App gives about 220-270 ms and New Window only about 50-100 ms (much faster). I don't give root access to tasker, so it must have improved the detection since the last time I tested it. Because at previous phone, it also hover around 700 ms as Automagic does. (it used to be tie)


I proceed to test now the new EAP version with the ability to adjust the timeout. I think maybe because I use so many UI event already, so it slows down. I should try in a new devices with minimum active flow (to reduce the possibility of slowing down) In Bliss Nougat 7.1, emulated in Virtual Box, Automagic App Task Started - classic gives about 750-850 ms average. UI event gives about the same. Tasker App profile gives about 200-250. The UI window opened, give twice 120-150 and another at around 300-400. Don't know why the duplicate event, but only the first one count, so much faster.

If I set the accessibility wait event to 200 ms, it will gives around 500-600 ms. 100 ms will give 400-500 ms. So it seems even though we deduct it till 0, we can only achieved 300-400 ms; which is somehow still slower than tasker Profile app. So I now know it is not caused by the active flow. There is something in tasker than detect the app/UI much faster.

So I retry again at my old phone. Now UI event give around 1100 ms, app task started 900-950. At the same time, tasker 5.2 gives around 520-580; still faster than Automagic.

Don't know why tasker now can detect much faster. Last year, to achieve such speed, Xposed module (AppContext) is needed, as it can hook to the process immediately as it started. 200 ms is the best. So I think Automagic still can improve in this part : app and UI detection (tasker already). Well, Automagic doesn't degraded, it is just tasker already improved. I use 16 UI Event, or about 8% of my triggers and 6 pair of app task started/ended, about 6%. If the speed of detection can improve 4 times faster, it will surely save thousands of miliseconds everyday. But of course, I still prefer battery efficiency first. As current state of accessibility almost give no impact to my battery life. I even frequently outperform those who don't use automagic at all. (My yesterday SOT is almost 14 hours, compared to the average 10 hours for other RN5) Probably it is because I have delegated so many tasks from one-trick-pony app to Automagic, making most of my daily activity much more efficient.

Your mileage may vary. But for 2-4 times speed difference, there must be something tasker has done so it can detect it much faster.

=============
As for the fail to trigger, I think you should ask in separate thread if it is not related to this EAP version. When it fails after several trigger, what is the error produced? Any pattern you can spot in the log? Or the flow simply refuse to accept any more trigger? I remember ever have more than 100+ trigger queued, and it still run properly before hitting emergency stop.

Sorry for the long post, you ask for it

[anuraag]

I was expecting long post . Thanks for your detailed info.

I agree with you that automagic still outperform tasker in many ways and without those dozen plugins. For me i don't have skills to create some simple tasks in tasker and i can easily create complicated tasks in automagic.

I have already shared my problem with Martin by mail and he came with this solution.