In an app I'm working on I have a file manager that uses File.listFiles() to retrieve all the files in a directory. This works perfectly fine on a Samsung Galaxy S3 but on a Nexus 7 tablet with KitKat 4.4.2 some of the directories are missing. The app has permissions to read and write to external storage.
The directories missing are particularly the ones I created recently. I checked the permissions on those and they are the same as the directories that get listed (771). Other file managing apps are able to list them all. Would this be a problem with the system not reindexing the directories?
Is there an alternative to File.listFiles() that would work better?
Obviously the other file managing apps are using a different method since they work fine.
I've tried some suggestions I found online about forcing a media re-scan but all the apps that I tried crash (seems to be an Android 4.4 related issue).
EDIT: I seem to have found the reason, which still puzzles me. There was a call to a function getFileExtension() that was returning NULL and caused some directories to no get listed. The call was done only if the item was not a directory but somehow it affected the execution flow:
if (ff.isDirectory()) {
dir.add(new Option(ff.getName(), "Folder", ff.getAbsolutePath()));
} else {
if (getFileExtension(ff.getName()).matches("WAV|AIFF|AIF|AMB|MP3|OGG|FLAC")) {
fls.add(new Option(ff.getName(), String.valueOf(ff.length()), ff.getAbsolutePath()));
}
}
The funny thing is that the same code ran OK on the Galaxy S3 (with Android 4.3).
Related
I am trying to copy photos onto my Android Emulator. I have tried
dragging photos onto the device screen (copying files popup does show up), but the photos do not appear anywhere. This worked on Android 8.1 and 10.
tried adb-pushing photos onto an Android 11 emulator. Although adb-pushed files are present on the file system (on both /sdcard/DCIM and /sdcard/Pictures), they do not show up on the device. I used adb push * /sdcard/DCIM, in a local directory with 24 photos.
I have also tried restarting the emulator (using the restart button on the Android UI), and no images were found. These images still exist on the filesystem. (This rules out me starting an older snapshot)
Unfortunately, the Files app shows these folders to be empty, even after restarting the emulator (Android UI restart button). My method working previously, but for some reason, can't copy photos onto the device now. Does anyone have a better method, or can confirm this method works for them?
Running Android Studio 4.1 (and tried 4.2 Canary) & Android 11.
Since 2 people have upvoted, I wanted to let you know how I work around this. After pushing the files to the device, I always restart it, and wait a couple of the minutes. This allows the MediaStore (which also handles stuff I would say is non-media, e.g. documents) to find the new pictures and add it to its own database.
Using stock Android 6.0 (Marshmallow), the stock (LG V10) gallery application (version 4.72.6) is including pictures and other files that have a timestamp newer than the .nomedia file timestamp. I have not been able to test this on other devices to see if it is LG specific.
Recreating the .nomedia file will update the timestamp, and hide all older pictures. Also, the folder being index is a hidden one (starts with a '.'), not sure why it is also being indexed in the first place.
There seem to be a lot of topics on this indexing issue, but none associated with the timestamps. It appears this could have been done intentionally, but it is very undesirable since several applications cannot access the microSD card after the Android permissions update.
I am getting a low storage notification from android on my Samsung tablet , and due to this my application is unable to write on a file , perform database operations like insert.
By searching i found out that , by dialing *#9900# and deleting logcat/dumpstate solves the problem , and it worked too.
There is also a method named onLowMemory() , which gets called when whole device memory is low, and may be it will work in my case , and I will show a notification in my app.
But my question is , whether android itself clears data from /data/log folder or not ? if yes , what is the time period ? Or we always have to use *#9900# to delete data from /data/log folder ?
Device name : Samsung Galaxy Note 10.0
Android version : 4.0.4
According to google results it seems like this is a Samsung related problem.
Most of the files inside /data/log are dumpstate files which means they store the state of the system/driver which crashed or had to be restarted for whatever reason.
These file will never deleted by the system because they contain information which could be used to fix the problem. Usually the folder should never get that big but it seems like it's a common problem on some Samsung devices. I guess they had a bug in a driver for some firmware versions.
Here is an related question: https://android.stackexchange.com/questions/48279/what-are-these-dumpstate-logs
I have made an app in Android, which is basically a File Browser. It shows all the files correctly in all devices perfectly, but not in one of my phones - Xperia SL.
It used to work properly in that phone, before I used ASYNC Task to load files asynchronously. After I did that, id doesn't show any file or any folder, just the LOST.DIR folder.
It works in all other phones perfectly, I have tested in 4-5 devices.
Can any one please suggest something?
I get the following error on my Android device:
E/OsclNativeFile( 1616): OsclNativeFile::Seek lseek64 failed
I want to know what it means, because I wasn't making anything special just getting a battery drain and the logcat show me zillion lines like the above. Thanks.
I got the same. That happened after i had updated my LG Optimus One P500 phone to android 2.3.3. I read this topic with no answers and was a bit disappointed. I tried to come back to 2.2, but phone didn't start (it stopped at android logo). I installed 2.3.3 again and it started normally. Then i experimented and soon noticed that there was no errors with sd-card unmounted. So I removed all programs from sd-card, and deleted all files from it (I moved it to laptop). And I have no such errors now. Maybe there is an easier way to solve it, but it has worked in my case.
The lseek64() system library function is typically used to access large files (2GB or greater). It's possible there's a flaw with the way the platform implements lseek64. A workaround--as tonixart has discovered--is to delete the large files on your sdcard.