An Android App for preserving user privacy
HideDroid is an Android app that allows the per-app anonymization of collected personal data according to a privacy level chosen by the user.
In a nutshell,HideDroid collects all the network traffic generated by the invocation of API calls belonging to analytics libraries, and extract the exported data.
Then, it anonymizes the personal and device data using a generalization technique, and the data related to the user’s behavior using an approach based on the concept of local differential privacy, in a way that preserves as much data semantics as possible.
Finally, the anonymized data are sent to the expected recipients by mimicking the original network calls.
| 5.x or lower | 6.0 | 7.x | 8.x | 9.0 | 10.0 | 11.0 | 12.0+ |
|---|---|---|---|---|---|---|---|
 |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
Android 10 and newer (API 29+)
On modern Android versions the app can no longer write certificates to the system trust store (/system/etc/security/cacerts). The recommended setup is:
- Install the HideDroid CA as a user certificate from the app (Settings -> Security -> Privacy -> Install certificate from storage). After installation, target apps must be repackaged by HideDroid so their traffic is intercepted.
- If your device is rooted and you want system-wide trust without repackaging each app, export the certificate and install it through a Magisk module (e.g., Move Certificates or any custom CA Magisk module that injects certificates into the system store).
The app exposes two actions from the certificate status dialog:
- Install CA in user store: triggers the system KeyChain installer.
- Export CA certificate: lets you choose a folder and saves
HideDroidSample_ca.crt, which can then be installed manually or pushed to a Magisk module.
Android 9 and older (API 28-)
On older versions the app can still install the CA in the system store directly when the device is rooted. Use the Install CA in system store option from the certificate status dialog.
In order to read the endpoints contacted by a target app, HideDroid can repackage the target app so that the HideDroid TLS certificate, installed as a user certificate, is trusted by that app. The repackaging step adjusts the app's network security configuration to accept user-installed CAs, allowing HideDroid to intercept and inspect its TLS traffic. Repackaging runs entirely on-device via a bundled apktool 3.x with a native aapt2 build for arm64-v8a/armeabi-v7a/x86_64 (32-bit-only x86 devices aren't supported).
Repack and No repack (track without modifying the app) can be chosen directly from the app list, per app, and switched at any time; the list can also be filtered to All / Tracked / Not tracked. Before a repack starts, HideDroid asks where to write the decompiled/rebuilt APK (defaults to the app's private storage and is remembered afterwards), and shows apktool's decompile/build/sign progress live in a popup, which also surfaces the actual error if a repack fails.
Alternatively, when HideDroid asks to modify the app, you can choose "Try without modification" (same as No repack in the app list) to track the app without repackaging it. In this case cleartext HTTP traffic is always intercepted and anonymized, while TLS traffic can be read only if the app already trusts user-installed certificates (for example apps targeting an SDK lower than 24, apps whose network security configuration already accepts user CAs, or any app when the HideDroid CA is installed in the system store on a rooted device).
In this specific case, all data read by HideDroid never leave the device or the app itself: traffic interception, data extraction, and anonymization are performed entirely on-device.
Repackaging only makes the target app trust the HideDroid CA at the network security config level (i.e. it accepts user-installed certificates). If the app implements certificate/public-key pinning in its own code (e.g. OkHttp CertificatePinner, TrustManager/HostnameVerifier overrides, Network Security Config <pin-set>, or native pinning in Flutter/Xamarin apps), it independently verifies the server certificate against a hardcoded pin and will reject the HideDroid CA regardless of the trust-store change, so its TLS traffic cannot be intercepted.
HideDroid does not detect or bypass pinning: repackaging will still "succeed" (the app installs and runs), but pinned connections will simply fail or refuse to use the proxy, and no data will be read for that app. Defeating pinning requires app-specific reverse engineering (e.g. patching the pinning check with a tool like Frida/objection) that is outside HideDroid's scope. Cleartext (non-HTTPS) traffic from the same app is unaffected and is still intercepted normally.
The Traffic view (navigation drawer) shows the requests captured by the VPN interceptor in near real time: host, package, HTTP method, timestamp and a color-coded status. The list can be filtered by status, limited to the newest 50–1000 items (remembered across restarts) and the current filter exported as CSV to the app's private storage.
| Status | Meaning |
|---|---|
| Normal | Host not in the tracker list and the request body contains no personal data. Forwarded untouched, only logged. |
| Private | Host is not a known tracker, but the request body contains personal data (name, email, phone, device identifiers, location, ...) matched against HideDroid's private-field list. The body is stored and anonymized like tracker traffic, and the host is recorded so it stays flagged. |
| Tracked | Known analytics/tracker domain (bundled trackers.json list, or a host enabled manually). The request body is anonymized before forwarding. |
| Blocked | Host blocked by the user. The request is never forwarded: the app receives a synthetic empty response (204 No Content), so nothing ever reaches the real server. |
- Tap an entry to block its host (for all apps, or for the originating app only). Tapping an already-blocked host offers to unblock it.
- Long-press an entry to anonymize the host from now on: it is added to the tracked domains and enabled.
The same controls are available from Settings → Domain settings, where each domain's anonymization/blocking state and per-app restrictions can be reviewed.
More details about HideDroid can be found in the paper You can’t always get what you want: towards user-controlled privacy on Android:
@ARTICLE{caputo2021cant,
author={Caputo, Davide and Pagano, Francesco and Bottino, Giovanni and Verderame, Luca and Merlo, Alessio},
journal={IEEE Transactions on Dependable and Secure Computing},
title={You Can't Always Get What You Want: Towards User-Controlled Privacy on Android},
year={2022},
doi={10.1109/TDSC.2022.3146020}
}Accepted on IEEE TDSC journal.
Questions, bug reports and pull requests are welcome on GitHub at https://github.com/0xdad0/HideDroid.