monkeyswarm
Mobmuplat 0.39 not allowing disk access on Android (Pixel 7a)
Hello,
I just reinstalled Mobmuplat to try and get a custom patch to run on my Pixel 7a, and having trouble getting the app to write files to my phone drive. The patch I created collected touchscreen data and exports these data to the local directory using a "write" object. For a long time, I was able to use this app on both iPhone and Android devices, and record data to the local storage folder. I just tried running the same exact patch though, and the "write" button doesn't do anything anymore.
One issue I looked into is that Android does not allow Mobmuplat disk/storage access, and so I wonder if this is causing an issue with writing files, or perhaps if anyone has found any other workarounds. I haven't found any way to grant MMP this access. Another potential issue is that there is no local "Mobmuplat" home directory when downloaded on Android, and I notice all the app files download directly to the Downloads folder, which seems odd. On iPhone, the app creates its own project folder, which makes it easier to track files.
Anybody have any ideas for how to fix this?
Matt
Hi Matt You are absolutely right. About two years ago I was obligated by Android to change the Android file access pattern. Previously, the app would read and write to an 'external' folder, which was globally visible (and is confusingly named 'Internal storage' in the OS Files app). That was no longer allowed: https://developer.android.com/about/versions/11/privacy/storage#other-private-dirs
With that change, I added the 'import' button, which would copy files, selected via the OS-provided file picker, into MobMuPlats internal file system (which is not visible to other apps). But I have not implemented the inverse 'export' pattern to get any newly-created files out of that folder, into a more visible location. I will keep that in mind for a future update (and leave this issue open)
Note that if a patch creates and writes a file, it should still be able to do so (and that file should be visible, but otherwise inaccessible, in the MMP file list, when showing all files...try tapping 'show all files' multiple times to reload. Is that not the case for you?
Thanks Daniel, I don't know much about the import/export button functionality, but I do see an exported file in the MMP file list like you're saying. But it's faded out and I can't open it, and also don't see any such file in my actual file directory. Strangely, I don't see any of the standard MMP files like the "MMPExamples" in my file system either, whereas with iPhone it's all in one central "Mobmuplat" directory.
Do you know of any way to access this written file through the MMP window? Basically the process is to populate a message box in my Pd file with user input data through the linked MMP file, then exporting it with a "write" and "textfile" object. In iOS this works fine and the written file appears right in the "Mobmuplat" directory. In Android it seems to exist in my MMP directory as a text file, but I can't find it in my internal storage.
Matt
On Wed, Feb 26, 2025 at 1:06 AM Daniel Iglesia @.***> wrote:
Hi Matt You are absolutely right. About two years ago I was obligated by Android to change the Android file access pattern. Previously, the app would read and write to an 'external' folder, which was globally visible (and is confusingly named 'Internal storage' in the OS Files app). That was no longer allowed: https://developer.android.com/about/versions/11/privacy/storage#other-private-dirs
With that change, I added the 'import' button, which would copy files, selected via the OS-provided file picker, into MobMuPlats internal file system (which is not visible to other apps). But I have not implemented the inverse 'export' pattern to get any newly-created files out of that folder, into a more visible location. I will keep that in mind for a future update (and leave this issue open)
Note that if a patch creates and writes a file, it should still be able to do so (and that file should be visible, but otherwise inaccessible, in the MMP file list, when showing all files...try tapping 'show all files' multiple times to reload. Is that not the case for you?
— Reply to this email directly, view it on GitHub https://github.com/monkeyswarm/MobMuPlat/issues/104#issuecomment-2683991853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMR5HJWP3FK5B47IIZ5YUWT2RVKYBAVCNFSM6AAAAABX4H6YDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTHE4TCOBVGM . You are receiving this because you authored the thread.Message ID: @.***> [image: monkeyswarm]monkeyswarm left a comment (monkeyswarm/MobMuPlat#104) https://github.com/monkeyswarm/MobMuPlat/issues/104#issuecomment-2683991853
Hi Matt You are absolutely right. About two years ago I was obligated by Android to change the Android file access pattern. Previously, the app would read and write to an 'external' folder, which was globally visible (and is confusingly named 'Internal storage' in the OS Files app). That was no longer allowed: https://developer.android.com/about/versions/11/privacy/storage#other-private-dirs
With that change, I added the 'import' button, which would copy files, selected via the OS-provided file picker, into MobMuPlats internal file system (which is not visible to other apps). But I have not implemented the inverse 'export' pattern to get any newly-created files out of that folder, into a more visible location. I will keep that in mind for a future update (and leave this issue open)
Note that if a patch creates and writes a file, it should still be able to do so (and that file should be visible, but otherwise inaccessible, in the MMP file list, when showing all files...try tapping 'show all files' multiple times to reload. Is that not the case for you?
— Reply to this email directly, view it on GitHub https://github.com/monkeyswarm/MobMuPlat/issues/104#issuecomment-2683991853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMR5HJWP3FK5B47IIZ5YUWT2RVKYBAVCNFSM6AAAAABX4H6YDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTHE4TCOBVGM . You are receiving this because you authored the thread.Message ID: @.***>