
Unlocking Android Secret Codes: How I Built a Bash Script to Find Codes on Moto G Play and Beyond
Table of Contents
TL;DR
- Android phones hide secret codes that unlock hidden menus and settings XDA Developers — Android Hidden Codes (2023).
- I wrote a Bash script that uses ADB shell to automatically discover codes on a non-rooted Moto G Play running Android 13.
- The script prints each code as it finds it and writes a timestamped report file.
- Use the report to dial codes safely; many can reveal engineering mode, sensor tests, or telecom menus.
- Run it with caution—some codes trigger wipes or unexpected reboots.
Why This Matters
I still remember the first time I was handed a brand-new Moto G Play and asked to find its hidden engineering menu. The manual was thin, the internet was full of vague phone-model lists, and I had only the device and a laptop. That frantic search cost me hours of frustration—and a growing sense of defeat.
For Android developers, forensic analysts, and security researchers, secret codes are a double-edged sword. On one side, they provide instant access to diagnostics, sensor tests, and hidden features that would otherwise require a deep dive into the OS source. On the other, a single wrong code can wipe user data or reboot the device unexpectedly.
Because manual hunting is slow, error-prone, and impossible to scale across fleets of devices, I set out to write an automated solution that would systematically scan every installed package for android_secret_code entries and collate the results into a tidy report.
Core Concepts
At the heart of this automation are three Android tools:
- ADB shell – the command-line bridge that lets a PC talk to a device. It exposes a Unix shell and many system services, and is the gateway to any secret code discovery you can dream of. ADB is described in the official Android SDK docs as “a versatile command-line tool that lets you communicate with a device” Android SDK — Android Debug Bridge (adb) (2023).
- Package Manager (pm) – an API exposed via ADB that lists and dumps application metadata. adb shell pm list packages returns every package that is visible to the current user, while adb shell pm dump
produces a verbose dump that contains activities, providers, and, crucially, any android_secret_code declarations embedded in the manifest. - grep – a text-filter that allows us to cherry-pick lines containing a particular pattern. When you pipe the pm dump through grep -i android_secret_code, the tool spits out every occurrence of the secret-code scheme.
The secret-code scheme itself follows a simple MMI pattern: android_secret_code://
The script I built, named secretcodes.sh, stitches these pieces together. It loops over all installed packages, dumps each one, greps for android_secret_code, extracts the numeric payload, and prints it to the console while writing a timestamped text file for later analysis.
Here’s a snapshot of the table that compares the three key ADB-based commands I use:
| Parameter | Use Case | Limitation |
|---|---|---|
| adb shell pm list packages | Enumerate every package visible to the current user | May miss hidden or system-level packages that are invisible to the shell session |
| adb shell pm dump | Dump full manifest data, including secret-code intent-filters | Large output; slower on devices with many apps |
| adb shell dumpsys sensorservice | Retrieve live sensor status for Accelerometer and Magnetometer | Requires proper permissions; not all OEMs expose the same sensor metrics |
How to Apply
Below is a practical walkthrough that you can copy-paste into a terminal. I’ve tested it on a Moto G Play (2023) running Android 13, but the same steps work on any non-rooted Android phone that exposes ADB.
Enable Developer Options and USB Debugging
- Open Settings → About phone → tap Build Number seven times.
- Return to Settings → System → Developer Options → toggle USB Debugging.
Install Android Platform-Tools
- On Linux/macOS: sudo apt-get install android-tools-adb or brew install android-platform-tools.
- On Windows: download the ZIP from the official site and add the platform-tools folder to your PATH.
Connect the device
adb devicesIf you see your device ID, you’re good.
Clone the repo and make the script executable
git clone https://github.com/douglas/fresh-habian.git cd fresh-habian chmod +x secretcodes.shThe repo also contains a forensics folder with related Bash utilities.
Run the script
./secretcodes.shThe script will:
- Print the device manufacturer, model, and Android 13 version.
- Loop through every installed package, dumping and grepping.
- Emit any found secret codes to stdout.
- Write a file named secret_codes_YYYYMMDD_HHMMSS.txt in the current directory.
Validate the codes
- Open the generated file, copy a code, and dial it from the phone’s dialer.
- Observe the resulting menu or action. If the code triggers a warning or a system wipe, abort immediately.
Optional: extend the script
- Add your own regex if you discover a new pattern.
- Use grep -i motorola to limit the search to Motorola packages, which dramatically speeds up the scan.
The output on my Moto G Play looked like this:
Device: Motorola Moto G Play (Android 13)
Found 4 codes:
2486 – Engineering mode (CQA menu)
828282 – Telecom developer menu (Enhanced call blocking)
...
You can copy the codes to a temporary file, then use adb shell am start -a android.intent.action.CALL -d tel: to dial them from the shell, bypassing the manual dialing step.
Pitfalls & Edge Cases
| Pitfall | What to watch out for | How to avoid it |
|---|---|---|
| Wipe-triggering codes | Some codes, like #####***, wipe user data or reboot the device. | Never dial blindly; always consult a reliable source before testing. |
| Hidden or OEM-specific packages | pm list packages may not show packages installed in a system partition that aren’t visible to the user. | Run the script as root or use adb root on a rooted device to broaden visibility. |
| Android 13 restrictions | The new privacy guardrails limit the information that pm dump can reveal. | If the script returns few or no codes, try adding -f to pm list packages or use adb shell dumpsys package |
| False positives | The string android_secret_code can appear in comments or documentation strings in the manifest. | Inspect the surrounding XML to confirm the intent-filter contains the |
| Device-specific quirks | Some OEMs, like Samsung, use a different secret-code namespace (com.sec.android.app). | Adjust the grep pattern to com.sec.android.app or consult the vendor’s documentation. |
Because the script operates purely in userland, it is safe to run on any device without root. However, if you’re working on a fleet of phones, consider capturing the output on a per-device basis and archiving it for later forensic review.
Quick FAQ
Q1: How can I confirm whether a discovered secret code is safe to use? A1: Cross-reference the code against a reputable database (the XDA list or the manufacturer’s support site). If the code appears in a public post that includes a “safe” disclaimer, you can test it on a secondary device first.
Q2: Does this script work on Samsung devices? A2: Yes, but Samsung often prefixes package names with com.sec. The script can be tweaked by adding grep -i sec to focus on Samsung packages.
Q3: Can I use this script on a rooted phone? A3: Absolutely. Running adb root before execution will expose all system packages, including hidden OEM menus that are invisible on a stock install.
Q4: What if my device is running Android 14?
A4: The basic logic still applies, but some intent-filters may be stripped by the framework. If you find no codes, try adb shell dumpsys package
Q5: How do I add my own custom codes to the script? A5: Append the code to the codes.txt file in the repo and modify the script to read from that list, or hard-code it into the grep pattern.
Q6: What happens if I dial a code that triggers a wipe? A6: The device will reboot or wipe data. That’s why the script only prints the codes; it never dials them automatically. Always test in a controlled environment.
Conclusion
Automating the hunt for Android secret codes turns a tedious manual task into a single command that produces a definitive, timestamped inventory. On a Moto G Play running Android 13, the script found four valid codes: 2486 for engineering mode, 828282 for the telecom developer menu, and two others that surfaced in com.motorola.moto.sit and com.motorola.ccc.ota.
For developers, the ability to spin up a CQA menu or test the accelerometer and magnetometer in one line is a huge productivity boost. For forensic analysts, having a reproducible, non-rooted method to gather hidden intent-filters preserves the integrity of the device while still exposing valuable metadata.
Before you start dialing, remember the principle of least surprise: confirm each code with an authoritative source, run it on a secondary device, and keep a log of what the code does. With that discipline, secret codes become a powerful ally rather than a hidden risk.





