FlipperDroid: carrying a Flipper Zero style toolkit in an Android phone

The pitch is one device instead of a specialised gadget

FlipperDroid is an Android application developed in Kotlin, inspired by the well-known Flipper Zero device, and it brings a set of wireless and hardware security testing tools to Android smartphones by leveraging their native capabilities. The framing is a substitution. The Flipper Zero is a small dedicated piece of hardware for radio and hardware work, and the argument here is that a modern phone already contains much of the same silicon, so an app can cover a useful share of the same ground without a second device to carry and charge. The README states the intended audience as security professionals, researchers and enthusiasts who want to interact with and analyse a wide range of communication protocols and interfaces directly from a mobile device. The module list covers scanning, analysing and emulating NFC, Bluetooth, RFID and more, plus tools for network diagnostics and USB based attacks, which the README calls a comprehensive mobile toolkit. The acknowledgements name the Flipper Zero project for functional inspiration, LineageOS and the Android open source ecosystem, and F-Droid for supporting free and open software distribution.

Eight modules, and three of them are explicitly unfinished

Reading the feature list closely is worthwhile, because the wording distinguishes what exists from what is planned. The NFC and EMV reading and emulation module reads and emulates NFC cards, including contactless bank cards and other chip based identifiers, and that is the centrepiece of the app since phone NFC hardware is genuinely capable of that. The Bluetooth interface module is described more carefully, as scanning for Bluetooth devices, connecting to them, and preparing for future emulation capabilities, which says plainly that the emulation half is not there yet and the module is currently a scanner and a connector. The network tools row is an integrated interface for tools like Nmap, Wi-Fi scanning and packet analysis, and it carries the marker in development, so the ambitious part of that row is a plan. The RFID and infrared row covers modules to read, interact with, or send signals using RFID or infrared communication, and unlike the Bluetooth row it does not carry a development marker, which suggests that one is further along. The remaining three rows are ordinary application features rather than radio work: an advanced logging system for viewing, managing and exporting logs related to device interactions, scans and application activity, customizable technical settings for modifying key behaviours and parameters, and Material UI compatibility so the app looks native.

BadUSB is the module to think hardest about

The BadUSB module is described as emulating malicious USB HID devices for penetration testing and user awareness purposes, and it is the feature that sets the boundaries for this project. The mechanism is well known in the security world: a USB device that enumerates as a keyboard and types commands is indistinguishable from a person at the keyboard, and a phone can present itself as one. The stated purposes, penetration testing and user awareness, are legitimate and the second one is educational, since the best defence against a device that types into your machine is a user who has seen one do it. The practical facts are that the feature is on a phone, that a phone is a thing people carry into other people's buildings, and that the legal disclaimer is doing real work in the README. The disclaimer says the application is intended strictly for educational, research and legal penetration testing purposes, that misuse for unauthorized access, emulation or attacks on third-party devices or systems is strictly prohibited, and that the developer is not responsible for the consequences of illegal use. That is the norm for this class of tool and it does not change what the module does, so the sensible reading is that this is a training and research tool that belongs in a lab rather than a general purpose utility.

Root, Android 10, and a single tested configuration

The requirements section is short and the second line is the one that tells you how confident the project is. Android 10 or newer is needed, and the app has been tested with LineageOS on a rooted Google Pixel 7. That is a single tested combination, named explicitly, and the choice of LineageOS rather than stock Android is a hint about why rooting is required, since the modules that emulate radio protocols need the kind of access to the NFC and Bluetooth stacks that a stock build restricts. The consequences for a user are practical rather than philosophical. Your phone has to be rooted, which means you open the bootloader, flash a custom image, and accept that a banking app may stop working, and the app is a sideloaded or F-Droid install rather than a Play Store one, so you are granting it the permissions it asks for by hand. For a researcher with a spare device, that is a reasonable price for carrying the toolkit. For someone who wants to use their daily phone, it is not. The README does not enumerate which specific modules need root and which do not, so the practical approach is to install it and try, which is itself worth knowing before you commit an afternoon to it.

A conventional Gradle project with one release

The project structure section lists a standard Android layout. The src/ directory holds the application source, build/ holds the Gradle build artifacts, and .gradle/, .idea/ and .kotlin/ hold configuration and IDE metadata. The build files are build.gradle.kts and settings.gradle.kts, which means the Kotlin DSL rather than the Groovy one, and there is a Gradle wrapper with both the gradlew and gradlew.bat launchers, a proguard-rules.pro for obfuscation and shrinking, and a local.properties for the local Android SDK path. The project structure block in the README reproduces exactly that tree.

FlipperDroid/
├── src/ # Application source code
├── build/ # Gradle build artifacts
├── .gradle/ .idea/ .kotlin/ # Configuration and IDE metadata
├── build.gradle.kts # Kotlin DSL build configuration
├── settings.gradle.kts
├── gradlew / gradlew.bat # Gradle wrapper
├── proguard-rules.pro # Obfuscation and shrink rules
└── local.properties # Local Android SDK path

The top level of the repository matches, with the .gradle, .idea and .gitignore directories, the LICENSE and README, the two Gradle Kotlin DSL files, the gradle.properties and gradle directories, the wrapper scripts, local.properties, proguard-rules.pro and the src directory. The release history is thin. The repository has one tagged release, named release with the title V1.0, dated 2025-07-11, and the last push to the repository was on 2026-07-22, so the code has moved since that release without a new tag. The project is MIT licensed, and the README points at the LICENSE file for the details.

Where FlipperDroid is the wrong choice

The first limit is the one the README states about itself, that the network tools are in development and that the Bluetooth module is preparing for future emulation capabilities. A toolkit whose most commonly discussed capabilities are half built is a research vehicle rather than something to depend on, and the tags suggest the API is not pinned either, with one release and a year of subsequent commits. The second is the root requirement, which turns a security testing tool into something that needs a spare device and an afternoon of setup, and which will also break banking and other apps that check for a locked bootloader. The third is the inherent asymmetry of the device, since a Flipper Zero is a dedicated tool you take out deliberately for a session, whereas a phone is a tool you carry and connect to things incidentally, including other people's devices, which is exactly where the legal line sits. The fourth is scope. The list of interfaces is broad, but a phone's NFC stack is a phone's NFC stack, and features that a dedicated device implements with its own radio, particular sub-GHz RFID readers, or a wideband antenna, are only emulated as far as the handset's hardware allows. The fifth is that the app competes with the real device it imitates, and the reason to prefer the real thing is that it does not require you to compromise the phone you carry. For learning and for a lab bench, the substitution is genuinely useful. For anything where a dedicated unit is available, the dedicated unit is the better tool.

Editorial conclusion

Adopt FlipperDroid if you want to experiment with NFC, RFID, infrared and USB HID emulation from a phone you already carry, and you are comfortable with a rooted device and with the responsibility of only testing hardware you own. Skip it if you need a finished product, since the network tools and Bluetooth emulation are explicitly unfinished, and skip it if you cannot root the device or cannot get an app with the permissions it needs. Verify first that your phone runs Android 10 or newer, that you understand which modules need root and which do not, and that the Bluetooth and network features you need are actually implemented rather than planned.

Frequently asked questions

Official sources

1. Issues
2. Jeremiznoo/FlipperDroid on GitHub
3. License: MIT
4. README
5. Releases