You need to navigate from the full root path, so open the sidebar and go to root then its /sdcard/android/data
Would also try and get a log to see why you cannot access the folder with the latest beta as I can with my pixel 4a on android 13
Would also try and get a log to see why you cannot access the folder with the latest beta as I can with my pixel 4a on android 13
Many Many Thanks. I am able to access/rename folders after going through root/sdcard/android/data. So the direct way of accessing the android/data folder is not possible E
Even with root..right? Is it because of limitation of android 13..?
You dont need to have root to access the android/data folder although there seems to be problems with different devices, on the latest beta on my pixel 4a android 13 I can access android/data without issue, so to understand why you cannot would need a log to see what is going on, try and do a folder rename or whatever it is that is failing and then get a log, (tap the 3 dots Send log)
I'm getting more confused.
Now I'm sure MiXplorer is collecting data. For example when it's saving user email/password for FTP connection. But sharing?! A user enters email/password to login to his/her own account. It it sharing with third party apps?!! Sigh!
Goodness gracious! Google's instructional copy is even more verbose than I and is needlessly abstruse as well, so for what this is worth from someone else who saw a need to assemble Google's documentation into a more manageable presentation.
https://www.termsfeed.com/blog/google-data-safety-form/
------------------
In a section titled "Collection of Data" , in addition to the 4 statements previously mentioned there is this:
"According to Google, if your app transmits data from off a user's device, that's the definition of "collect.""
There is also an inserted image of text which lists items that are "Not in scope for data collection"
------------------
As to email and cloud credentials, this may (or may not) indicate that they are exempt:
From "Data Sharing" section there is another image of text titled "The following types of data transfers do not need to be disclosed as "sharing"" in which there is an entry for "Service Providers" that process the data on behalf of the developer.
I say No, Mixplorer does not collect, let alone share, user data.I'm getting more confused.
Now I'm sure MiXplorer is collecting data. For example when it's saving user email/password for FTP connection. But sharing?! A user enters email/password to login to his/her own account. It it sharing with third party apps?!! Sigh!
I think the problem may be that there is a space on a Google form where you are supposed to list all the types of data you collect. A reasonable person would leave it blank if there is no such data. Google wants you to write "no such data". Repeatedly.
... but does that line up with this?
"According to Google, if your app transmits data from off a user's device, that's the definition of "collect."
By that definition would not the copying of files to another device via cloud bookmark, (or maybe even the receiving of files to MiX FTP or other server) be considered "collected".
That being said, +1 to the possibility that this is an issue with managing the form and not the actual tech. Supporting your suggestion about that is a comment at one of the websites to which I shared links which stated that Google lets you put any answer there and it's a matter of trust but they want something there but IDK if the form uses drop-downs or manual text entry.
Last edited:
The form doesn't give me option if I just say no this app is not collecting or sharing user data. But if I say yes, then it will ask "Do you provide a way for users to request that their data is deleted?".
So I don't know what that email address issue is.
'Undo' is back. Fresh changelog awaited.
Attachments
@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.
Notes:
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.
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.
Notes:
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.
Last edited:
- 'Remember Delete option' will remember the last selected option in dialog.
- Uncheck 'Recycle bin' to hide the 'Recycle bin' option in dialog. Then you can only long press on Delete button to send files to recycle bin and delete later.
- 'Undo' is a separate feature to also be able to undo some other operations. I added this option because I'm afraid the operations in the older devices will become slower. The saved file paths are encrypted.
The reason for enabling 'Recycle bin' by default is that some users sent me messages (some with F words) about losing their files, because they thought they will go to recycle bin like in the other operating systems.
Last edited:
Attachments
I feel for you; you must be riled by messages from those ingrates who should actually be thanking and supporting you for such a terrific 'swiss army knife' file manager.
Putting aside my utter disdain for the author of "from off a user's device" there is the exception
I believe this would cover cases like "user requests connection to an FTP server and provides a username and password"
@HootanParsa I'm confused. Are you saying there is no option to say "this app is not collecting or sharing user data"? And what "email address issue"?
The article @IronTechmonkey found includes references to some automatic privacy policy disclosure generator. If you use that generator, it will ask you, the developer / publisher, for an e-mail address to which the generated privacy policy disclosure will be e-mailed for subsequent inclusion in a web site or app.
According to that article, Google does recognize the possibility that an app will not collect any data. Are these disclosure forms publicly available? Maybe it would help to see one for an app that does not collect any data -- an app that Google has already approved. (How you would find such an app, I do not know.)
The option is already selected last year but now they're saying you have to change it because your app is collecting or sharing user's email address. Only MediaFire and Mail.ru need to enter email address locally and MiXplorer doesn't share it. It just uses to login to user account. It will encrypt and save it on user device.
Edit: I saw another similar file manager has selected the Yes option. I will update the options on Play console and will share the screenshots.
Edit: There was a mistake. Only MediaFire and Mail.ru need email address, not even Mega.
Last edited:
This effectively turns a permanent delete action into a file copy action which a user might not realize has occurred and which may leave private data elsewhere on the device unknown to the user. The long press delete function is like a qualifier key to force enable recycle/trash and no other recycle/trash system I know of does anything like that. It effectively means the recycle function cannot be disabled.*
Windows: Leave the recycle bin enabled and have "deleted" items go there, or disable the recycle bin so items are permanently deleted, and when the recycle bin is enabled a qualifier key can be used to permanently delete an item by bypassing the recycle bin. There is nothing like a qualifier key to force something to the recycle bin when that setting is disabled.
IOS and Linux: Trash/Recycle cannot simply be disabled (unless by a system hack) so there is no permanent delete without qualifier key as there is in windows, but there is a qualifier keys to permanently delete items by bypass the trash/recycle bin. In these operating systems as well, there is nothing like a qualifier key to force something to the recycle bin because the bin is always enabled.
Understood. I was reporting that it is not working as expected. Expanding from my previous post, in all cases where Undo should have found something to Undo, there was only a toast “no item”. Maybe other people can provide feedback. Tomorrow, I can log it.
- Possible clarification about wording. “enabling 'Recycle bin' by default” sounds like a statement regarding the default setting of the recycle bin in new installations or updates. It does not speak to the function which concerns me (and which cannot be disabled), which I would describe as “Long press delete to force enabling of recycle bin/send file to recycle.”
- No wonder that person made their case through DM, it is absurd on its face. I hesitate to go that far with criticism even when there’s sharp disagreement but what they expect is truly absurd. They are demanding, because they disabled or failed to enable their recycle bin, that the ability to actually disable the recycle bin be removed, and that now everybody else must be forced to accept automatic enabling of the recycle bin even if they chose to disable it; with this all being contrary to what all other operating systems do (a fact which they seem confused about).
One of the many things which distinguishes MiXplorer is that, as with the Windows, the recycle bin can be completely disabled. Enabling the recycle bin for new installations (but not for updates) seems reasonable enough protection; if someone thereafter disables the recycle bin that's their responsibility. It does not seem fair that if they make that mistake that no one else must be able to truly disable the recycle bin, so I do hope you reconsider and either remove that functionality or provide a way to truly disable the recycle bin.
As to F words... I have one for tonight and it is Fangs, but I'll continue to pretend not to have figured out who made that request
.
Last edited:
OK, I will work on it...This effectively turns a permanent delete action into a file copy action which a user might not realize has occurred and which may leave private data elsewhere on the device unknown to the user. The long press delete function is like a qualifier key to force enable recycle/trash and no other recycle/trash system I know of does anything like that. It effectively means the recycle function cannot be disabled.*
Windows: Leave the recycle bin enabled and have "deleted" items go there, or disable the recycle bin so items are permanently deleted, and when the recycle bin is enabled a qualifier key can be used to permanently delete an item by bypassing the recycle bin. There is nothing like a qualifier key to force something to the recycle bin when that setting is disabled.
IOS and Linux: Trash/Recycle cannot simply be disabled (unless by a system hack) so there is no permanent delete without qualifier key as there is in windows, but there is a qualifier keys to permanently delete items by bypass the trash/recycle bin. In these operating systems as well, there is nothing like a qualifier key to force something to the recycle bin because the bin is always enabled.
Understood. I was reporting that it is not working as expected. Expanding from my previous post, in all cases where Undo should have found something to Undo, there was only a toast “no item”. Maybe other people can provide feedback. Tomorrow, I can log it.
- Possible clarification about wording. “enabling 'Recycle bin' by default” sounds like a statement regarding the default setting of the recycle bin in new installations or updates. It does not speak to the function which concerns me (and which cannot be disabled), which I would describe as “Long press delete to force enabling of recycle bin/send file to recycle.”
- No wonder that person made their case through DM, it is absurd on its face. I hesitate to go that far with criticism even when there’s sharp disagreement but what they expect is truly absurd. They are demanding, because they disabled or failed to enable their recycle bin, that the ability to actually disable the recycle bin be removed, and that now everybody else must be forced to accept automatic enabling of the recycle bin even if they chose to disable it; with this all being contrary to what all other operating systems do (a fact which they seem confused about).
One of the many things which distinguishes MiXplorer is that, as with the Windows, the recycle bin can be completely disabled. Enabling the recycle bin for new installations (but not for updates) seems reasonable enough protection; if someone thereafter disables the recycle bin that's their responsibility. It does not seem fair that if they make that mistake that no one else must be able to truly disable the recycle bin, so I do hope you reconsider and either remove that functionality or provide a way to truly disable the recycle bin.
As to F words... I have one for tonight and it is Fangs, but I'll continue to pretend not to have figured out who made that request
View attachment 5819271
Thanks, and to use more F words, it would not surprise me if you find a fair solution. BTW for a different perspective on "bugs", zoom into the picture of the hyena and check between its eyes. That must be a frustrating bug, no wonder the hyena is snarling, I wonder if it has an official bug tracker.
Did Google explain what made it think Mixplorer was collecting an e-mail address?
I understand that you could be at the mercy of a Google 'bot, or a Google drone, but if there is a rational human reading what you write, it should be possible to explain that you are acting at the direction of the user when you submit a username and password, even if the service in question requires that the username be an e-mail address.
@HootanParsa For what it's worth, the "program" "Exec Lua" on the Google Play Store has a "Data Safety" section that says "no data is collected or shared".
Now if you can figure out why Google thinks you are collecting e-mail addresses...
Now if you can figure out why Google thinks you are collecting e-mail addresses...
This is what they sent me:
Attachments
Similar threads
Top Liked Posts
-
4
There have been no reports here at XDA about that since 6.59 was released (I'm not sure about reports at Play Store). I never use the feature so I would not know what to expect but, you may have discovered a glitch worth logging, and sharing details about how the issue is reproduced.
[EDIT] @rsngfrce, you might want to double check your workflow as well. I cannot tell if there was a change in behavior because I did not previously use it but, in a quick test in MiX Beta 6.59.0-BETA B23012920 (should be same as yours) the merge tasks feature functions as might be expected. When the second task of a given type (copy or move) is being queued there is a prompt to add it to the other tasks of that type. Adding it to the existing task queues both of them as if they are one task in the queue, and that task runs all of the merged subtasks. If that is not working for you then you should definitely consider logging this and sharing the specific steps that you take when reproducing the issue.4Update to Servers FAQ Post: https://forum.xda-developers.com/t/mixplorer-q-a-and-faq-user-manual.3308582/post-65157350. General cleanup, significant rearrangement of sections, Addition of section "Starting servers" and new subsection for creating deeplinks (text of the new copy is quoted here: https://forum.xda-developers.com/t/mixplorer-q-a-and-faq-user-manual.3308582/post-8806822744
An internet connection is not required for the feature to function properly or to configure the shortcuts. There is a mixplorer.com site but AFAIK at the moment it only contains information. This deeplink does not attempt to access the site; IIRC MiX intercepts the link and redirects it to toggle the server. The only reason I mentioned internet access was because the behavior of browsers, when creating the home screen shortcut, may vary across different browsers and depending on whether or not there is an active internet connection. IE, I could not create the home screen shortcut after merely pasting the link into the browser URL bar; an attempt to access the site was required, but whether that failed because there was no connection or because that link goes nowhere on the site the resulting shortcut was functional.3 -
12
- 'Remember Delete option' will remember the last selected option in dialog.
- Uncheck 'Recycle bin' to hide the 'Recycle bin' option in dialog. Then you can only long press on Delete button to send files to recycle bin and delete later.
- 'Undo' is a separate feature to also be able to undo some other operations. I added this option because I'm afraid the operations in the older devices will become slower. The saved file paths are encrypted.
The reason for enabling 'Recycle bin' by default is that some users sent me messages (some with F words) about losing their files, because they thought they will go to recycle bin like in the other operating systems.12
It's not just about the Trash bin.Now the word "Trash" is gone so what will Mac users do?
But seriously, even though I agree with the change in terminology the new label is so long as to undermine itself as a label.
@HootanParsa, here is a suggestion which might accommodate all user preferences while making the label shorter by renaming it to the following:
Recycle (also known as Undo or Trash).
If you enable Undo, you will be able to undo operations like Moving, Renaming, Sending to trash/recycle bin and...
Edit:
I will add a different option for Recycle/Trash bin.10FYI, almost all settings are listed here, including a change to the way they are structured which was made some time ago: https://forum.xda-developers.com/t/mixplorer-q-a-and-faq-user-manual.3308582/post-82834917.
Settings > More settings > undo. That setting has not moved in a long time.
It seems that in some cases we may have to disable Undo again after this new update, but that should be a one-time thing.
View > Options (thumbnail and preview settings are here)
There are several view settings which might be applicable (eg more details, and others) and there is also Settings > More settings > custom date time
...
...And they still are configurable. You just lost track. At some point the settings were separated into different groups including these three.
Settings > More settings...,
and
View > Options (thumbnail and preview settings are here)
and
Sort > Options
Speaking from experience, few settings have been removed, just rearranged once, and there are many new settings.10
Your case is different.Using /mnt/user/0/emulated/0 as working directory on the ftp settings allows to access /Android/data
Thanks!
I cannot upload to XDA now. Download the latest BETA from here.10
More annoying than people who can't read a few pages back in a thread, or maybe even search the thread which would lead you to your answer and/or the amazing MiXplorer thread by @IronTechmonkey that has loads of useful info. Just like what you were asking about. -
2919Downloads
Download the latest updates from Drive.
The latest MiXplorer (com.mixplorer API-29 & API-33)
and the BETA build (com.mixplorer.beta)
Get MiX Silver
from Play Store (com.mixplorer.silver)
to support the development of this project.
Downloads from any other source are not recommended.
FAQ MiXplorer Q&A and FAQ (User Manual)
LOG How to report a bug
If you're going to report a bug, first install the latest BETA, try to reproduce the error, then if it's still happening, write a post and explain the issue with the attached log file from the main menu > Send log. Thank you.
• Themes by @djdarkknight96
• Themes by @TerrorFlatRider
• Themes by Vladimir
• Windows Fluent Design theme by @marciozomb13
• Material Design theme by @marciozomb13
• Theme Corporate
• Guillaume Skins Gallery
• YandLiu Skins Gallery
•Skins by @scohut2363[APP][2.2+] MiXplorer (full-featured file manager)
Hello everyone!
My name is Hootan. I work on XDA in my free time and this file explorer is my favorite Android project!
MiXplorer mix of explorers (SD, FTP, Lan, Cloud and other storage explorers) is a fast, smooth, beautiful, reliable and full-featured file manager with a simple and intuitive user interface.
This app has no ads, is and will always remain free.
It supports Android 2.2+ (Froyo)
I hope you enjoy it.
Features
The best way indeed is to explore yourself. But here's a brief list of essential features:
FAQ MiXplorer Q&A and FAQ (User Manual)
LOG How to report a bug
If you're going to report a bug, first install the latest BETA, try to reproduce the error, then if it's still happening, write a post and explain the issue with the log file from the main menu > Send log. Thank you.
If you have any ideas, suggestions or you found a bug/mistake, feel free and let me know.
Email: [email protected]
Screenshots419Changelog
v6.59.0_B23012940:
• Added a separate option for Recycle bin in the settings page > More settings.
• Added deeplinks to turn the servers on and off:
- https://mixplorer.com/app/ftp/trigger
- https://mixplorer.com/app/sftp/trigger
- https://mixplorer.com/app/http/trigger
- https://mixplorer.com/app/smb/trigger
• Some tiny improvements and bug fixes.
v6.58.8_B22090510:
• Enabled Undo feature by default. You can disable it from the settings > More settings > Undo.
• Fixed some issues and tiny improvements.
v6.58.5_B22090510:
• Fixed accessing to /Android/data and /obb directories in Android 12+.
• Fixed crashing while decoding some types of HEIC images.
• Fixed crashing Code editor because of a bug in a system method used by GBoard app on Android 12+.
• Fixed some issues in SQLite DB editor.
• Changed to use the internal browser to login to DropBox by default.
• Added ID3 version options for MP3 files in Tags editor dialog.
• Added Metadata/Tags/Comment option in Search dialog.
• Some other bug fixes and improvements.
v6.58.4_B22020920:
• Fixed some issues in previous builds.
v6.58.1_B22020120:
• Fixed group of issues was made during compiling the codes.
v6.58.0_B22013120:
• Added SFTP and SMB1 servers. (experimental)
• Added 'Reload' and 'Start at the end of text' menu options in Code/Text editors. And 'Tab with 4 spaces' for Code editor.
• Added AXML editor.
• Added 'Don't show in recent activities' option in app selection dialog.
• Added support for AVIF and multipage HEIC images.
• Removed 'Root directory' from FTP server settings. It will be the same as the 'Working directory'. Added 'Force this directory'.
• Moved Add > 'Document provider' to Add > 'Storage'.
• Improved local IP scanner.
• Fixed some issues with editing SQLite files.
• If user is anonymous in FTP-Client, working directory will be read-only. Default user is Admin.
• Many other fixes and improvements.
v6.57.6_B21121040:
• Improved FTP/Share server performance and compatibility.
• Many tiny improvements, optimizations and fixes.
v6.57.5_B21111410:
• Added the list of current possible IPs for the server, in the Server settings.
• Added sending the list of video files in the current folder to MX Player.
v6.57.4_B21111220:
• Added settings to set the server port for SendTo feature.
• Some tiny fixes and improvements.
v6.57.3_B21110910:
• Fixed some issues with FTP(S-ES) server.
• Fixed reading /data/data directory.
• Fixed some other issues.
v6.57.2_B21110510:
• Added SSL option for Servers again.
• Added Explicit mode and content encryption support for FTP server.
• Added Filter extensions for thumbnails. Long press on the address bar.
• Added custom keystore and key manager in the servers settings page.
• Added 'Archive files separately' option in the Archive dialog, if there are multiple files/folders.
• Added starting FTP/HTTP servers without WIFI.
• Added custom IP input in the servers settings page.
• Added 'nameio/block32' filename encoding support for EncFs.
• Added Multi-user support for the servers. Default user is Admin.
• Removed TCP server. Use FTP/Share server.
• Improved Send-To function and added Archive option.
• Fixed an issue with some compressors. Archive add-on needs to be updated.
• Fixed starting servers on boot.
• Fixed an issue with searching files in the system directories.
• Fixed selecting files from Viber and some other apps.
• Fixed adjusting the new file size when editing MP3 tags.
• Fixed an issue with updating the Android media store.
• Fixed typing lags in Code Editor.
• Fixed opening some type of files from Gmail app.
• Fixed selecting files from some other apps.
• Fixed uploading an empty file to OneDrive.
• Fixed editing a text file in OneDrive with Code Editor directly.
• Fixed opening user home directory for FTP server.
• And some other tiny fixes and changes.
392Languages
See List of v6.x language add-ons
If you want to help to translate to your language, send me an email to [email protected]
