AppOpsNext

English | 简体中文

AppOpsNext helps protect your privacy with finer control over app permissions, access history, and live monitoring. It runs through Shizuku without root and helps answer four questions:

• Settings: What have I allowed?
• Activity: Which apps are accessing what?
• Outcomes: Did the system allow or deny the access?
• Listeners: Which other processes are watching for permission changes?

Download APK · Report an issue · Build status

Official APKs are published ONLY on GitHub Releases. No guarantee is made for APKs from any third-party source.

Preview

Highlights

• Permission controls. Set AppOps such as camera, location, and clipboard per app, then read back each change to verify it.
• Templates. Apply saved rules to several apps or automatically to new installs.
• History. Filter by time and app, including counts of denied attempts. Save individual records on the device beyond Android's seven-day retention period.
• Access monitoring (experimental). Watch chosen app permissions, get reports of allowed and denied accesses, and review them in a log.
• Permission change listeners (experimental). See which processes are registered to watch for permission-setting changes.
• Limited privileged access. Use a fixed set of AppOps commands and interfaces, with no arbitrary shell execution. Records stay on the device; only the update check uses the network.

What you can do

Install and get started

Requirements

• Android 15 or later (API 35+).
• Shizuku 13 or later, running and authorized for AppOpsNext.
• The bundled native backend targets ARM64. Other CPU architectures have not been verified.

Root is not required when Shizuku is started through ADB or wireless debugging. AppOpsNext still needs Shizuku for privileged operations.

1. Install and start Shizuku.
2. Download the APK from the latest release and install it.
3. Open AppOpsNext and grant access when Shizuku prompts you.
4. Choose an app, select an operation, and review the confirmation before applying a change.

Use Templates for reusable rules and History to review system records. Automatic template application for newly installed apps is optional; configure its rules before enabling it. The first reconciliation establishes an existing-app baseline; it does not retroactively apply the template to every installed app.

For updates, install the new release APK over the existing app to retain its settings. If Shizuku stops after a reboot or authorization is revoked, restore the connection before making new privileged reads or changes. Saved history remains viewable without that connection.

Tested environments

These results describe the tested environments, not compatibility with every OEM ROM. See backend compatibility notes for the evidence and known limitations.

How history works

History comes from records retained by Android. AppOpsNext prefers individual access records and falls back to time-bucketed system statistics where needed, such as for clipboard access. Retention and timestamp precision depend on the device; this is not a complete, independently recorded audit log. Denied attempts are shown as interval counts alongside accesses, including when individual access records exist. Interval boundaries are labelled; they are not individual rejection timestamps. Aggregate accesses are not counted again when discrete records are available. The seven-day chart continues to count accesses only.

• Each operation's last successful result is saved locally and restored when the app reopens, with its update time shown on the page.
• Returning within five minutes reuses fresh results. Older or missing results are read when the history screen is visible, the app is in the foreground, and the backend is connected; periodic refresh follows the same conditions.
• Manual refresh bypasses the freshness check. Results update as each operation finishes, and a failed read keeps the previous result with an error message.
• Before the first successful read, the page distinguishes unloaded history from a genuine zero count.

The saved result is a cache of the latest successful read. It is stored in the app's private storage and excluded from Android backup; clearing app data or uninstalling removes it.

History persistence

Android keeps individual records for seven days; older accesses survive only as interval counts without their times. With Settings → History persistence turned on, AppOpsNext keeps the individual records of the permissions chosen there (camera, microphone, and precise and approximate location, the ones with individual records):

• The choice starts from the history page's selection and is independent of it afterwards.
• Permissions the history page shows are saved as it refreshes. The rest are saved when the app is opened, at most every six hours. When reads and writes succeed, opening the app at least once every seven days avoids gaps caused by individual records expiring.
• Periods that were not saved are filled from interval counts within 30 days. An interval that partly overlaps saved records counts only the accesses beyond them, which can be slightly high because Android may merge accesses into one record.
• Up to 100,000 records are kept, oldest removed first. They stay on the device, are excluded from backup, and can be deleted by date range or all at once.
• A saved file that cannot be read, for example after a downgrade, is left as it is and saving pauses until it is deleted, rather than being overwritten.

Denied attempts are never saved as individual records by Android. To record them one by one, use the experimental access monitor and its log.

What an AppOps change means

AppOps and Android runtime permissions are separate layers. Setting an AppOp to Allow cannot grant a missing runtime permission. Android or an OEM policy may also normalize or reject a requested mode. AppOpsNext explains runtime-permission failures and provides a route to the app's system settings.

Changes use a verified transaction:

Read and check the original state
  → Write the requested mode
  → Read back and verify
  → On failure, attempt to restore and verify the original state

Manual, batch, and automatic-template writes share a serialized transaction queue. A command completing is not sufficient to report success; verification and restoration outcomes are surfaced separately. Restoration is attempted, not guaranteed.

UID-scoped changes can affect multiple apps sharing that UID. The confirmation screen identifies those packages. Automatic scope fallback is constrained to avoid silently extending a change to other apps. Batch results report each target separately.

Permissions and network use

The update check reads one public GitHub endpoint and nothing else. It never forces an update, never downloads or installs anything, and never shows a popup or a notification about it: an available version appears next to the app version in Settings and nowhere else. No user data of any kind is uploaded.

The diagnostic report is never sent anywhere on its own. It is assembled on the device and copied to the clipboard only when you ask for it, and sharing it is entirely your decision.

Troubleshooting

• Cannot connect: confirm Shizuku is running and AppOpsNext is authorized, then check Settings → Connection and diagnostics. The app tries its bundled native backend first and Shizuku UserService if native startup fails.
• A mode will not apply: check the Android runtime permission and the reported verification result. Some system restrictions cannot be overridden through AppOps.
• History looks old or incomplete: check the saved update time, refresh manually, and verify the connection. Android controls which records exist.
• The access monitor reports nothing: it is experimental and depends on a privileged interface that not every ROM provides. Turn it on again and read the registry check result; it can be confirmed, unconfirmed or failed, and partial registration and callback parsing errors stay visible. Matching registrations do not prove callback delivery. Enable notification permission and the monitoring notification channels. Also confirm at least one app and operation are selected, since nothing is watched by default.
• Monitor counts differ from app calls: the count represents reported events, which Android may emit more than once for one call. A monitoring point may also carry a reporting interval, in which case anything inside that interval is not reported at all. Only the selected apps in the current user profile are included. The monitor is not an exact API-call audit log.
• A busy permission fills the notification: an operation such as location is reported once per delivered fix, so watching one without an interval produces a report per second. Give that monitoring point a reporting interval in Settings, Experimental, Monitor settings, Monitoring points.
• "Only when off screen" still reports what you can see: the monitor reads the process state AppOps keeps for the app, and treats anything other than the app being on screen as off screen — including a foreground service. If the state cannot be read at all, the access is reported rather than dropped, so a monitor that cannot check something never goes quiet.
• The monitor stops after a force stop: a force stop removes its service and prevents Android from restarting it. Opening AppOpsNext again brings it back while the switch is still on.
• The monitor stops after the screen has been off for a while: some vendors' battery optimisation or background management ends the app's process, and a foreground service does not survive it either. This is outside the app's control. To run the monitor for long periods, exclude AppOpsNext from battery optimisation in system settings and lock it in the recents list. Opening the app again restores the monitor.
• Reporting a problem: include the device, Android/ROM version, reproduction steps, and a diagnostic report from Settings. Review and redact that report before posting it in a public issue.

Build from source

Use JDK 17, Go 1.24+, and the Android SDK with platform 36 installed. The repository includes the Gradle wrapper. Set JAVA_HOME to JDK 17 and point local.properties (sdk.dir) or ANDROID_HOME to your SDK installation.

# Optional: set this if Go is not on PATH.
# export GO_EXECUTABLE="/absolute/path/to/go"

./gradlew :app:assembleDebug

Output: app/build/outputs/apk/debug/app-debug.apk. Gradle also cross-compiles the bundled daemon for Android ARM64; a separate NDK build is not required. Debug builds keep the screen awake while the app is in the foreground and use a different signing identity from public releases.

Run the same checks as Android CI:

(cd daemon && "${GO_EXECUTABLE:-go}" test ./...)
./gradlew :app:testDebugUnitTest :app:lintDebug :app:assembleDebug --no-daemon

Signed release builds

Public release signing material is excluded from Git. The configured release build expects .signing/appopsnext-release.keystore, alias appopsnext, and APPOPSNEXT_STORE_PASSWORD / APPOPSNEXT_KEY_PASSWORD in the environment:

./gradlew :app:assembleRelease

Output: app/build/outputs/apk/release/app-release.apk. For your own distribution, supply your own keystore. Updating an existing installation requires the same signing identity. Maintainer validation and publishing steps are in the release checklist.

Code and documentation

Android packages live under app/src/main/java/dev/izumi/appopsnext/.

Further reading: Architecture · Privileged backends · Device findings · Release checklist.

License

AppOpsNext is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Copyright (C) 2026 1zumiii.

Third-party components keep their own licenses: the Shizuku API is MIT, and the Phosphor Icons are MIT; AndroidX and Jetpack Compose are Apache-2.0. These are compatible with GPL-3.0. The Phosphor notice is included in the app at app/src/main/assets/licenses/phosphor-icons.txt.

Project background

AppOpsNext is an independent clean-room implementation inspired by the general product idea and workflows of the historical App Ops application (rikka.appops). It is not a fork, port, modified build, or official successor.

It includes no legacy application source, decompiled code, assets, branding, or configuration data, and does not require or provide migration from that app.

AppOpsNext is not developed, endorsed, or supported by RikkaApps or the original App Ops author. Its use of Shizuku does not imply affiliation with its maintainers. “AppOps” refers to Android's built-in system service.

简体中文

• 1.6.0 对主要页面及相关操作界面进行了现代化重构，可直接覆盖安装 1.5.0。

• 历史页「涉及应用」现在默认按访问与拒绝的总次数排序，也可切换其他排序方式。

English

• 1.6.0 refreshes the main screens and related views with a more modern design. It installs directly over 1.5.0.

• The Apps involved list in History now sorts by total accesses and denied attempts by default, with other sorting options available.

SHA-256 (AppOpsNext-v1.6.0.apk): afca931497d4f1f3372d26a0c4ea83a19924bef0db3f2223b6a5b75efec98713