Audio Recorder: a plain Android recorder with an honest storage limit

What the app does, and where it comes from

Audio Recorder is an Android application for recording audio, published on both F-Droid and Google Play under the package id `com.dimowner.audiorecorder`. The README presents it as an app for recording audio, whether you are capturing important moments or creating content, and lists the reasons it stands out.

The features are ordinary for the category and worth listing because they define the product. Fast startup, so you do not miss a moment. Three recording formats: M4A for high quality in a compact file, WAVE for professional-grade recordings, and 3Gp for sharing on the go. Adjustable sample rate and bitrate, and a toggle between mono and stereo. A visual waveform of the recording. And the everyday conveniences: rename recordings, share audio files, import existing audio files, create bookmarks, and pick colourful themes.

The project is Apache-2.0 licensed, with the copyright held by Dmytro Ponomarenko and a NOTICE file referenced in the licence text. The top level of the repository holds an `app/` module, a `build.gradle.kts` and `settings.gradle.kts` in Kotlin DSL, a `gradle/` directory, `gradlew` wrappers for both platforms, a `fastlane/` directory for release automation, an `art/` directory, an `AGENTS.md`, a `LICENCE` file and a `keystore.properties` file.

The repository is not archived and the last push was on 2026-09-29, the same day as the v2.5.0 release. The recent releases show steady work: v2.5.0 for system audio recording, v2.4.0 with ExoPlayer, playback speed controls and search in the records list, and v2.3.0 with a name format constructor, Bluetooth microphone detection improvements and Arabic localisation with RTL support.

The system audio recorder switched from MediaRecorder to MediaCodec

The v2.5.0 release title is unusually informative: it adds a system audio recording feature and a new M4a recorder that uses MediaCodec instead of MediaRecorder.

That switch is the interesting engineering decision in the project. MediaRecorder is the high-level Android API for capturing audio and video, and it handles container and codec details for you. MediaCodec is the lower-level codec interface, where you feed it buffers and it gives you encoded output. Moving from one to the other means taking on the container writing and the format handling yourself, in exchange for control.

For system audio, that control is the point. Capturing what another app is playing is not something MediaRecorder exposes, so the recorder has to work at a lower level and write the file itself. The consequence for a user is a new M4A path that is separate from the older WAVE and 3Gp paths, which means the file handling code is not uniform across formats any more.

The alternative to capturing system audio, and the one most users take, is to use the platform's own screen recording, which also captures audio. The reason to prefer this app is control over the audio stream, the format and the destination.

The v2.4.0 release added ExoPlayer for playback along with speed controls and search in the records list, which means the app moved from a simple player to one with a real media stack behind it. That is a meaningful upgrade for a utility app, since ExoPlayer handles the format and codec variations that a naive player does not.

The recording directory cannot be changed, and that is a platform fact

The FAQ answers the question of when the option to choose a recording directory will be added, and the answer is that there are no plans to add it.

The reason given is that newer versions of Android added restrictions on the ability to interact with the device file system, and there is no simple way to implement the feature. The consequence is that all records are stored in the app's private directory.

The FAQ then gives the workaround, which is the sentence that matters: all record files are available for the user to download from the app's private dir to a public dir. The development plans in the README also list a backup feature to allow downloading all records files into a public directory called Downloads, from the v1.0.0 milestone.

So the workflow is a two-step one. The recording goes to private storage, which is correct for Android's storage model and means the app can record without holding broad storage permissions, and then you export it to a public location that other apps and file managers can see.

This is a real constraint for anyone who wanted the app to write straight to a folder on the SD card, and the project's answer is a policy decision rather than a technical one. It also means the app does not need the wide storage permissions that older Android apps requested, which is a genuine benefit on a modern device.

The coverage gate is 5 percent, and that is the point

The most revealing part of the README is the test coverage section, and it is worth reading precisely because the number is so low.

The project uses JaCoCo for code coverage reporting, with two Gradle tasks. The unit-test-only report needs no device:

./gradlew jacocoTestReport

That runs `testDebugConfigDebugUnitTest` and writes an HTML report to `app/build/reports/jacoco/html/index.html` and an XML report to `app/build/reports/jacoco/jacocoTestReport.xml`.

The full report needs a connected device or a running emulator:

./gradlew jacocoFullReport

That runs both the unit tests and the connected Android tests, `connectedDebugConfigDebugAndroidTest`, and merges the coverage data into a single report at `app/build/reports/jacoco/htmlFull/index.html` and `app/build/reports/jacoco/jacocoFullReport.xml`.

And then there is the verification task:

./gradlew jacocoTestCoverageVerification

This runs the full report and then asserts that the overall line coverage ratio is at least 5 percent, and the build fails if the threshold is not met.

Five percent is a very low bar, and the honest reading is that this is a floor to prevent coverage from regressing to zero rather than a quality target. The value of the setup is the mechanism rather than the number: instrumented tests are wired into the build, the report paths are documented, and a regression in coverage fails the build.

The README also gives a practical tip, that `jacocoTestReport` is the fast option for local iteration and the full report and verification tasks are for CI or when instrumented coverage is needed. That advice is about wall clock time, since instrumented tests need a device.

The Kotlin rewrite, Compose and the architecture change

The development plans section describes a v2.0.0 that reworked the app completely: a new architecture written in Kotlin, UI designed with Android Compose, a Room database, ExoPlayer for media playback, and Hilt for dependency injection. The README notes that despite the substantial changes the existing user interface remains mostly unchanged, and that the effort also focused on achieving robust unit test coverage, with the stated goals of app stability, faster feature delivery, and mitigating concerns about introducing new bugs.

A Room database is the notable part of that list. A recorder that stores its metadata in a database rather than by scanning the file system can hold bookmarks, durations, names and format information as queryable rows, which is what makes the v2.4.0 search in the records list and the v2.3.0 name format constructor implementable. The name format constructor in particular implies a template system for generated file names, which only makes sense with a metadata store behind it.

Hilt for dependency injection matters less visibly but matters for testability, because it is the standard way to make an Android app's collaborators substitutable in unit tests. That is the mechanism behind the unit test coverage that the JaCoCo tasks measure.

One caveat about the README: the development plans section is out of date. It describes v2.0.0 as currently under development, while the release history shows v2.5.0 as the most recent release. The plans are a historical document rather than a roadmap, and the release titles are the better guide to what the app actually does now.

Where Audio Recorder is the wrong choice

The clearest wrong case is a workflow that needs to write recordings to a chosen folder directly. The FAQ rules that out, and the answer is that there are no plans to add it because of Android's storage restrictions. If your pipeline expects a file to appear at a path you control without an export step, this app does not fit and the README says so plainly rather than implying it might change.

The second wrong case is a need for lossless or professional mastering workflows. The format list is M4A, WAVE and 3Gp, with adjustable sample rate, bitrate and a mono or stereo toggle, but there is no mention of recording without lossy compression, dithering, or metering. A user who needs a WAV that is bit-exact from an analogue source will find the settings insufficient.

The third is any environment that cannot install from F-Droid or Google Play, since those are the two distribution channels listed. There is no APK download link described in the README and no sideloading path documented, although the repository does contain `keystore.properties` and a `fastlane/` directory, which suggests the project does produce signed builds for its own release process.

The fourth is a developer looking for a test coverage reference. The enforced threshold is 5 percent line coverage, and the instrumentation is a recent addition to a project that spent most of its life as a simpler app. The Compose and Hilt rewrite is a real improvement, but the coverage number tells you the testing is still early, and a fork that intends to change behaviour in the recording path should assume it is working with lightly tested code.

Editorial conclusion

Audio Recorder suits a user who wants a straightforward recorder with no account, no subscription and no telemetry, available from F-Droid as well as Google Play, and a developer who wants to read a real Compose and Hilt Android project. It does not suit anyone who needs to choose where recordings are written, since the FAQ says the directory cannot be changed and everything lives in the app's private storage, and it does not suit a team treating the project as a coverage benchmark, because the enforced line coverage threshold is 5 percent. Before adopting it, read the FAQ entry on the recording directory to understand the export path, and check the release notes for the version you install, since the v2.5.0 system audio feature depends on MediaCodec rather than MediaRecorder.

Frequently asked questions

Official sources

1. Dimowner/AudioRecorder on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases