The export screen is a lie of omission. It shows a progress bar, so it looks like the work is happening in the window. It is not. On Android, the work happens in a process that outlives the window, and the window is only a view onto it.
That distinction explains the most common export complaint: “I switched apps and it stopped.” Almost always it did not stop. The progress bar stopped, because the progress bar was the thing tied to the screen.
What actually happens when you leave an app?
An Android app is a process. Activities — the screens — live inside it and can be destroyed at any time, including when you press home. Destroying an activity does not necessarily destroy the process, and it definitely does not stop work that was handed to a service.
There are two kinds of service, and the difference is the whole story:
- A background service is subject to being stopped when the system needs memory or when background execution limits apply.
- A foreground service shows an ongoing notification and is treated as work the user knows about. It is allowed to keep running while you use other apps.
A video export can take minutes. Every editor that survives the user switching apps has to move the render into a foreground service, or accept that a long export dies whenever the phone decides the app is no longer interesting.
What does ReelRoll’s export service do?
When you tap save, ReelRoll starts ExportService as a dataSync foreground service and posts an ongoing notification titled “Exporting Video” or “Exporting Audio”. The render runs through FFmpeg into a temporary file in the app’s cache directory. When it finishes, the file is published through Android’s media store — Movies/ReelRoll for video, Music/ReelRoll for audio — and a second notification says the export is complete and opens the file when tapped.
Two details explain most of the confusion:
The percentage is not in the notification. Progress is sent to the editing screen over a process-local broadcast. That is deliberate — the notification is a status light, not a dashboard — but it means the moment the screen is destroyed, there is no percentage anywhere. The spinner in the shade keeps turning and the file still appears.
The completion dialog is also screen-bound. If you are in another app when the render finishes, you get the system notification and the file in the gallery rather than an in-app dialog. The Studio tab reconciles from the media store, so the finished reel shows up there when you come back.
What does not survive?
A process kill. That is the real failure, and it looks identical to a paused export from the outside.
If Android kills the whole process — a force-stop, a low-memory kill, an OEM “cleaner” — a service started with START_NOT_STICKY is not recreated. The temporary render file is left in the cache, no completion notification arrives, and nothing resumes. Force-stopping an app is the most common way people do this to themselves without meaning to.
Long exports are exactly when this is most likely: the screen is off, the phone is in a pocket, and a battery manager decides the app has had enough. If a render keeps dying overnight, the fix is usually an exemption from battery optimisation, not a different editor.
Why exports fail at the end rather than the start
The other complaint — “it got to 90% and failed” — is usually storage. A long export writes a full intermediate file before publishing the result, so it needs room for the render and then room again for the published copy.
ReelRoll does not check free space before it starts. The encoder simply fails when the disk fills, the diagnostic log becomes the error message, and the temporary file is deleted. That is why the failure arrives late: the export was fine until there was nowhere left to write.
Other failures that are not what they look like:
- Encoder trouble. If the hardware encoder fails, the app retries once with the software encoder, or the other way round. A second attempt that succeeds is not a bug, just a slow export.
- A custom folder that lost permission. The export falls back to
Movies/ReelRollrather than failing, so the file may be somewhere other than the folder you chose. - A gallery insert that failed. The render succeeded but Android refused the media-store entry, which reports as a publish failure rather than a render failure.
- Notifications denied. The export still runs — you get a toast instead — but you lose the only sign that it is alive. That is worth granting if you export long videos.
How do you tell a slow export from a dead one?
Three checks, in order:
- Pull down the notification shade. An ongoing “Exporting Video” notification means the service is alive. If the shade is empty and no file appeared, the process died or the render failed.
- Look in Movies/ReelRoll. A finished file can be there before the app’s own list catches up, because the media store is the source of truth.
- Check free space. If the export died near the end, this is the first thing to rule out, not the last.
Then retry from the error dialog rather than starting over from the editor: it re-runs the same save with the same settings, which is faster than rebuilding the edit.
The general lesson is not specific to ReelRoll. Any Android app doing long work behind a screen has to choose between a service that survives and a progress bar that does not. The good ones give you the notification; none of them can give you the progress bar after the screen is gone.
For the architecture behind the local renderer, see building a video editor that never uploads your footage. If you are comparing galleries first, the Android gallery comparison covers which ones edit locally at all.