NOIR audits what your Android phone could leak, over adb and without root, and every fix it applies can be undone

NOIR is a free desktop tool that connects to an Android phone over adb (Android's USB debugging bridge) and produces a report on what the phone's apps could leak and where that data could go. The repository was created on October 31. When we checked on November 4, GitHub's API showed about 1,770 stars and 137 forks. Trendshift counted about 1,670 stars gained between Oct 31 and Nov 4, including more than 1,000 on November 2 alone. The code is Kotlin under the MIT license, and the latest release is v0.2.5, published November 2.

Why it matters: Android's permission screens tell you what an app may access. They don't tell you which ad, telemetry or analytics servers that app is built to talk to. NOIR puts those two lists side by side, without root and without uploading anything, so you can decide which apps to restrict.

What it checks

According to the README, NOIR:

• Lists apps that hold internet access plus a sensitive permission, along with what each one has actually been granted.
• Pulls URLs out of each app's code on the phone itself, using unzip and strings, so only a few KB per app comes back to your computer instead of the whole APK.
• Sorts those domains by vendor and purpose (telemetry, ads, location, input method and so on) and gives each app a risk score.
• Maps permissions to the data they expose: location, contacts, SMS, call logs, microphone, camera, screen, your installed-app list and device IDs. It then pairs that data with the reporting domains.
• Merges shared-UID system packages such as android.uid.system, so permissions granted to a shared identity are counted for every app that uses it. HotRepo's write-up singles this out as a smart design choice.
• Reads manifests for exported components that have no permission guard, cleartext traffic, backups allowed, debuggable builds and target SDK level.
• Goes deeper on request. noir deep <package> pulls one APK and uses the jadx decompiler to look for risky calls such as Runtime.exec and DexClassLoader.

The fixes, and how to undo them

By default, a scan is read-only. noir auto --apply changes only app-ops settings, the per-app permission switches underneath Android's settings screens. NOIR writes a rollback.txt file, and the README says each change can be reset. Uninstalling requires an explicit --aggressive flag. Even then, it removes the app only for the current user (--user 0) and first prints the pm install-existing command that brings it back.

For blocking, NOIR doesn't change your phone's DNS. It exports a domains.txt file you can load into Pi-hole, AdGuard or your router, with domains split into trackers, ones to review and ones apps need to work.

Try it

You need Android platform-tools (adb) and USB debugging turned on in your phone's developer options. On first run, NOIR offers to download adb and jadx into ~/.noir/tools. The README marks macOS (Intel and Apple Silicon), Windows 10/11 and Debian/Ubuntu as supported. Portable builds on the releases page bundle their own Java runtime. To build from source you need JDK 17+:

git clone https://github.com/Verlintas/NOIR
cd NOIR
./gradlew :cli:installDist
./cli/build/install/noir/bin/noir doctor   # check the phone connection
./cli/build/install/noir/bin/noir scan     # read-only audit
./cli/build/install/noir/bin/noir ui       # browse the results

Running noir with no arguments starts a wizard.

Read the fine print

• Capability is not proof. The README is upfront that findings are static: they show that an app holds a permission and contains an endpoint, not that it ever sent your data there. Proving that takes network-level evidence.
• The scan is a lower bound. The project page says NOIR scans only each app's base.apk, so code in split APKs can be missed.
• System apps keep coming back. Preinstalled apps can be restricted or disabled but not truly removed. OTA updates or a factory reset can bring them back, which is why NOIR suggests app-ops or DNS blocking for them instead.
• Reports are personal. A report can contain your package list and endpoints from your phone. Review it before posting it in an issue.
• It's very young. The README's roadmap still lists a GUI, configurable YAML rules and signed scan results. The project page says it has been tested on Xiaomi HyperOS, AOSP emulators and vendor ROMs, and that unsigned builds trigger OS warnings. iOS isn't supported.

The project says the tool has no telemetry, accounts or analytics. The only network traffic it describes is the one-time download of adb and jadx during setup.

Who should try it: anyone with a phone full of preinstalled vendor apps, and anyone who already runs Pi-hole or AdGuard and wants a list built from their own phone instead of a generic one. Leave USB debugging off when you're done.