Quick Answer: A rootless Android call recorder captures calls without unlocking your bootloader, usually by using Shizuku to reach ADB-level system APIs. AVault, an open-source app for Android 12 through 16+, saves recordings as AES-256-GCM encrypted
.vaultfiles, keeps keys in the Android KeyStore, and unlocks them with biometrics or a PIN. Recording laws still apply to you.
Most call recorders on Android fail the same way. They drop an unencrypted .m4a into a folder that any app with storage access can read. AVault takes a different route. It's an MIT-licensed project that pairs rootless system integration with encryption at rest, biometric locking, and automatic cleanup. Here's what its design actually does, where the limits are, and what you need to decide before you install anything.
Why Most Call Recorders Leak Your Audio
The usual failure isn't the recording itself. It's what happens afterward. A plaintext file sits in shared storage, gets indexed by the media scanner, and shows up in gallery apps. Anyone with physical access, or an app with broad read permissions, can copy it.
The project's README makes this point directly: traditional tools store raw audio as unencrypted files in public directories where they're exposed to media indexers and unauthenticated extraction. Scoped Storage has made some of this harder, but it hasn't solved the core problem, which is that a file someone can read is a file someone can leak.
AVault's answer is to treat every recording as a secret from the moment it's written. Most guides skip this part, so it's worth understanding before you look at any feature list.
How the .vault Format Protects Each Recording
Each recording is packaged in a custom container with a fixed binary layout. The fields are:
- Magic identifier (bytes 0–3): the ASCII string
AVLT, which lets the app reject malformed files. - Format version (byte 4):
0x01, which leaves room for future cryptographic migrations. - Initialization vector (bytes 5–16): a 12-byte nonce from
java.security.SecureRandom, generated per session. - Ciphertext payload: Opus audio (32–128 kbps by default) or AAC, encrypted with AES-256 in Galois/Counter Mode.
- Authentication tag (final 16 bytes): a 128-bit GCM tag.
The tag is the part people underrate. If someone flips a single bit in the file, decryption fails before any audio plays. That matters for evidence integrity. A recording you can't prove is untampered is a recording you can't trust.
The nonce detail matters too. GCM is catastrophically weak if a key and nonce pair is reused, so generating a fresh random IV for every session is the non-negotiable part of the design. The README states that IVs are never reused, which is the right claim to make.
Hardware-Backed Keys, and the Plaintext Gap Nobody Advertises
Here's the counter-intuitive part. Keys generated in the Android KeyStore can live inside the Trusted Execution Environment or a StrongBox secure element, and the raw key material never has to enter your app's memory. That's a real improvement over keys stored in a file the app can read.
But encryption at rest only covers the file on disk. To play a recording, the app has to decrypt it, and the audio exists in RAM for as long as playback runs. AVault's README describes decryption "directly in volatile memory" into a 0600 POSIX file descriptor, with .nomedia to keep media scanners away, and says the stream is shredded when playback halts. That's a sound design. It just isn't "zero plaintext" in the absolute sense. The accurate claim is zero plaintext at rest.
When does this matter? If someone has root access to a device while you're actively playing a recording, the protection is weaker than the marketing suggests. Your threat model should include that case, not assume the KeyStore covers it.
The app's lock layer adds another gate. Per the spec, it uses BiometricPrompt, a salted PBKDF2-HMAC-SHA256 PIN with 100,000 iterations, and a lockout after five wrong attempts, starting at 30 seconds. Those are reasonable numbers for an on-device PIN. They don't make a weak PIN strong.
What "Rootless" Really Means With Shizuku
Rootless doesn't mean unprivileged. AVault relies on Shizuku, which lets apps call system APIs through an ADB shell-level Binder connection. That's a higher privilege than an ordinary app holds, and it's the reason the tool can access telephony functions without a rooted bootloader.
The trade-off is operational. Shizuku generally needs to be started again after a reboot, depending on how you configured it, and it depends on developer options staying enabled. Those are common failure points. If a recording doesn't start, check Shizuku's status before you assume the app is broken.
Compare this with the root-based tools in the table below. Rootless setups avoid unlocking the bootloader and voiding warranties, but they still grant meaningful system access. Treat the privilege as real, and don't leave the Shizuku service running on a device you no longer control.
Auto-Delete, Bookmarks, and the Retention Trade-Off
AVault can automatically prune expired, non-bookmarked recordings on a schedule from one day to one year. Bookmarked calls are exempt and stay until you delete them.
This is a good privacy default, but it has a sharp edge. The simplest mental model is that auto-delete is a one-way door. Once the interval passes, a recording you didn't bookmark is gone, and encryption won't bring it back. Here's where most people get caught: they set a short retention window, forget about it, and later discover that a call they needed was pruned three days earlier.
Set your retention interval based on the longest window you'd realistically need, not the shortest one that sounds private. Then bookmark anything you might later need as evidence or reference. The setting is only as good as your habits around it.
The Consent Problem Comes Before the Code
This is the section that matters most, and the project's own README opens with it. Recording phone calls is governed by different rules in different places. The source cites one-party consent under 18 U.S.C. § 2511 in the United States, and all-party consent under California Penal Code § 632, Germany's StGB § 201, and GDPR Article 6 as examples. Some jurisdictions require every participant to agree before a call is recorded. Others only require one participant, which may be you.
Here's the practical reality. The legal question isn't about the software. It's about who's on the call, where each person is, and what they agreed to. A tool that's perfectly legal to use in one country can expose you to criminal liability in another. I'm not a lawyer, and nothing here is legal advice. Check the rules for every place a participant might be.
The project also explicitly prohibits use for unauthorized surveillance, stalking, or harassment. Read that as a serious constraint, not boilerplate.
Comparing AVault With Other Approaches
| Approach | Root Required | How Recordings Are Stored | Plaintext Exposure |
|---|---|---|---|
| Standard call recorder apps | No, but Scoped Storage limits access | Usually unencrypted MP3, M4A, or WAV | Permanent plaintext file |
| Root-based recording tools | Yes, bootloader must be unlocked | Usually unencrypted MP3 or WAV | Permanent plaintext file |
| AVault (v2.0.0 per the README) | No, uses Shizuku | AES-256-GCM .vault container | None at rest; decrypted in RAM during playback |
The table reflects the project's stated design. It's a README, not an independent audit. I looked for references to a third-party security review in the excerpt I read and didn't find one. Treat the cryptographic claims as the author's design, and verify them yourself if your use case depends on them.
Frequently Asked Questions
What is AVault, and is it a rootless Android call recorder?
AVault is an open-source Android app that records calls without root by using Shizuku to access system APIs. It stores each recording as an AES-256-GCM encrypted .vault file, so no plaintext audio sits on disk. It supports Android 12 through 16+, according to its README.
How do I keep call recordings secure on Android?
Store recordings in encrypted form rather than shared storage, lock the app with biometrics or a strong PIN, and set an auto-delete interval that matches your actual needs. Bookmark anything you need to keep. Avoid running a privileged service like Shizuku longer than you need it.
Why does a rootless call recorder need Shizuku?
Shizuku lets an app call system APIs through an ADB-level Binder connection, which gives it more access than a normal app has. Without that, telephony recording would typically require root. The trade-off is that Shizuku usually needs restarting after a reboot, so plan for that.
Is recording phone calls legal?
It depends on where you and every other participant are located. Some places require one-party consent and others require all-party consent, and GDPR adds data protection obligations in the EU. Check the rules for every jurisdiction involved before you record anything. This is general information, not legal advice.
Keep the core rule in mind: encryption protects the file, but it can't make an unauthorized recording legal. Verify the consent requirements for every call before you hit record. Then, if you're evaluating AVault, try it on a test device with a consenting contact, set a short retention window, and check that the bookmark and auto-delete behavior matches what you expect. Pass this checklist to anyone wrestling with how to secure call recordings without giving up privacy.