Irene Okpanachi is a Features writer covering Android devices, laptops, portable projectors, VR headsets, software, and AI recorders for Android Police and Talk Android.
She has five years' experience across the Tech, E-commerce, and Food niches, with over 1,000 posts published. The Tech space is where she geeks out most, particularly Android.
Irene holds certifications in Graphic Design (HerTechTrail), Writing in Plain Language (LinkedIn), and English for IT (Cisco Networking Academy).
Beyond writing, Irene is a gamer, singer/songwriter, food lover, and a Jack of all trades.
Not everything is what it seems, and I keep that in mind when auditing apps. I have half a mind to be ignorant and the other half to be skeptical of every app I install.
Even the best apps keep more about you than their privacy policies alert on. So, you can never be too careful with anything installed on your Android phone.
That's why I make time to tear down apps and review the data they store, with help from Google Gemini. Here's how it works.
App permissions are only the tip of the iceberg
The body is ocean-deep in hidden background processes
Most people rush to install apps and tap Allow on the pop-ups that follow when running them. App downloads aren't instant for me, given the Trojan horse problem.
The Trojans pulled a wooden horse through their own gates, and the soldiers hiding inside opened the city from within to attack. Apps work similarly, so if I invite one in, I'm responsible for every dangerous permission I grant.
It's why I always check the permissions under About this app on the Play Store. I scroll to the bottom and tap See more beside App permissions.
The Play Store doesn't flag or explain dangerous permissions; it just lists them in plain text. But the common red-flag permissions are:
- Read or receive text messages (SMS): Apps are able to read incoming texts.
- Accessibility: Apps receive full control to read the screen and tap buttons for you.
- Display over other apps: Apps can draw windows over your screen.
- Install unknown apps: Allows apps to download files from outside the Play Store, which may introduce malware to your phone.
- Query all packages: A search permission allowing apps to scan installed apps and map out your setup.
- Device admin: Apps receive high-level system control.
- Background location and call logs: Tracks your physical location all day and logs who you call.
No rule requires you to deny all of these permissions. My criterion is that they support an app's main feature. A messaging app needs my contacts and possibly the microphone, but a flashlight app has no justifiable reason.
Likewise, a wallpaper app has no business querying all packages, even if it claims to need permission to detect my launcher or match my app icons.
Since Android 11, apps no longer need broad permission to inspect your entire device. They must query only the specific apps they interact with.
I cracked open Android's sandbox
Sifting through the raw data was messy business
Auditing an app's stored data means looking inside the /data/data/ directory, which is Android's protected storage vault for each app's files, settings, and runtime data.
To access it, I connect my phone to my PC with a USB cable and enable USB debugging in Developer options. Go to Settings > About phone and tap Build number seven times until a message confirms you're a developer.
The Android Debug Bridge (ADB) audit needs this feature to access deeper content, and Microsoft's free code editor, Visual Studio Code, to read files.
I had VS Code installed, but you can download it from the official website.
I also have basic coding knowledge, especially in shell commands and Structured Query Language (SQL), but I still kept Gemini on standby to make sure I didn't miss any steps.
You can do this even without programming knowledge.
I installed Google's Android SDK Platform-Tools to get ADB and ran adb devices in VS Code's terminal.
You can also use your PC's native terminal, but I prefer the editor because it turns raw output into a searchable, readable workspace where I can analyze extracted files and run ADB commands side by side.
Android locks each app's data away to protect your privacy, so a normal command won't get you in. So, I accessed my phone's command line and went to the app's folder.
Then I used the pull command to copy its database and settings files to my PC and opened them in VS Code. Then a free extension enabled me to search the databases.
I repeated the process for every app I wanted to inspect. I only needed to do the setup once, so for later apps I pointed the pull command at a specific package directory.
Your favorite sideloaded apps could be loaded with risks
It's best to diffuse them before they blow
I tested Snaptube, a popular sideloaded media downloader removed from the Play Store. Pulling its /data/data/ sandbox failed with a package not debuggable error, so I bypassed it without root.
Then I installed Apktool through Homebrew and decompiled the APK to inspect its raw AndroidManifest.xml in VS Code. The decoded manifest revealed several high-risk requests:
- REQUEST_INSTALL_PACKAGES to install external APKs.
- SYSTEM_ALERT_WINDOW to draw overlays over other apps.
- MANAGE_EXTERNAL_STORAGE for broad file access.
- QUERY_ALL_PACKAGES to inventory installed apps, and KILL_BACKGROUND_PROCESSES.
The app also enables android:usesCleartextTraffic="true", which permits unencrypted HTTP traffic.
Background services like KeeperService and RebirthJobService restart killed tasks, and system receivers trigger on boot, unlock, or charging.
It even embeds ad and analytics software development kits from ByteDance, InMobi, Mintegral, Vungle, SensorsData, and Meta.
Code decompiling guide:
Initial Setup & Dependencies (One-time setup)
# Install Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install adb
brew install android-platform-tools
# Install APK decompilation tool
brew install apktool
# Step 1: Locate the target app package
# Verify device connection
adb devices
# Find [PACKAGE_NAME] under Settings > Apps > [App name] > App info
adb shell pm path [PACKAGE_NAME]
# Step 2: Extract app files / Uncover permissions
adb shell "run-as [PACKAGE_NAME] cp -r /data/data/[PACKAGE_NAME] /sdcard/Download/app_data"
adb pull /sdcard/Download/app_data [LOCAL_WORKSPACE_FOLDER]/data/
code [LOCAL_WORKSPACE_FOLDER]/data/
# Step 3: Decompile for Hardened Apps (If run-as fails or for full analysis)
# Create a local workspace folder
mkdir -p [LOCAL_WORKSPACE_FOLDER]
# Pull the base APK (use the exact path from Step 1)
adb pull [APK_PATH_FROM_STEP_1] [LOCAL_WORKSPACE_FOLDER]
# Decompile the APK to decode AndroidManifest.xml and resources
apktool d [LOCAL_WORKSPACE_FOLDER]/base.apk -o [LOCAL_WORKSPACE_FOLDER]/decompiled/
# Open the decompiled project in VS Code
code [LOCAL_WORKSPACE_FOLDER]/decompiled/
Not every audit takes this much effort. Simpler apps let you copy their data files with standard backup commands. Hardened or production-signed apps block access, so you must decompile them.
My patience for tedious work has dropped over the years, so I'm thankful for shortcuts like vibe coding. Pasting my database results into Gemini saved me two to four hours of scanning obscure tables and settings files.
Unearth your phone's buried secrets
Seeing how many flags were stored in different app databases became the catalyst for my auditing habits across different areas of digital life beyond privacy and security.
I can confidently say that seeing the dark corners of my everyday tools has kept me from being blindsided by attacks and hidden costs.
Plus, I've thwarted data hoarders and battery killers before they compromised my digital space.