Frequently asked questions

Getting started

Do I need root to use Thor?

No. Thor works with any one of three privilege engines:

• Root — Magisk, KernelSU, KernelSU Next or APatch. Thor asks for su through the standard root interface rather than looking for the binary on disk, which is why it works with the managers that hide it.
• Shizuku — no root, no unlocked bootloader; started over ADB or wireless debugging.
• Dhizuku — Device Owner mode on a stock device.

Shizuku is the usual choice for an unrooted device. Root was the only option when Thor launched; Shizuku support was added by request (#46) and is fully supported now.

What can Thor do with no privilege at all?

More than you would expect. Browse every installed app, search it, sort by any of eight keys, filter by install source, state or declared permission, see the home dashboard and the install-source chart, open the app info sheet, launch apps, install APKs and split bundles through the system installer, and use every theme, layout and language option.

What needs a privilege engine is changing an app’s state — freezing, suspending, force-stopping, clearing data, uninstalling system apps.

How do I set up Shizuku?

Install the Shizuku app, then start its server — over ADB from a computer, or with wireless debugging pairing on Android 11 and newer without one. Open Thor and grant permission when asked. Thor notices the Shizuku service appearing on its own, so you do not need to restart it.

How do I set up Dhizuku?

Dhizuku is the most demanding option. Your device must have zero accounts on it when you enrol — Android refuses to set a Device Owner otherwise, and signing into Google afterwards breaks it. Then install Dhizuku, make it Device Owner over ADB, and authorise Thor from inside Dhizuku. In practice that means doing it on a freshly set-up or wiped device.

Which Android versions are supported?

Android 9 (API 28) and newer.

What languages does Thor speak?

English, Arabic, Chinese (Simplified), French, Polish, Portuguese, Brazilian Portuguese and Spanish, plus a “System default” option. You can set Thor’s language independently of your device language. Translation contributions are welcome.

Freezing, suspending and debloating

What’s the difference between Freeze, Suspend and Force stop?

Force stop is a momentary kill. Freeze and Suspend are persistent. Freeze is more thorough; Suspend leaves a visible reminder that the app exists, which many people prefer (#90).

Can I tap a frozen app to unfreeze and open it?

Three ways, depending on how much you want to install:

• Pin a home-screen shortcut — built in, no extension needed. Turn on Add Freezer to launcher in Settings first; Add to Home screen then appears on the info sheet of any user app, on a launcher that accepts pinned shortcuts. You get a shortcut carrying that app’s own icon, desaturated to grey while it is frozen, and tapping it unfreezes and opens the app in one motion. This is the answer for most people.
• Suspend mode. Tapping the greyed original icon brings up Android’s own “app paused” dialog — two taps to get in, and the icon stays where it always was.
• One tap on the original icon, with nothing greyed and no dialog, needs the Stormbringer extension, which requires root and LSPosed.

Automatically re-freezing when you swipe the app out of recents is not possible: Android has no public API for recents-removal events, and the workarounds — an accessibility service, or a polling foreground service — cost battery, demand alarming permissions and would jeopardise the Play listing (#210).

Can I brick my phone by freezing the wrong system app?

Thor bundles the Universal Android Debloater database and checks it before freezing any system app. Anything UAD rates Unsafe is blocked outright, with no override anywhere in the app. Expert shows a loud warning you can choose to pass. Recommended and Advanced proceed normally.

The gate fails closed: if the UAD data cannot be read at all, every system app is treated as unsafe and blocked rather than waved through.

Can I undo it?

Almost always.

• User apps — unfreezing always works, with no data loss.
• System apps — Thor switches them off in place. The app keeps its data, nothing is removed, so there is nothing to restore. This is the only thing a freeze does, in every privilege mode.
• The devices where it doesn’t happen at all — a few OEM builds refuse to let a preinstalled app be switched off by anything but root. On those, Shizuku and Dhizuku cannot freeze that app, and Thor tells you so and leaves it alone. Nothing to undo, because nothing was done. Freezing those apps needs Root.
• Debloated, rather than frozen — recoverable with pm install-existing as long as the APK is still on the system partition, which is the normal case: it is the same file that shipped with your phone.
• Where it cannot be undone — if a system update removes an app from the system partition while it is frozen, there is nothing left to reinstall from.

I switched from Root to Shizuku and now some apps won’t unsuspend.

Known limitation. Android only lets the package that suspended an app lift that suspension, and the three privilege engines register under different identities. The workaround is to switch back to the mode you used when you suspended them, and unsuspend there.

Root’s unsuspend is the broadest of the three: it clears through the privileged call and through a shell pm unsuspend, so it covers more of those identities than the other two do. That is not a guaranteed rescue for a suspension another mode recorded. Making every unsuspend path clear all known suspender identities is tracked as an open follow-up.

If I remove an app from the Freezer, does it stay frozen?

No. Taking an app off the watchlist from the Freezer screen restores it first — unsuspended and re-enabled — so you never end up with an app that is frozen but no longer tracked. Its home-screen shortcut is disabled at the same time and carries a No longer frozen message: Android does not let an app quietly remove a shortcut you pinned yourself, so greying it out is as far as Thor can go.

If you have apps that are disabled but not on the list — frozen by another tool, or by an earlier version of Thor — the Freezer screen offers to import already-disabled apps, so you can find them and restore them.

Can I freeze a group of apps at once?

Yes — Freeze Profiles. Create named groups, put apps in them (an app can be in several), and freeze or unfreeze the whole group in one tap. There is also the main watchlist, which the Quick Settings tile and the launcher shortcuts operate on.

What does the Quick Settings tile do?

Freezes everything on your watchlist, in one tap from the notification shade. On Android 10 and newer, opening the shade shows how many apps are currently freezable; the tile subtitle that count sits in does not exist before that. The tile only freezes — unfreeze from the app or from a launcher shortcut.

Component control

What is component control?

Surgery one level below freezing. Freezing switches off a whole app; component control switches off a single piece of one — one activity, service, broadcast receiver or content provider out of the many an app declares.

Open any app’s App Details screen and the four component sections list what that app declares: Activities, Services, Broadcast Receivers and Content Providers. Each row carries its own actions — open it, copy its class name, stop a running service, or switch the component off.

The usual reason to want it: an app you otherwise like ships one receiver that keeps waking it up, or one activity you would rather nothing could launch.

What privilege does component control need?

Root, or a Shizuku that was itself started as root. A shell-mode Shizuku cannot do it, and Dhizuku cannot do it at all.

That is not a limitation Thor chose. PackageManagerService has a carve-out letting the shell uid change an app’s state at the package level, and it explicitly rejects the same call when it names a class — “Shell cannot change component state for …”. Reaching the same binder call by reflection arrives at the same check with the same uid, so there is no fallback to write. Force-opening an activity and stopping a service are root-only for the equivalent reason: the platform waives the export and permission checks for root and the system alone. Dhizuku is not a partial case but an empty one, because DevicePolicyManager has no component-enabled API at all.

Thor says which of those three is in the way, on the screen, rather than showing a row of dead switches.

One thing needs no privilege whatsoever: opening an activity that is exported and not guarded by a permission. Anybody may launch those, Thor included, so Thor simply does — no shell, no root, and the app sees an ordinary caller. That is why some rows say Open and others say Force open.

What does disabling a component actually do?

The component stays part of the app. It just stops running — and nothing tells the app that.

This is the sharpest tool in Thor for exactly that reason. Apps rarely expect a component to be unavailable, so a feature can break with no error message at all, or the app can crash on the path that needed it. There is no partial-credit outcome to inspect afterwards: the app still looks installed, enabled and perfectly normal while some piece of it silently does not work.

Thor asks before every disable because of that. The Don’t ask again this session checkbox lasts until Thor is killed rather than forever — deliberately, so that one tap cannot disarm the warning permanently.

Can I undo it?

Yes, and the details are worth knowing.

Thor keeps a record of every component it switched off, and restoring puts the component back to the state its developer shipped, not simply “on”. A component that ships disabled is restored to disabled — switching it on would invent a state the app never had.

Restore all covers every app, not just the one you are looking at. The button sits next to a count for the app currently open, so that surprises people; the confirmation dialog spells the scope out before anything happens. Covering every app is the point of keeping the record at all, because a component you switched off weeks ago in an app you have since forgotten is otherwise unfindable. It is every app for the Android user Thor is running in — records belonging to another user or a work profile are not touched.

A partial run says so — “Restored 6 of 9” — and leaves behind exactly the entries that did not fully complete, so pressing it again retries those rather than starting a second, different operation. An entry counts as done only when the component is back and its record is cleared, so a component that was restored while its record could not be deleted stays on the list for one more pass. Thor would rather retry something harmless than report a number your own screen contradicts.

Does it survive a reboot? An app update?

Both. Component state lives in Android’s own per-user package-restrictions.xml rather than in Thor, so it persists the same way freezing does. An app update keeps it too: the system drops only the names that no longer exist in the new APK.

Clearing the app’s data does not reset it, unless that app specifically asked for it to by declaring android:resetEnabledSettingsOnAppDataCleared.

Can the app just turn its component back on?

Yes. An app may change its own components’ state with no permission at all, and some do so routinely as part of how they work. Thor’s disable changes a component’s state; it is not a lock on it.

Thor does not pretend otherwise — it shows you when it happens. A component Thor recorded as disabled which is enabled now is labelled Changed elsewhere, with Forget offered to drop the stale record. The same label covers an app update or another root tool putting the component back.

Does Thor show components another tool disabled?

It shows their state, but it does not claim them. A component disabled by something else appears as disabled — Thor reads the real state from the system each time you open the screen — but it carries no Restricted by Thor badge, and Restore all does not touch it.

Thor only undoes what Thor did. Anything else is somebody else’s change, and quietly reverting it would be Thor asserting a preference nobody gave it. Reset to default is there for when you do want to clear such an override by hand.

Installing apps

Which file types can Thor install?

.apk, plus every common split-bundle format: .xapk (APKPure), .apkm (APKMirror), .apks (bundletool) and .apkp. Thor works out which one it is holding from the archive’s contents as well as its extension, then installs all the right pieces as a single session. No manual extraction.

My .xapk wouldn’t install.

Two separate causes, both fixed. Any APK containing a nested APK was being mistaken for a bundle (#207), and APKPure’s .xapk files use a zip layout that streaming readers cannot parse. Update to the current version.

I can’t open a .apks file from Samsung My Files.

Known and diagnosed (#161). Samsung’s file URIs carry no filename in the path, and the filter that matches by extension needs one to match.

Open the file from a different file manager. That is the fix, it costs you nothing, and it is what I would do. Sharing the file to Thor is not a way round it — Thor registers no share target at all.

If you would rather not change file manager, Settings has a switch called “Show Thor when opening any file”, off by default. It adds a second, much wider entry point: Thor becomes an option for every file Android cannot put a type to, which is not the same thing as every APK. You will see Thor offered for files it has no business opening, and it can do nothing useful with them.

Two honest caveats before you turn it on. It is aimed at exactly the shape #161 has — a file the system hands over with no name and no type — so it only helps if that is really what your file manager is doing, and I have not been able to confirm it on a Samsung device, only reason about why it should apply. And the filter cannot be narrowed, because what it exists to catch is a handover carrying no name and no type — there is nothing in it left to match on. Putting an extension pattern back would rebuild the filter that already misses these files. So it is either this broad or it is not there, which is why it ships switched off rather than on.

What is “Fix Store”?

It makes Android believe an app came from the Play Store.

Thor reads the app’s own installed APK paths — the single APK, or every split if it is a bundle — straight off the device, then reinstalls those exact files with the installer record set to com.android.vending. Nothing is downloaded and nothing is replaced: it is the same app you already have, reinstalled from itself with a different name on the receipt.

That matters because plenty of apps ask Android who installed them and behave differently when the answer is not Play — licence checks fail, expansion files will not download, some DRM refuses to start, some apps simply decline to update. Fix Store makes the system record say what those checks expect.

It works in all three privilege modes. Thor refuses to do it to itself.

Can Thor install without root or Shizuku?

Yes, through Android’s standard installer — you will see the usual confirmation dialog. The one thing that is not possible unprivileged is downgrading, because the OS refuses it outright. Thor tells you that rather than failing mysteriously.

Privacy, licence and distribution

Does Thor collect any data?

No. No analytics, no crash reporting service, no telemetry, no ads, no trackers. Everything Thor does happens on your device.

That is checkable rather than a promise: exactly one file in Thor’s own code opens a network connection, data/repository/StoreRepositoryImpl.kt, and it belongs to the Extension Store. The store build also carries Google Play Billing, which is Google’s code rather than mine and opens a connection to Play when the app opens — the foss build has no such library.

Then why does Thor ask for INTERNET permission?

For the Extension Store — downloading its catalog and the extension APKs, over HTTPS from GitHub. If you never open the Extension Manager, the foss build makes no network request at all. Nothing about you, your device or your installed apps is put into the request — though GitHub, like any web server, sees the IP address it arrived from.

The Play (store) build does one more thing: it opens a Google Play Billing connection when you open the app, to fetch the support tiers and check whether you already hold one. That runs through the Play Store app rather than through Thor’s own code, and none of it reaches me. The privacy policy has the detail.

Why does Thor need to see all my installed apps?

QUERY_ALL_PACKAGES is what makes Thor an app manager. It cannot list, freeze or install apps without it. The list never leaves your device.

What licence is Thor under?

GPL-3.0-or-later. The complete source is on GitHub. You can read it, build it, audit it, fork it.

Where can I get Thor officially?

Three channels:

• Google Play
• IzzyOnDroid
• GitHub Releases

Is Thor on F-Droid?

Not yet. Thor is on IzzyOnDroid, which is a separate repository you add to an F-Droid client — not the main F-Droid repo. The two are easy to confuse, so to be exact: if you search F-Droid’s default repository for Thor, you will not find it until you have added IzzyOnDroid’s repo.

Adding it takes one step. In your F-Droid client, add this repository, then search for Thor.

https://apt.izzysoft.de/fdroid/repo

A listing in the main F-Droid repository is planned.

What’s the difference between the Play version and the FOSS version?

One functional difference: the Support Developer flow. The Play (store) build includes Google Play Billing; the foss build ships a stub with billing permanently unavailable. Every app-management feature is the same in both.

They are not byte-for-byte twins otherwise — the FOSS flavour also carries a -foss suffix in its version name and an extra ProGuard rules file — but nothing you can do with one is missing from the other. Both now bundle the same eight locales: the locale filter that used to apply only to the FOSS flavour is applied to every variant, because the Play build no longer uses per-locale splits. If you are on the FOSS build, or you would simply rather not send a cut to a payment processor, the direct routes are below.

Are the builds reproducible?

For the foss build, IzzyOnDroid rebuilds it from this source and publishes it with their reproducible-build badge when the result matches the APK on the release page. Their check, not my claim — and that is the whole point of the flavour: you do not have to take my word that the binary matches the code.

The store build is not reproducible, by design. CI uploads an app bundle to Play, and Play generates the install for your device from it and signs what it generates — so what Play installs is not a file that was built here.

Baseline profiles are deliberately kept out of the build entirely. They change the emitted bytecode and would break that verification.

Is this build official?

Official Thor comes from the three channels above. Anywhere else — a mirror, an aggregator, a repackager — check the signing certificate against the APK attached to the GitHub release before you trust it. Thor’s name and logo are trademarked even though the code is free software — anyone may fork the code, nobody may ship it under Thor’s identity. An unofficial build using the name could have anything added to it.

Can I support development?

Yes, and it is appreciated. Thor is written by one person in their own time. None of these routes change anything about the app: there is no paid tier, no unlocked feature, and no difference in what you get.

• GitHub Sponsors — the one I would point you at first. Lowest fees, recurring or one-off, and it sits next to the code.
• Patreon
• Ko-fi
• Buy Me a Coffee
• PayPal

Thor’s own Support Developer screen carries three of them — GitHub Sponsors, Patreon and PayPal — and opens each in your browser rather than through in-app billing. Both builds show those three; the Play build adds a second tab with its billing tiers.

Things worth knowing before they surprise you

Does the permission filter show what an app has, or what it can ask for?

What it can ask for. The filter reads declared permissions, so an app appears under “Camera” even if you denied it. That is the useful question when you are auditing a device — what on here could ask for my camera? — but it is not the same question as what has access right now.

Why does per-app cache size show 0 under Shizuku?

Thor measures it by reading the app’s own cache directory, which needs root. Shizuku and Dhizuku read zero rather than guess. Clearing the cache still works in every mode.

Why can’t Thor reboot my device under Shizuku?

Rebooting needs root. Shizuku and Dhizuku return an explicit error rather than pretending to succeed.

Will the biometric lock ever lock me out?

No. Thor refuses to arm the lock on a device that cannot satisfy it, and tells you exactly what is missing. If a restored backup brings the setting back to a device that could never satisfy it — API 28 with no fingerprint sensor, where no enrolment would help — Thor turns it off itself. Where enrolling a screen lock or a fingerprint would fix it, the lock stays armed and Thor sends you to enrol one instead.

One thing to know on the oldest supported release: on Android 9 the lock accepts fingerprint only, because the API 28 prompt has no PIN fallback. A device without a fingerprint sensor cannot use it there at all.

Is there a process manager showing what’s running and using RAM?

Not yet, and it is harder than it looks. Since Android 8 an app can only see its own process. A real process manager would have to parse dumpsys or top output, which is brittle and varies by OEM, and it would not work under Dhizuku at all. It is being considered as an extension (#55).

Will Thor scan APKs with VirusTotal?

It is in development as an extension, not as part of Thor itself (#209).

That is deliberate. Scanning means sending a file hash to a third party, which is exactly the kind of thing this app exists not to do quietly. Keeping it in an extension means it ships only if you choose to install it, the network access belongs to the extension rather than to Thor, and anyone who wants none of it is unaffected by default.

Can Thor back up app data?

Not yet — it is planned. Exporting APKs and split bundles works today; backing up actual app data, the root-only copy of an app’s private storage, is the part still being built.

Still stuck?

• Bug or feature request — GitHub Issues, with your Android version, device and privilege mode. Those three answer most of a bug report before anyone has to ask.
• Extensions — read the extensions policy first.
• Everything else — the Telegram channel. Release announcements go out there, and it is the fastest way to reach me about anything that is not a bug worth tracking.