- Feb 12, 2013
You've provided good information and (IMO) a reasonable bump. FYI, the developer is sometimes away from this thread for extended periods of time but is good about following up upon return.
I used to have the same problem and (a year and more ago) I started to use (there was a discussion about at that time) MiXPlorer builds with "API29" in the name (post #1, downloads)
Thanks., Now I can see the folders and files in it!I used to have the same problem and (a year and more ago) I started to use (there was a discussion about at that time) MiXPlorer builds with "API29" in the name (post #1, downloads)
That way, MiXPlorer can see and use /Android/data with no problem (probably even without root), on my two Xiaomi phones (one with MiUI 12.5/A11 and the other MIUI 13/A12) - screenshot
I can copy/paste between /Android/data and /Download, now I just played an ogg file I found in /Android/data/email/files and time ago I installed an apk attachment I found in the subfolder for another app there
First I uninstalled the previous MiX and then installed the api29.I can copy/paste between /Android/data and /Download, now I just played an ogg file I found in /Android/data/email/files and time ago I installed an apk attachment I found in the subfolder for another app there
Don't know if you need to enable some permissions for MiXPlorer in the native Settings for your ROM - A12 and.A13 might be tough about, and eg Xiaomi MIUI ROMs. Cannot help.you further
If you now installed that API29 MiX version, maybe you have two versions of MiX app installed and/or the new one did not install as update for your previous (they might have different package names), hence you maybe lost the permissions previously granted to MiX. You must investigate yourself
Have you checked the option in Magisk for Global Namespace? Settings>Superuser>Mount namespace Mode>Global
Warning, Rabbit Hole Ahead - Jumping in.
In other words this is looking to be a potential real issue or yet another challenge laid down by Google but it is hard to make sense of the information even though it is good information.
At the heart of it this is indeed a permissions error. It is not certain that the tips regarding resetting permissions will fix this but it seems applicable to run through them just to eliminate them. That being said, having tested some more I see evidence that this permissions landscape might have changed (perhaps more than once) since MiXplorer's developer was last here and since the last MiX beta.
Testing creation and editing of new text file in /android/data/com.google/android.video on external and internal storage on Android 11 stock moto rooted magisk in MiX XDA 6.58.5 (non API specific).
- In internal SD the file is created OK and after being edited and closed and reopened, it shows the results of the edit.
- In external SD card in the same folder structure the new text file is created but then when an attempt is made to edit it the result is the original file and a new file with "(1)" appended to the file name both of which have no contents. File can be created but no write permission to edit - has been reported before.
Here it gets weirder:
- A MiX log indicates that document providers have previously been configured for
/storage/emulated/0/[other non related folder out of this structure]
/storage/[external drive label]/
/storage/[external drive label]/Android/obb
/storage/[external drive label]/Android/data
Immediately, the document provider for the root of external storage stands out as an oddity because it is known that we are no longer allowed to assign document provider at the top level of the drive. How this got carried over from previous versions or added a new I do not know. Even more strange is that now, when following the routine to add document providers for those directories, on both internal and external storage after navigating in the native picker to the /android directory the only directory visible there is media.
It is possible that some MiXplorer settings got migrated over from previous android version on this device, and that is the only way I could explain the document provider for the root of external storage, but I definitely could see all the directories within /android on internal and external storage and was able to create document providers for them in the past. Other users have reported the closing of a loophole that allowed developers to work around scope storage. I wonder if this has been done within OS security updates or Google services from play store. This could explain the inconsistencies I see on my device and the differences in experiences regarding these permissions which don't run exclusively along the lines of different android versions.
Thanks for your answers.With this Scoped storage there is still some odd behaviour, I was having a play around and cannot delete or paste files into the root of android/data I get the file manager permission loop, I then tried copying a mp3 to the files folder of mixplorer silver, I could play it but it would not let me delete nor cut and paste it out of the folder, using the full root path I could though, think this is the same issue as that thing about deleting cached images that came up and I posted a log about, Hootan who I hope is well will need to have a look to iron some of these issues with the android/ folders out @dari-woka try and play your video, copy/paste by using the full root path to see what happens
Should also say I am on android 13 and using a Pixel 4a, will try and get a log posted
Yeah having a problem copying the logs from android/data/mix sliver although going through full root works
Error trying to delete the mp3
181 I/MiX> ----- Operation started ----------------------
182 I/MiX> Action: DELETE
183 I/OPERATION> #1 DELETE /storage/emulated/0/Android/data/com.mixplorer.silver/files/A Fistfull of dollars .mp3
184 D/DOC> DOC null!!
185 D/COUNT> Total: 1
186 I/OPERATION> #1 DELETE -------
187 D/STORE_REMOVE> Remove media /storage/emulated/0/Android/data/com.mixplorer.silver/files/A Fistfull of dollars .mp3
188 I/MiX> No item deleted
189 I/MiX> ----- Operation finished. 0s -------------
196 I/MiX> ----- Operation started ----------------------
197 I/MiX> Action: COPY
198 D/COUNT> Total: 15233 bytes
199 I/OPERATION> #1 COPY ---------------------------------------
200 D/OH:> default
201 W/SDExplorer> NULL or Dst 15633 != Src 15233 > /storage/emulated/0/MiX-B22090810_2022-12-05_19-34.txt
202 I/OPERATION> #1 COPY -------
203 I/MiX> No item copied
204 I/MiX> ----- Operation finished. 0s -------------
When transferring files between two android 10 and android 13 stock no root devices and vice-versa with MiXplorer v.6.59.1 B23020180, using the FTP server,
I detected a behavior that was inconsistent with the enabled settings:
more precisely after having set as "work folder" /storage/emulated/0/Download selected "Force use of this folder" and clicked on "Save", the transfers are always concluded at the path /storage/emulated/0/.
Secondly, it also seems that the setting to force a specific folder is not remembered. In fact, re-entering the FTP server settings after having made the "Force use of this folder" and "Save" modification, the box is found unchecked.
Am I doing something wrong or is this behavior normal?
- 'Remember Delete option' will remember the last selected option in dialog.@m0han Ninja-ed me but, maybe Undo is not quite all back. Not posting as implied criticism, I've been on a deep dive into the Rabbit Hole this Evening (or Morning or Afternoon) and just came up for air after a few hours so here we go.
6.59.0-BETA B23012410, Stock Moto A10 rooted magisk, testing with files on external SD. Settings > More settings, now includes all 3 options: Recycle bin, Undo, and Remember delete but, I’m not seeing how to use them properly or there are still issues with them. Details below;
- With only Recycle Bin enabled then recycled files are sent to the .recycle folder and can be restored manually but there is no apparent option in the menu. The deleted files in the .recycle folder retain their original names but without something like the menu that was used for the old undo function, a user would have to know the file name and search for it or search for all files in the .recycle folder to find the item to restore.
- With only Undo enabled then after copy or move (or delete) operations, there is a Menu > undo item but invoking it yields toast “no item”.
- With both Recycle Bin and Undo enabled, then the same as above: after copy or move or delete operations, there is a Menu > undo item but invoking it yields toast “no item”.
- The .recycle folder (when not deleted between tests) seems to contain the files that were deleted with Recycle Bin enabled, and also seems to contain the folders for the copy/moves (although those folders contain no identifiable files.
- With both Recycle Bin and Undo disabled, a file that is Deleted via Select > menu > tap delete > acknowledge permanent = is actually deleted and does not force the creation of the. recycle folder. That is good but…
- Now we get to the drum I may beat until the skin on my hand or the skin of the drum starts to crack. With both Recycle Bin and Undo disabled, Select > long press deletes still creates the .recycle folder and copies the file there. I don’t care what is done with the Recycle Bin because I don’t use it and that it sort the point. I dont use it but it still can happen. Even with all relevant options disabled it is all too easy for an intended delete operation to become a file copy operation into it another folder unbeknownst to the user and not with the scope of familiar locations where it might be discovered. Please give us a way to disable this.
Remember delete option remained disabled throughout testing.
.recycle folder was deleted between major test segments,
BTW @HootanParsa, assuming that both Beta and XDA version might be using the .recycle folder, are there any concerns for people who use Recycle Bin in multiple version of MiX (XDA, Silver, Beta)? This is not of concern to me as I only Recycle Bin in the beta for testing (so there is nothing potentially placed there by the XDA version is at risk) but I was curious about this.