MacroDroid/Tasker Integration via Plugin

[vibhor1102]

Currently working on it, and defining a Locale plugin within Klick'r seems extremely promising. The initial aim was to allow macrodroid/tasker or other automation apps to start/stop specific scenarios and integrate. Allowing them this access through intents was very user unfriendly, exactly how intents tend to behave. But early testing versions of the Locale plugin seem to work well, not a security concern, and user-friendly. A normal user who has basic MacroDroid/Tasker macro creation and Klick'r scenario creation knowledge would be able to carry it out with no problems. The ScenarioID and any backend info is not required by the end user, and setup remains minimalist.

Examples

• start a specific scenario when a game is opened, or close it when the game is closed.
• integrate into other advanced automations.

Drawbacks

• Screen casting prompt is unavoidable. That makes any screen-off scenario startup impossible.
• Tasker/MacroDroid are paid applications. The free options are limited.

Future Direction

• There can be a new type of action (currently assuming the name "External Action" for it) that invisibly allows the scenario to invisibly communicate something to MacroDroid/Tasker, where it can be added as a trigger to a Macro. Each External Action would need to carry a specific user-defined name and there can be as many of them and those of the same name can be used as many times as needed, just like counters/variables/functions.

  Examples

  • When the External action is placed next to scenario stopping action, it can carry message that scenario stopped, which can trigger certain action in the external Macro.
  • For any broad system-wide actions that are out of scope, like changing any setting during a scenario's event, users can place an Extenal Action, and setup MacroDroid/Tasker to recognize that trigger, and execute the POWERFUL action when that trigger is fired.
  • @Nain57 You intended the intents to be only for use by developers? Well, you can completely remove those, and let the users know that they're meant to use an External Action in place, and use the heavy automation app for this task. And intent's difficulty to use doesn't become your headache anymore!

FAQs

Q1: What API standard is used to integrate with automation tools (Tasker/MacroDroid), and is there developer documentation?

A: We implement the open Locale Plugin API, which is the industry standard natively supported by all major Android automation hosts (Tasker, MacroDroid, LlamaLab Automate).

• All plugin activities and receivers are declared in the :feature:external-launch AndroidManifest.xml.
• The core specifications are described in the Locale Plugin API Specification and João Apps' Tasker Plugin Development Guide.
• The plugin contracts in our codebase are defined in LocalePluginContract.kt (for incoming controls) and ExternalActionEventContract.kt (for outgoing triggers).

---

Q2: What is the exhaustive list of features and operations that Klick'r exposes?

A: The integration supports three operations:

1. Start Scenario (LocalePluginOperation.LAUNCH): Launches a specific scenario. Supports both Smart and Dumb scenarios. Configured and serialized using LocalePluginConfiguration.kt. Dumb scenarios are fetched via Room from the local DumbDatabase, and Smart scenarios from ScenarioDatabase.
2. Stop Scenario (LocalePluginOperation.STOP): A global stop setting to immediately halt the currently running scenario. Configured instantly without a GUI via LocalePluginStopConfigurationActivity.kt.
3. External Action Event (Outgoing): A custom Klick'r action that sends a broadcast containing the action name (com.twofortyfouram.locale.intent.action.REQUEST_QUERY). When the automation host queries Klick'r, ExternalActionEventQueryReceiver.kt matches the configured name against the fired name inside the pass-through bundle data (net.dinglisch.android.tasker.extras.PASS_THROUGH_DATA).

---

Q3: How are setting configuration payloads secured against local spoofing/forgery?

A: Because com.twofortyfouram.locale.intent.action.FIRE_SETTING is an open broadcast, a malicious local app could send spoofed intents to start or stop random scenarios. To prevent this, payloads are signed with a private key stored inside the hardware-backed Android KeyStore:

• When saving a setting, AndroidKeystoreLocalePluginSigner.kt generates a HMAC-SHA256 signature of the configuration JSON payload.
• This signature is bundled inside SignedLocalePluginConfiguration and returned to the host.
• When the settings receiver fires, LocalePluginConfigurationCodec.kt verifies the HMAC payload signature. If the signature is missing or forged, the trigger is silently dropped.

---

Q4: How is the system Media Projection consent warning handled, and can it be bypassed?

A: System Media Projection security requirements cannot be bypassed silently, but the implementation minimizes user intervention:

• Projection Reuse (Bypass): If a smart scenario is already active, calling replaceSmartScenarioWithCurrentProjection() in LocalService.kt updates the active scenario ID and switches the target scenario without prompting the user, reusing the existing casting token.
• Interactive Screen-On Flow: If no projection is active, Klick'r launches LocalePluginExecutionActivity.kt as a translucent window to request the casting token.
• Lockscreen Fallback: If the device is locked or non-interactive, the receiver falls back to posting a notification. Clicking the notification prompts the user once they unlock the device.
• Note on keeping projection active when idle: Currently, calling stopScenario() (manually or via plugin) executes stopAndWait() which terminates the projection proxy and stops the screen capture session. Keeping projection alive when no scenario is running is not natively supported in Klick'r's current session-coupled architecture.

---

Q5: When can a user expect to NOT see the media projection prompt, or the launch scenario failing to do anything?

A: There are specific scenarios where the media projection prompt cannot open, or the launch fails:

1. Device Locked / Screen Off: For security, Android prevents launching interactive permission activities when the screen is locked or off. Klick'r detects this state and drops back to the notification fallback. The user must unlock their phone and click the notification to trigger the prompt.
2. Foreground OEM Restrictions (Aggressive Battery Optimizers): Many manufacturers (such as Xiaomi, Huawei, OnePlus, and Samsung) block apps from starting activities (like the media-projection prompt) from the background.
   • The 1.5-second Timeout: If the prompt fails to open within a 1.5-second timeout (DIRECT_LAUNCH_FALLBACK_DELAY_MS), Klick'r registers a launch failure and posts the notification fallback.
   • "Don't Kill My App" Troubleshooting Popup: The next time the user opens Klick'r, ScenarioActivity consumes the failure state and displays the BackgroundLaunchTroubleshootingDialog dialog, directing the user to the Don't Kill My App guide to configure battery optimization exemptions.
3. Already Running Scenario at Scenario Settings: If a scenario is currently active and the user is editing its settings, launching an external control triggers a mutex check (scenarioChangeMutex). It will safely stop the running scenario first before attempting the replacement.
4. Notifications Disabled: If the user has disabled OS-level notification permissions for Klick'r, the notification fallbacks (used during screen-off or background OEM blocks) cannot be displayed. In this case, the launch will fail silently with no feedback.

[Nain57]

Hi and thank you for your contribution as usual.

First I see your starting a list a feature request, please split them into diffierent posts (as stated in rules of the section: #883).

Feedback:

• I've never looked at how the integration works, but the first step would be to find the documentation for those. I might already have them so sharing it would help the request.
• Other user have requests with other kind of integrations, like adb for instance: Need ADB command or Dynamic/Desktop Shortcuts #887
• For the intent feature: As I said, I don't really know how tasker or others communicate, but it might be using intents as well under the hood.
  The thing is, the raw intent feature is used by several people i know to start external tools execution and comunicate with them. One thing i do agree is that this "raw" intent API feature is no user friendly at all.
• The main drawback is, as you said, the need to display the MediaProjection request to the user. How do we handle it?

To be Refined

• What API are provided by Tasker or other big apps. Is there something common or do we need to use different systems for each use cases ?
• What are the exhaustive list of things Klick'r should expose ? Starting a scenario, requesting the projection ...
• How this will be displayed ? As i said, raw intents are useful for a few people, but the whole dialog can be reworked to support different format of external communications.
• For the Media Projection: we can request it at any time, add an api to display the request, and even add an option to keep it when no scenario are loaded to be ready for other apps to interact.

I won't have enough time to dedicate to feature requests until the 4.0.0 is finalized, as I want to dedicate as much time as possible to finish the tutorial rework and bug fixes as quickly as possible, but I will try to keep this one updated to use as a reference for the others and that's something requested several times and never had the time to implements. As stated in the rules, the goal of those Feature Request is to refine a ticket that i will add here once all the details are defined: Klick'r Requested Features Implementations (view)

[vibhor1102]

Noted. I'll be splitting the features listed here into their own individual posts instead. Will be limiting this one to Tasker plugin-based integration only, and starting separate feature requests for the other ones individually.

I anticipate that there won't be any further betas required after beta03 for bugfixes. I haven't seen any bug submission for the v4 specific changes since beta02, and my personal bughunting has saturated as well and I'm not finding anymore issues. So, i hope v4.0.0 can be marked stable soon (within a week).

• API: I'm not sure about the documentation, because I've been getting AI Agents to write code for me, and the early prototype works fine for interaction. You should be able to find some resources upon searching "Locale Android Plugin API". Apparently, Locale was an old app that was pioneer of this plugin standard, but app got deprecated while the standard was adopted by all major automation apps, making it the defacto standard. So, yes, it's common for them all. However, i only have MacroDroid myself, so that's the only app i can myself test with.

• Intent: I'll let you know more about exact details once i'd have finalized the approach.

• MediaProjection: This would be handled the same way as the Quick Setting Tile, that the user would need to approve the prompt.

• I'll be sharing screenshots and screen recordings as examples for you to understand more clearly before finalizing and converting it into a Pull Request. Plus, more details on technical aspects from my AI Agent.

PS: @Nain57 Feel free to wait on my Feature requests and work on the bugfixes and tutorial rework. I'll be accumulating those in the meanwhile, no problems.

[Nain57]

beta03 will also includes the first batch of the tutorial rework, I would have integrated it in beta01 but was delayed and could'nt work as much as i wanted on them. Impact is really local to tutorials so this should be good.

They take a lot of time to write but I have a stable engine now, I a just have to fix a few minor issues before beta03 release. beta04 will fix the lasts remaining issues found and deliver the remaining tutorials.

I will read your changes, but keep in mind that I can't just validate an IA solution without understanding its wereabouts, so anything you find providing documentation would really helps, (existing open source plugins/add-ons projects source code would be a good starting point)

[vibhor1102]

I'll definitely keep updating and share details here once I've finalized approach, and if you wanna see code yourself or real-time progress, you can check this branch: https://github.com/vibhor1102/Smart-AutoClicker/tree/feature/automation-trigger

[vibhor1102]

Demo for the upcoming "External Actions" feature

Screenrecorder-2026-07-09-14-37-15-704.mp4

(Ignore the fact that Klick'r is actually receiving a blank screen in media projection. It doesn't affect the demonstration, and is the only way to successfully record screen simultaneously.)

Please share feedback about it. Would love to hear any feedback at all.

As usual, WIP code is visible at my fork's branch.

The Start/Stop Scenario is another feature in pipeline, but I'm still experimenting with how to handle Media Projection behavior, and will be sharing its demos once ready. And that's when I'll publish technical summary of how the internal code achieves all this, and create the PR as well.

[vibhor1102]

@Nain57, have a look at the demo. Any thoughts on the integration method? I personally think it's pretty user friendly.

I expect to finish developing it by tomorrow, and that's when I'll share demo for the rest of the plugin's functionality as well.

How many further weeks do you expect the tutorial rework for 4.0 to take? I should open the PR only after 4.0.0 is stable, right?

I'll be working on more features till that time :)

[Nain57]

For the others apps: we don't necessarelly needs to implement the support right now, but we have to think about the integration in the future; Ui and Engine should take that in consideration. I can pay for tasker in order to develop the support after your feature implementation for instance.

[vibhor1102]

You also had a query about "why not use raw intents itself"?

There can be 2 ways to understand it.

1. If the communication between Klick'r and other automation app is going to be occuring through intents anyways under the hood, why not just use raw intents anyways? Because intents are a nightmare to set up for any normal user. I tried it, and the UX couldn't be worse. Plugin allows for Klick'r to show its own UI within the automation app, allowing users to select a specific Scenario through GUI.

2. If I'm doing all this, just to be able to remove the intent action from Klick'r and allow users to set up their intents via the external automation apps instead, that just adds plain one step for them for sure. But my vision is broader. This "External Action" allows them to not just setup intents from within the automation app, but select from other hundreds of actions that they have. For example, changing deep system level settings. Klick'r can never have those because those are all niche use cases, and it allows delegating tasks to the specialists of that category. Just download and go through the Action menus of MacroDroid for instance.

Not sure which one you meant, so i answered both :)

(For all your other questions, I'll answer them later today, or tomorrow)

[Nain57]

I think I expressed by thought badly. Currently, intents allows to start an app, or to use the raw intent. My idea was to modify the intent action dialog UI to propose several types:

• Start app
• Macrodroid
• Tasker
• Raw Intents

Macroiddroid and other will not use the raw intent UI of course, but a dedicated UI, like the start application one. This will keep the current features (even if they are niche) while allowing to propose "pre formatted" intents like the Macrodroid one in your repo.

[vibhor1102]

I think i now get your point finally. Let me explain it in my own words and see if you agree (i.e. we've agreed on the same meaning of your question)

If we already have the intents action, with current Simple and Advanced sub-menu of configurations, why not use that action and add a new sub-menu for MacroDroid/Tasker or whatever is required?

I think the architecture of my external action is a little closer to variables than intents. They rely on specific external apps being installed, and then to have an event trigger setup on that side as well to be listening for the broadcast to be sent by Klick'r which is through the plugin route and not through intent broadcast listener. They're also designed to be global (device/application wide), usable across different scenarios, and internally also i guess quite different from intents. Merging into intents might affect user-discoverability of the feature, especially if the name of the Action is kept as "Intent". If it could be renamed to something more generic, like my chosen "External Action", that'd help in old users at least seeing it as something new and giving it a try once, and new users to not hesitate in trying it either. There, advanced intent really needs to stay as a sub-menu deliberately placed at the end of the list so as to not be something new users see as the first thing.

I did plan on deprecating advanced intents after a new months of notice for a couple reasons though intitially, that's why it never came it in my mind to merge the two together, as i saw myself replacing it:

1. For the users who couldn't figure out how to use the Intent feature, it came around as bad experience in dealing with Klick'r app itself, and a minority of them even turned hostile.
2. Specialist apps like MacroDroid might be better at handling intents as well. I don't understand the intent feature myself fully, but on the surface, look at this MacroDroid's UI, seems to expose more options to configure the Intent. Plus, they have proper variable feature support, which comes in really handy there.

That being said, i do prefer the separate action approach, but your suggestion option is also viable. If you want, i can change the approach to merge the 2 together. Would definitely be renaming them in that case, probably "External Action". And no, MacroDroid, Tasker, etc. don't need their own separate sub-menus. Since Locale API is meant to be used, it's all going to stay interoperable.

[vibhor1102]

@Nain57 I've also added an FAQs section to the main feature request's description. Hopefully answering all your questions. In case i missed something or there is any further question, please re-ask them.

PS: also, apparently i forgot to push with today's (or maybe even yesterday's) changes. But in all, ive tested the Media Projection further, and added much needed refinement as well as edge cases for where media projection prompt can't be displayed. there were many of those. current state is close to final code implementation, I'm just going through quick looks for any minor refinements, bugfixes, translations, etc.

[vibhor1102]

Here's the demo for Launch Scenario.

I've tested a lot of edge cases myself, and went with this solution. When a permission prevents Klick'r from showing Media Projection in background, a notification fallback is shown instead after 1.5 seconds of waiting and no-response from helper process. Plus, the Don't Kill My App popup the next time user opens Klick'r app.

The demo first shows how an attempt through fallback notification usage would look like, and then how another attempt with permission already given would look like. There's no code for directly checking for whether permission to open from background is given or not, since it's not an android-general restriction but very diversely implemented individual restrictions from various phone manufacturers.

Screenrecorder-2026-07-12-13-40-16-410.1.mp4

There's also stop scenario functionality that works exactly how you'd expect it to, although not included in this demo.

[vibhor1102]

Restored back after a month of invisibility as my account was false-positively flagged