Created attachment 183383 [details] Screenshot showing the 2GB speedpaint recording stuck in Krita's private app directory. SUMMARY Critical Data Loss: Individual Speedpaint frames (images) in Krita Android Beta are Inaccessible and Cannot Be Exported from Private /data/user/0 Directory. STEPS TO REPRODUCE 1. Open Krita Android. 2. Load an existing illustration document that contains a recorded speedpaint. 3. Navigate to the speedpaint recorder options. 4. Observe that, by default, the recorder's output directory is set to a private, application-specific location. 5. Click the first icon on the right (to open the list of recorded speedpaints or access specific recorder options). 6. Observe that when attempting to export the speedpaint frames, no option is provided to select a public destination folder, only can delete it. 7. As a result, these individual frames remain stuck in this private folder. Exporting them as a video is also currently impossible within Krita Android because it doesn't support FFmpeg for video rendering. OBSERVED RESULT -Individual speedpaint frames are saved in a private folder: /data/user/0/org.krita/files/kritarecorder/. -This location is completely inaccessible to standard file explorers, other image/video editing applications, and direct transfer to a PC without rooting the device. -Attempts were made to access the location using ADB (Android Debug Bridge), but the Krita Android application is not "debuggable," which prevents the use of commands like run-as to extract the files. -There's no apparent in-app functionality to export these already existing speedpaint frames (either as a sequence of images) from this private directory to a public user-accessible location. -This has resulted in the loss of my work. EXPECTED RESULT The frames of speedpaint video should be exportable by default to an accessible internal storage location (e.g., Movies or Download). Or integrate with external video renderers (e.g., via FFmpeg, if installed separately), SOFTWARE/OS VERSIONS App: Krita Android Beta OS: Android 14 Device: Galaxy Tab S7 Storage Impact: 2 GB of inaccessible recorded image frames ADDITIONAL INFORMATION -After changing the output directory, the original recordings became fully inaccessible. -There is currently no method to even delete the data from the private directory without root access. -Rooting is not a viable or safe option for many users, and may void warranties or lead to data loss. -The inability to export or retrieve these frames severely limits the utility of the speedpaint feature and can lead to significant user frustration. -Users are currently forced to accept the loss of recordings. Thank you for your time and effort in investigating this issue. As a user, I am committed to helping improve Krita and prevent similar data loss for other users.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2616
Git commit 7b2760c32d3df209ada4ae64de06cca1da5844a1 by Dmitry Kazakov, on behalf of Carsten Hartenfels. Committed on 28/01/2026 at 08:39. Pushed by dkazakov into branch 'master'. [android] Make recorder docker not trap files On Android, no user-visible directories are writeable by default. That means QDir::homePath() is an application-internal directory by default, which means the recorder docker's default storage location dumps file in a place inaccessible to the user. To add insult to injury, the user can't actually create a timelapse video from these files on Android due to an absent ffmpeg, meaning all they do is take up space. And to add torture to insult, if the user changes the recording directory to an external one while they have files lingering in the internal directory, they can no longer revert to that directory, rendering them unable to delete those (often large) useless files without clearing Krita's data altogether, losing all configuration. This patch changes the recorder's default directory to be empty on Android, since we don't have a sensible default we can use. The user must choose a directory themselves, where they will give Krita permission to write to that directory. That requires the docker to actually handle an empty directory properly. It no longer tries to start an auto-recording when the path is empty. When the user hits the record button without selecting a directory, they will be prompted to do so before recording starts (or aborts, if they don't pick any directory.) Finally, to rectify the past situation, if the default path is selected, it will get turned into an empty path instead. If the internal directory exists and the user has selected a different directory for us to write to, the files will be moved over. M +15 -1 plugins/dockers/recorder/recorder_config.cpp M +9 -0 plugins/dockers/recorder/recorder_config.h M +126 -4 plugins/dockers/recorder/recorderdocker_dock.cpp M +1 -1 plugins/dockers/recorder/recorderdocker_dock.h https://invent.kde.org/graphics/krita/-/commit/7b2760c32d3df209ada4ae64de06cca1da5844a1