AVault records Android calls through Shizuku, but its encrypted vault needs a reality check
A development build separates capture, storage protection and key recovery, leaving handset-specific playback as the essential first test.
AVault can keep a call in an encrypted library without asking you to root the phone. Whether it captures both voices still depends on the phone and calling app.
The project’s current README says it installs on Android 11 and later, then uses Shizuku started through wireless debugging or ADB. It tells users to “check both sides of the conversation” during setup.
Encryption uses AES-256-GCM when enabled. The important sequence comes afterward: AVault records audio first, then attempts encryption of the completed file. Plaintext can exist during capture or if that step fails. Hardware-backed keys depend on the device.
The latest documented refresh did not include a live-call capture test, and the downloadable APK is described as a debug-signed development build. That leaves a specific job for anyone trying it: prove capture on the intended handset before trusting it with a conversation that matters.
The setup therefore has two separate acceptance checks. One asks whether the intended call produces an audible recording. The other asks what protection the resulting file actually receives. A successful permission prompt settles neither. It is possible to configure an elaborate vault around audio that never captured the other participant.
A useful compatibility note would be specific enough for somebody else with the same handset to repeat: Android version, calling application, chosen audio source and whether both directions were audible. Reporting only that the app installed hides the part a future user needs. A screenshot of a recording timer is especially poor evidence for what the microphone path captured.
The key-management instructions deserve reading before the first recording worth keeping. An app PIN and an encryption key perform different jobs. Remembering the number that opens the interface does not recreate a missing key after the application’s storage is cleared. Anyone evaluating retention should decide what needs preserving before experimenting with reinstalling or cleaning up the app.
For a permitted trial, a disposable conversation with a consenting participant gives the test a clear result: both people can say a recognizable phrase, and the saved recording can be played back afterward. There is no need to discover a one-sided recording during a conversation that cannot be repeated. The project documents the limitations; the actual phone has to supply the evidence.
A call recorder also becomes part of a personal filing system. Keeping every test indefinitely makes the vault harder to search and creates more material to manage. Retention and recording rules should follow the actual purpose of the evaluation, with a check that the selected settings behave as expected. The next useful report would demonstrate capture, playback and the fate of the file after the chosen retention interval.
The useful next compatibility report would name the handset, calling app and capture settings, with confirmation that both sides were audible.