fix(recordings): open the recordings folder from the system file manager
The recordings live in app-private storage (<data>/app_flutter/grabaciones), which the Android sandbox forbids any other app from reading, so no ACTION_VIEW on a file:// or FileProvider URI could ever open it. On top of that, viewDirectory built an EMPTY candidate list for that path: directoryDocumentUri returned null (path outside external storage) and FileProvider.getUriForFile threw because pluriwave_file_paths.xml never covered app_flutter. The loop never ran, so both entry points -- the radio recorder and Settings -- always showed "could not open the folder". Publish the folder as a browsable storage root via RecordingsDocumentsProvider instead. The files never leave private storage; the document framework asks us for them one document at a time, and the user can browse, copy out, rename and delete straight from the file manager. The root follows a user-configured path and falls back to the default recordings directory. Its title reuses the already-translated recordingsFolderTitle, so no new literal is introduced in any of the 13 locales. Also fixes "open last recording", broken by the same missing FileProvider root, and replaces Intent.createChooser with a bare startActivity in the candidate loop: a chooser never throws when nothing can handle the intent, so the first candidate always "succeeded" and the fallback chain never ran. Device QA pending -- the provider is driven entirely by the platform's document framework, so no unit test covers it. Each candidate logs its own name under file_actions.viewDirectory for logcat triage.
This commit is contained in:
@@ -73,6 +73,7 @@ void main() {
|
||||
'preNoticeChannelDescription',
|
||||
'openFolderTitle',
|
||||
'openRecordingTitle',
|
||||
'recordingsRootTitle',
|
||||
'missedTitle',
|
||||
];
|
||||
for (final clave in claves) {
|
||||
|
||||
Reference in New Issue
Block a user