Setup
Setup & Help
Getting CallVault running on an Android phone, start to finish, and what to check to be sure it is genuinely recording both sides of a call.
Download
Get the app, then check it before you install it
Download CallVault 0.2.9 for Android · 86 MB · What's new in 0.2.9
Most of that size is the speech model for on-device transcription, which ships inside the app so that transcribing never needs a network. Android 11 or later, and Shizuku is required before it can record anything. Your browser will warn you about installing files from outside Google Play. That warning is correct and it is the reason the next paragraph exists.
CallVault is not distributed through Google Play, so nothing checks the file for you.
Confirm it is the build published here before installing it: version 0.2.9,
90,314,284 bytes, built 2 October 2026.
SHA-256 of the APK
3376612c9f81e10efc34037e328226563e7b3083dfc2c691c644d8bdd72506f3
Check it yourself before installing:
certutil -hashfile callvault-0.2.9.apk SHA256 (Windows)
shasum -a 256 callvault-0.2.9.apk (macOS)
sha256sum callvault-0.2.9.apk (Linux)
If it does not match, do not install it.
That hash covers one exact build and changes with every new release. The signing certificate does not — every genuine CallVault build is signed by the same key, and Android refuses to install an update signed by a different one. Its SHA-256 fingerprint is:
fa2aead65010f62f6b396e753b590fded5d956d224f7b62a9dc56ae022ccf3b5
Certificate holder: NEXUS-SECTECH LTD, United Kingdom.
Read this first
CallVault needs Shizuku. There is no way around it.
Android will not let an ordinary app record a phone call. The permission that grants
access to the call audio stream, CAPTURE_AUDIO_OUTPUT, is reserved for
system and privileged apps, and the check happens deep in the audio server against the
identity of whoever is asking. No setting, no toggle and no permission grant will hand
it to a normal app.
Shizuku is what makes it possible. It lets an
app run a small helper process under the shell identity, the same one
adb uses, which is allowed to open the call audio stream. CallVault
uses it for that one job and nothing else.
On Android 15 there is no fallback worth having. CallVault can fall back to the microphone, and on Android 15 it is useless: the system silences microphone access for apps running in the background rather than refusing it. Recording starts, the app reports it is working, and every sample in the file is zero. We measured 619,805 consecutive silent samples on a real call.
So: install Shizuku first. Installing CallVault on a phone where you cannot run Shizuku gets you an app that looks armed and records nothing. CallVault now deletes a completely silent recording rather than filing it, and tells you plainly that the call was not recorded, but it is a poor substitute for it having worked.
| You need | |
|---|---|
| An Android phone | Android 11 or later |
| Shizuku | Installed and running |
| A computer | Optional. Only for the first pairing on some phones, and for checking your first call |
Step 1
Install Shizuku
Where to get it. Shizuku is free and open source, by Rikka. Use any of:
Google Play
Search for Shizuku by Rikka. The simplest route, and it updates itself.
Official site
shizuku.rikka.app has documentation and download links, including the current APK.
GitHub
RikkaApps/Shizuku has release APKs direct from source, if you would rather not use Play.
Why a call recorder asks you to turn on wireless debugging
It is a fair question, and the honest answer is that nothing else on an unrooted phone can do the job.
Recording a call needs a permission Android reserves for system apps. CallVault cannot
hold it, and no amount of granting permissions will change that. What can hold it
is the shell identity, the account adb runs under. So the
recording is not done by CallVault at all: it is done by a small helper running as shell,
which CallVault asks for the audio.
Starting something as shell requires something that is already shell. On a phone without root there are exactly two: root itself, or ADB. That is the entire reason ADB is involved. Not for debugging, not for diagnostics, and not to send anything anywhere — it is simply the only key that fits the lock.
Wireless debugging just removes the computer from that. Plugging into a laptop and running one ADB command does exactly the same thing. Wireless debugging lets the phone make that connection to itself, over its own loopback address, so you do not need a second device. Same mechanism, no cable.
You can turn wireless debugging off again as soon as Shizuku is running, and you should.
ADB is the ignition, not the engine. Once the helper is running it is an independent process that has no further connection to ADB — on a phone where we checked, its parent process had already become the system itself, with the ADB session long gone. Switching wireless debugging off does not stop it, and CallVault keeps recording normally until the phone restarts.
Leaving it on is the option worth avoiding. While wireless debugging is enabled your phone is listening for debugging connections on whatever network it is joined to. For a phone holding call recordings, that is not a trade worth making to save a few taps.
Huawei phones are the exception. On EMUI, stopping ADB takes the helper down with it, so there ADB has to stay on while you want calls recorded, and in the network mode that keeps it alive across an unplug. That is the trade described above, and on those phones it cannot be avoided without rooting. It also stops if you change the USB mode while the cable is in, or unplug in any mode other than Charge only. The setup is under Troubleshooting.
Starting it without a computer (Android 11 and later)
Shizuku can start itself using Android's own wireless debugging, entirely on the phone:
- Turn on Developer options. Settings → About phone → tap Build number seven times. You will be asked for your PIN.
- Turn on Wireless debugging. Settings → System → Developer options → Wireless debugging.
- Tap the words "Wireless debugging", not the switch. The row looks like a plain on/off toggle, but the label itself opens a detail screen. You need that screen, and missing this is the single most common way this gets stuck.
- On that screen, tap Pair device with pairing code. A dialog appears with a six-digit code.
- Leave that dialog on screen. Pull down the notification shade. Shizuku has posted a notification asking for the code. Type it there.
- Shizuku reports that it is running. Open CallVault and check the Health screen is green.
- Turn Wireless debugging back off. Nothing breaks. Shizuku and CallVault carry on until the phone restarts, and your phone stops listening for debugging connections. See above for why this is safe.
Check the Health screen rather than stopping at "Shizuku is running". The two are not the same thing: Shizuku can be up while CallVault has not yet connected to it, and green on Health is the app confirming its own helper is in place and the next call will be captured.
Why the dialog has to stay open. The pairing service only exists while that dialog is displayed. Close it and the service is gone, even though Wireless debugging itself stays on.
If Shizuku sits on "searching for pairing service" forever, this is almost always why: there is genuinely nothing to find, because the dialog was never opened or was dismissed. It is not a fault with your phone. That is also why Shizuku asks for the code in a notification: it is the only place you can type it without dismissing the dialog you are reading it from.
Starting it from a computer
If pairing will not hold, connect the phone by USB with USB debugging enabled and run:
adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh
Shizuku's own documentation covers this in more detail, including what to do if that path does not exist on your build.
Huawei: starting it again after a restart
Huawei phones have no Wireless debugging screen, so the no-computer route above is not available on them, and nothing on the phone itself can start Shizuku after a restart. It needs ADB over a cable each time. That cable can go to a computer or to a second Android phone, which is what makes a restart away from home recoverable. Either way, first set up the Huawei as described under Troubleshooting: without that, Shizuku stops the moment the cable comes out.
From a second Android phone. It needs to support USB host mode, which most do, and you need a USB-C to USB-C data cable. One-time setup on that phone:
- Install Termux and Termux:API, both from F-Droid. They must come from the same place or they will not work together; the Play Store version of Termux cannot use Termux:API at all.
- In Termux, install
termux-adb, a community build of ADB that can reach a USB-connected phone without root:curl -s https://raw.githubusercontent.com/nohajc/termux-adb/master/install.sh | bash
This adds its author's package repository to Termux, so Termux will trust packages that author signs. That trust stays inside Termux, but it is your decision to make; the script is short and worth reading before you run it. - Then:
pkg install -y termux-api
curl -sO https://callvault.nexus-sec.tech/arm-huawei.sh
and check it is the file published here before using it. Its SHA-256:ebd12bcdb11793efc398cd25791eeab726fd8b5095bfa6e46f6422f5ebf8a517
sha256sum arm-huawei.sh
Each time the Huawei restarts: connect the two phones, and on the second one run
bash arm-huawei.sh in Termux. Allow Termux:API to use the USB device when asked
(possibly twice, because the Huawei reconnects part-way through) and, the first time only,
allow USB debugging on the Huawei. It checks the Huawei's settings, switches its ADB to
network mode, starts Shizuku and wakes CallVault, and it only says ARMED
once the recorder is actually running. Unplug then, and leave the Huawei's "Use USB to"
prompt alone.
From a computer. The same two steps: adb tcpip 5555, then
start Shizuku as above. Keep the Huawei on Charge only when you unplug.
If your phone is rooted
Shizuku can start itself automatically and stay running. This is the only configuration where you can forget about it.
The part people get wrong: Shizuku stops every time the phone restarts.
Unless the phone is rooted, you must start Shizuku again after every reboot. While it is not running, CallVault cannot record calls. CallVault will tell you, with a persistent NOT ARMED notification, but if a phone is meant to catch calls reliably, either root it or get into the habit of checking after a restart.
That means the wireless debugging step above is repeated each time: switch it on, let Shizuku start, switch it off. It is a minute's work, not a setting you leave on. The helper process is what does not survive a restart — nothing about your pairing or your permissions is lost, and CallVault does not forget anything.
Step 2
Install CallVault and grant its permissions
CallVault is distributed as an APK and is not on Google Play. Copy it to the phone and
open it, allowing installation from that source if prompted. From a computer, the
equivalent is adb install -r app-release.apk.
On first launch it asks for:
| Permission | Why it is needed |
|---|---|
| Microphone | Required by Android for any audio capture. The real capture happens in the Shizuku helper. |
| Phone | To know the moment a call starts and ends. |
| Call log | To find out who the call was with, after it has been recorded. |
| Contacts | So a recording shows a name rather than a number. |
| Notifications | How the app tells you it is not armed, or that a call was missed. |
Shizuku will then show its own separate prompt asking whether to allow CallVault. Allow it.
One thing Android will not ask you about
Go to Settings → Apps → CallVault → Battery and set it to Unrestricted. Without this the system is free to stop the app in the middle of a call. On Sony phones, also check that STAMINA mode is not going to shut it down.
Everything else CallVault needs, it arranges itself through Shizuku when it starts.
Check the Health screen
Open the Health tab. Before trusting it with a call that matters you want Armed, Shizuku bound and Battery exemption all reading green.
Green means armed and working. Amber means something needs attention. Red means live capture, or a failure. Red never indicates a healthy state anywhere in this app.
Step 3
Prove it is actually recording
Do not assume. The failure this app exists to prevent is a recording with a real number, a real duration, and no audio in it. You find out months later, in the moment you needed it.
Make a short test call, around thirty seconds, with both people speaking. Then open the recording in CallVault and use the You / Them / Both control. If one side is silent you will hear it immediately.
If you have a computer to hand, this is more precise. With the phone connected by USB:
adb logcat -d | grep "CV\."
The line that matters looks like this:
CV.Capture: stopped: 26740ms route=shizuku_dual peaks up=22820 down=26662
up is your voice and down is theirs, on a scale of 0 to 32767.
| What you see | What it means |
|---|---|
| Both numbers healthy | Working. Both directions captured. |
up=0 or down=0 | One direction is silent. The recording is still kept, since half a conversation is still evidence, but something is wrong with capture on that handset. |
up=0 down=0 | Nothing was captured. CallVault deletes the file rather than filing it, and tells you the call was not recorded. |
route=mic_fallback | Shizuku was not running. On Android 15 this will produce silence. |
No CV. lines at all | The app was never woken. Check Shizuku is running and the battery setting is Unrestricted. |
If something is wrong
Troubleshooting
| Symptom | Usual cause | Fix |
|---|---|---|
| NOT ARMED notification | Shizuku is not running | Start Shizuku. It stops at every reboot unless the phone is rooted. |
| Shizuku stops when you unplug the cable (Huawei) | On EMUI, ADB shuts down when the USB cable is pulled, and Shizuku goes with it | What made it stay up on the Huawei we tested: Developer options → turn on Allow ADB debugging in charge only mode; before starting Shizuku, run adb tcpip 5555 over the cable; and keep the USB mode on Charge only: if the "Use USB to" prompt appears, tap Cancel. Picking Transfer files while armed also stops it. After a restart, see Huawei: starting it again. |
| Calls on a Huawei are cut short or chopped when not charging | EMUI freezes CallVault in the background while on battery | Settings → Battery → Launch manager → CallVault → turn off "Manage automatically" and leave all three switches on. Do the same for Shizuku. |
| "That call was not recorded" | Capture returned silence on every channel | Check Shizuku is running. On Android 15 the microphone fallback always produces this. |
| Calls are not detected at all | The app is battery-restricted | Set Battery to Unrestricted; check STAMINA or similar power saving. |
| Backup never runs | Consent not completed | Open the app in the foreground while the phone is awake. The Google consent screen can only appear there. |
| One side of every call is quiet | Normal, and handled | The far end typically arrives several times louder than you do. The player evens this out on the way to the speaker; the stored file is never altered. |
Do not run two copies of CallVault on one phone. A handset has a single in-call audio tap. Two installations both arm, both try to open it, and whichever gets there first takes the audio while the other records digital silence, with no way to predict which. We lost three real calls to exactly this before finding it.
Before you record anyone
The law on recording telephone calls differs by country and, in some places, by state or province. In some jurisdictions every party must be told, or must consent, before a call may be recorded. In others recording is permitted but using or sharing the recording is restricted.
Making sure it is lawful where you are, and that anyone entitled to be informed has been, is the responsibility of whoever operates the device.