When I plug my phone into my PC I can see a file on my SD card called 'Android' with my game data.
But when I open ES File explorer on my phone there is another file called 'android' (small 'a') which appears empty, but I can't delete it.
When I go up to root /data/media I can see what looks like my SD card with the 'Android' and 'android' folders but there appear to be duplicate files while others are missing or moved.
I think after flashing new kernels this week there are duplicate files being created. I often have to re-download game data after flashing a kernel and I seem to be losing a lot of SD memory.
I just want to know which folders should I delete?
Using superuser permission should allow you to delete the "android" folder or file. If ES Explorer don't work, try Root Explorer or do it in adb if you know how.
In linux file systems, A and a can be two different files or folders.
Or you can reflash google factory image and that will wipe the entire internal storage.
Thanks.
I managed to delete both the Android folders.
Had to re-download all my game data but I've ended up with about 3 gig more memory.
I have a weird problem with the G4 memory showing all files and folders in windows explorer.
It began with Vuze downloads (torrents), everytime I wanted to see a downloaded file on PC I had to move it from the Vuze folder to another one so windows explorer can see it.
Now more files are not appearing in windows explorer, from both internal and SD card, I reinstalled the drivers 3 times but still my Windows 10 can't see all the files produced on the G4, example I copied an app from system partition to external SD, I can see it on Root Explorer on the G4 itself but not on Windows!
What is the fix?
Yes my phone is rooted
Ok I think I have found the problem:
Some third party apps that write on the G4 memory (SD included) like Vuze will not write it with hidden LG ''permission'' so the files are unviewable on PC.
I updated my Root Explorer app to latest one and now I can see the files I cut or paste with it on Windows.
I have found this ''bug'' thanks to the stock G4 File explorer as it was the only app capable to cut and paste in the G4 memory and let it show in windows.
Vuze looks like it needs to be updated by its maker so the files downloaded are visible in windows, until then I will have to move them using the new Root Explorer or the stock G4 file explorer
I am unable to delete OBB folder located in "sdcard0/android/" it shows delete failed in root explorer and cynogen default file manager also
I have an Amazon Fire 8 HD and I'm currently trying to transfer an OBB file I have on my PC to my tablet's OBB folder via a USB cable... However, I'm not having any luck... When I try to do this, Windows 10 makes the jingle noise and the transfer fails with no notification. That said, transferring the OBB file to other folders doesn't work either as I tried a few others including the downloads folder. Any help with this please?
Note: transferring any other form of file such as APK works fine, it's just OBB that fails.
hello, since Android 13, Foldersync has no longer access to the Android/Data folder. Can someone help me or give a workaround?
Hi. If no one else has any other ideas, you can try the developer of the app. If this is the app here FolderSync, it shows the developer information as:
Developer contact​Website
http://www.tacit.dk
Email
[email protected]
Click to expand...
Click to collapse
BiBaBuTzE said:
hello, since Android 13, Foldersync has no longer access to the Android/Data folder. Can someone help me or give a workaround?
Click to expand...
Click to collapse
Some info...
Why an Android file manager can't open folders under /Android
File managers aren't supposed to be able to access folders under /Android, but a loophole let them. Android 13 closes that loophole.
blog.esper.io
https://twitter.com/i/web/status/1560716910001520641
Lughnasadh said:
Some info...
Why an Android file manager can't open folders under /Android
File managers aren't supposed to be able to access folders under /Android, but a loophole let them. Android 13 closes that loophole.
blog.esper.io
https://twitter.com/i/web/status/1560716910001520641
Click to expand...
Click to collapse
Hi, please can you explain step by step what i must do to get access to the Folder. Foldersync needs Access to this Folder. Thx a lot and have a nice day
I haven't tried it, but this is supposed to take care of the problem, if rooted...
GitHub - Magisk-Modules-Alt-Repo/NoStorageRestrict: Remove the restriction when selecting folders through SAF
Remove the restriction when selecting folders through SAF - GitHub - Magisk-Modules-Alt-Repo/NoStorageRestrict: Remove the restriction when selecting folders through SAF
github.com
In android 13, data and obb folders are blocked. Tried many file managers with root to copy game data in obb folder but failed. Even the Xposed module "no storage restrict" did not worked. Finally copied data through browsing "/data/media/0/Android/obb". You may try this with root.
I am using Evolution X 7.1 on Redmi Note 11.
There are some file managers that are catching up with this. MiXplorer and FV File Manager have updated to allow access to /Android/data & /obb directories in Android 12+.
Now I have access to Android/Data & Android/Obb but I can't paste any file to these folders. I use ES File Explorer. I don't want to use other file manager like MiXplorer and make the trick of splitting screen with drag & drop so that to write files to the above paths. How to make it in the ES File Explorer or if it exists some magisk or xposed module in which to disable this restriction and to be like in Android 12 in which we didn't have any problem in accessing or writing any file to above paths ?
Johnn78 said:
I use ES File Explorer.
Click to expand...
Click to collapse
This is your problem right here. ES File Explorer stopped working properly upon release of Android 11 or 12. I discontinued my modded versions of the app at that time and switched to something that DOES work.
Get another file manager.
This File Manager tends to work in A13, I moved from ES a long time ago when they removed some features, https://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore .
Strephon Alkhalikoi said:
This is your problem right here. ES File Explorer stopped working properly upon release of Android 11 or 12. I discontinued my modded versions of the app at that time and switched to something that DOES work.
Get another file manager.
Click to expand...
Click to collapse
When I went to Android 13 then I had ES File Explorer which didn't have access to Android/Data. Then I found ES File Explorer v4.4.0.2.1 which has the ability to have access to Android/Data but it hasn't the ability to write (via copy - paste) to Android/Data. This problem doesn't exist only to ES File Explorer but in all File Managers which I have used like File Manager+, File, MiXplorer, Xplore etc... The MiXplorer which can write to Android/Data not be done via copy - paste but via some trick by splitting screen and drug-drop the file which is some intermediate solution. If it is found some solution which can work the copy - paste to Android/Data then this will work to all File Managers which means that the problem isn't that the ES File Explorer is deprecated. May exist some magisk module or lsposed module which deactivate the SAF (Storage Access Framework) permission in which wasn't enabled in Android 12.
Johnn78 said:
This problem doesn't exist only to ES File Explorer but in all File Managers which I have used like File Manager+, File, MiXplorer, Xplore etc...
Click to expand...
Click to collapse
ES File Explorer, as I said in my previous post, no longer works with current versions of Android. This is because there is no one working on its code. No one to fix bugs when they appear. No one to ensure root functions continue to work. No one to enable proper access to Android/data.
There are file managers out there that are not ES File Explorer, and while you have tried some, you've not tried them all. I tried Root Explorer just now and had no problems copying files to /Android/data in internal storage; no tricks or workarounds needed. So I stand by my statement. Especially as the file manager I now use doesn't have this issue.