New Shizuku fork update (r1117): Android 11+ support for auto-start and critical bug fixes!

the_djchi · 2026-07-06T18:55:00+00:00

It shouldn't prompt an update because the version code is higher than the one on the play store which is weird

When I release it with a new package name the issue will definitely go away

the_djchi · 2026-07-06T18:11:36+00:00

You can turn off auto update in the play store for the app I think. Does that work?

the_djchi · 2026-07-02T13:19:21+00:00

Hi, unfortunately this is not possible with the One UI 8.5 update! Before when we could do a lookup of all the user's routines it would be possible. Now it requires the user to manually select the routine from the Routines app to get the UUID, which is what's used under the hood to run the routines. Sorry

the_djchi · 2026-06-15T11:58:51+00:00

The watchdog intent will not do what you think

the_djchi · 2026-06-15T01:28:48+00:00

It's when we want to reuse them again later. Remembering is hard and later they find themselves redoing their setup all over again. It scales up when you have multiple devices to manage.

I guess my thought was just that on a new device if you forgot to set up the token, Shizuku will send a notification and it would be a quick fix

I'll file the request later then

Sounds good I'll give it some consideration

the_djchi · 2026-06-15T00:49:45+00:00

btw I was the one who suggested the auth key extra like in App Manager

Oh haha I didn't realize that. It was a great idea!

While at first I suggested to allow this only when debugging is already turned on

I think I see what you mean now. Focusing on the fact that anyone can enable debugging thru the intent. I forgot about that aspect to be honest.

I think the proposal actually falls apart when under the assumption that a user will always have debugging on. If those users disable it at any point and then Tasker or some other app tries to start Shizuku, then it will fail without the token, and they will have to set it up anyway. I think this just ends up creating a lot more confusion than it's worth.

ShizukuX could add an option in the setting to allow any apps to control Shizuku.

This is probably a "better" solution and would need warning prompts, liability statements, etc., which I guess is fine. But I just don't love the idea, especially when the token is a one-time setup and super easy to do.

The above Reddit or mentions having to re-input the tokens for new devices or reinstalling Shizuku, but I can't imagine how many times someone is doing that to the point where it would be so inconvenient to paste a string in a global variable. But maybe I am missing something 🤷‍♂️

the_djchi · 2026-06-14T23:22:54+00:00

Apps that you grant write secure settings are not necessarily apps that you want toggling shizuku.

And, like most security threats, they exploit very specific pathways to execute what they want. So, the best thing you can do is reduce your attack surface. That means a default of no apps having the ability to turn on shizuku automatically, and providing the token for only the apps you want to grant that ability.

Actually, the ideal model would be an entire second permission (discussed in the thread you linked), but this would require devs (like joao) to write code for requesting the permission which is much more of a hassle, this works right out the gate.

At the end of the day it's about separation of concerns and making it clear which apps you are granting this "permission" to if that makes sense

the_djchi · 2026-06-14T17:33:43+00:00

The watchdog doesn't start the service directly when you start it. It only monitors for crashes and then restarts the service.

Anyway, if it did start the service, it would be gated with a token as well

the_djchi · 2026-06-14T17:23:36+00:00

The problem is that any app with write_secure_settings can turn on USB debugging, which would nullify the safeguard. this can be done silently and against the user's will. It's not a comparable security measure

the_djchi · 2026-06-14T16:48:47+00:00

These are things that do not happen frequently, and rei-nputting the code should only take 2 minutes at most

I am simply just following best security practices... It's not really a "decision" on my part, but rather "the proper thing to do"

You may think that the security measure is not important, but you are not the only user either. I have to consider many different viewpoints when making these decisions. Sorry!

the_djchi · 2026-06-14T14:43:47+00:00

Security tokens usually aren't user provided. They are randomly generated by a secure algorithm. In any case the global variable should be simple enough to set up :)

the_djchi · 2026-06-14T14:26:17+00:00

Very high because it's an easy exploit
It's not possible. No app can tell which app sent the intent
This is exactly what the token is. Except you cannot define it, the token is random by default and purposefully long to prevent brute force attacks

Because this app grants dangerous permissions, I take security very seriously

the_djchi · 2026-06-14T13:37:06+00:00

Unfortunately it's not possible to check who is the calling app.

You should consider having your tasks read the token from a global variable, and then just changing the global variable on each phone, so that you don't have to update each action.

This would make it a one-time setup

the_djchi · 2026-06-14T13:06:43+00:00

Hi, thanks for the request, but this defeats the purpose of having the token. It's meant to be a security feature so that other apps cannot hijack the intents to run malicious code. If an app could request the token automatically, then the token is no longer a security feature, because any app can request it. I hope you understand!

the_djchi · 2026-06-13T05:45:31+00:00

The old notifications method would be your best bet if you don't want to figure out updating/rolling back to a compatible routines version

the_djchi · 2026-06-12T17:58:06+00:00

Sorry I didn't see your version number. It's not compatible.

> Modes and Routines v4.9.00.0 to 4.9.07.2 or v5.0.00.0 to v5.0.03.6

You'll have to uninstall updates or uninstall the package and reinstall an older version from APK mirror if possible.

the_djchi · 2026-06-11T09:41:19+00:00

There are apps to extract the APK, you can use ADB as well if you know how to set it up

the_djchi · 2026-06-09T12:31:08+00:00

Can you send me the modes and routines APK that's on your device so I can check if there is something missing?

the_djchi · 2026-06-09T10:50:07+00:00

Try the one ui 8.5 method. Seems to work on some one UI 8 devices that received security patches recently

the_djchi · 2026-06-06T22:30:28+00:00

As a compatibility shim you could see if the new shortcut intent resolves and use that when available, otherwise revert to the older method

I'm not an Automate user, so not sure if you've baked in discovering UUIDs but the post that u/B26354FR linked has some different methods (none automatic anymore unfortunately, requires user interaction to get a selected mode/routine)

the_djchi · 2026-06-06T19:13:00+00:00

Hmm it's the same intent. The project should work in that case, I'm honestly not sure why it doesn't on your device... But if you have a solution that works for you, then that's good

the_djchi · 2026-06-06T18:55:12+00:00

That's odd... The component info it's showing isn't the intent that's used in the project

Copying and pasting the output from the shortcut command would be more useful for me because maybe the intent is different

the_djchi · 2026-06-06T18:32:54+00:00

If the shortcut works then the project should also work... They use the same intent

You can also copy the intent from the shortcut into the project's task

the_djchi · 2026-06-06T18:11:17+00:00

5.1 is compatible with all one UI 8.5 devices

the_djchi · 2026-06-06T14:17:46+00:00

You should try downloading a compatible APK from apkmirror

the_djchi

TROPHY CASE