In my little file explorer app I show the number of sub-elements in each directory like:
To set those numbers, I launch an AsyncTask (so the ListView won't get "laggy") from my Adapter's getView() method and that for each item in the list. However, when viewing some system directories (like "/" for example) with huge number of subdirs and files, the garbage collector is going insane and performance drops significantly (multiple instances of my AsyncTask still stay in memory even after the app gets finished).
I'm quite sure this is related to how I implemented the subdirs and subfiles check that I'm doing inside the AsyncTask, but the following recursive approach is the only thing I could think of:
//countHidden is a boolean indicating whether to count hidden files
private int[] getSubFilesCount(File root) {
int fcount = 0;
int dcount = 0;
File[] files = root.listFiles();
if (files != null)
for (File f : files) {
if (f.isDirectory()) {
getSubFilesCount(f);
if (f.isHidden()) {
if (countHidden)
dcount++;
} else {
dcount++;
}
} else {
if (f.isHidden()) {
if (countHidden)
fcount++;
} else {
fcount++;
}
}
}
int[] tcount = { fcount, dcount };
return tcount;
}
The question: is there any alternative to get the number of subdirectories and files that will work faster then the approach posted above?
You could do what's suggested here which is effectively the same as you're doing but slightly more succinct (if you don't mind me saying so). Obviously you'd have to do it for files and directories. I believe Java 7 provides a better way of doing this but unfortunately you're limited to Java 6 at the moment with Android.
Related
I am developing an Android App. I have the below code to write a list of all files starting with XLR in a particular folder:
private List<File> getListFiles(File parentDir) {
ArrayList<File> inFiles = new ArrayList<File>();
File[] files = parentDir.listFiles();
for (File file : files) {
try {
if ((file.exists()) && (file != null)) {
if (file.isDirectory()) {
inFiles.addAll(getListFiles(file));
} else {
if (file.getName().startsWith("XLR")) {
inFiles.add(file);
}
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
return inFiles;
}
On Android 10 and 11 it seems to be a problem. For Android 10 I have legacy storage enabled and Android 11 I have got access to all files. So the issue is not file access.
The folder itself might not be in my app's folder, hence the need to be able to list out files
I know that there is an extensive page here on NPE's and I have tried my best to follow the advice there (I am checking that files exist and are not null), but still to no avail.
I feel that there's probably something so stupid, that a more experienced programmer would probably pick out in 2 seconds...
This problem would be easily solved just reading the documentation of the actual File package.
Documentation on the method File::listFiles:
An array of abstract pathnames denoting the files and directories in the directory denoted by this abstract pathname. The array will be empty if the directory is empty. Returns null if this abstract pathname does not denote a directory, or if an I/O error occurs.
As you can see, that method can actually return null and not only an empty array, so you should check that the value isn't null before even trying to iterate over it.
I'm trying to crawl the entire file system of an android device, both directories and files, without the benefit of NIO, to build a tree of it. If I had NIO then I could use WalkTree or similar, but I don't.
The problem I am having (on the Nexus 5 API 23 x86 emulator) is in /sys/bus/pci/devices and possibly other directories (eg /proc/self) - it doesn't complete before the app times out/quits/crashes (unknown which), possibly getting into some kind of loop or something (the path may change in a repetitive fashion but the canonical path varies little or not at all) .
However if I rule out Symbolic links then that problem goes away but I get what is only some of the files on the device rather than all - for example lacking files under /data (or /data/media/0) and those files not showing up elsewhere - not to mention it looks completely different from the file system that most file managers show. The former is strange as I'd understood Symbolic Links pointed to files and folders that were still present in the file system, but just made them look as if they were elsewhere.
What's the solution? Do I have to code exceptions or special handling for /sys/bus/pci/devices, /proc/self and others? I'd prefer to keep Symbolic Links being followed if I can, and I'd prefer to crawl as many files and folders as I can (so starting in a sub-folder is not preferred).
And a few related questions that might affect the approach I eventually take - if I DO keep SymLinks then does that mean that some things will be crawled twice or more? Is there a way to avoid that? Is there a way to detect when something is the TARGET of a SymLink, other than following the SymLink and checking the CanonicalPath?
Here's my code:
I get the root (I understand that in Android, the first and likely only root is the valid one):
File[] roots = File.listRoots();
String rootPath = "";
try {
rootPath = roots[0].getCanonicalPath();
} catch (IOException e) {
// do something
}
Then I start the crawl (note the boolean to choose whether to ignore simlinks or not):
try {
// check if the rootPath is null or empty, and then...
File rootFile = new File(rootPath);
rootNode = new FileFolderNode(rootFile, null, true, false); // last param may be true to ignore sim links
//FileFolderNode(String filePath, FileFolderNode parent, boolean addChildren, boolean ignoreSimLinks)
} catch (Exception e) {
// do something
}
That uses the FileFolderNode, which has constructor:
public FileFolderNode(File file, FileFolderNode parent, boolean addChildren, boolean ignoreSimLinks) throws IOException {
if (file == null)
throw new IOException("File is null in new FileFolderNode");
if (!file.exists())
throw new IOException("File '" + file.getName() + "' does not exist in new FileFolderNode");
// for now this uses isSymLink() from https://svn.apache.org/repos/asf/commons/_moved_to_git/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java adjusted a bit to remove Java 7 and Windows mentions
if (!ignoreSimLinks)
if (FileUtils.isSymlink(file))
return;
this.name = file.getName();
if (this.name.equals("") && ! file.getCanonicalPath().equals("/"))
throw new IOException("Name is empty in new FileFolderNode");
this.isDirectory = file.isDirectory();
if (this.isDirectory) {
this.children = new ArrayList<FileFolderNode>();
if (addChildren) {
File[] files = file.listFiles();
if (files == null) {
// do something
} else {
// add in children
for (File f : files) {
FileFolderNode child = null;
try {
child = new FileFolderNode(f, this, addChildren, ignoreSimLinks);
} catch (Exception e) {
child = null;
}
if (child != null)
children.add(child);
}
}
}
}
}
Given the lack of answers here, I've broken this question down into areas needing clarification, and am trying to get answers to those - please do see if you can help with those:
Get Android Filing System root
Android SymLinks to hidden or separate locations or partitions
Avoiding Android Symbolic Link loop
When I plug my device into big computer I see the following picture
How to find these (two) directories programmatically from withing Android application?
UPDATE
I wrote utility class to deduce roots. Unfortunately, it works for minSdkVersion=19
public class RootsUtil {
private final static String seed = Environment.DIRECTORY_PICTURES;
public final static File[] getRoots(Context context) {
File[] paths = context.getExternalFilesDirs(seed);
if( paths.length <= 1 ) {
return new File[] { Environment.getExternalStorageDirectory() };
}
else {
while(true) {
int count = 1;
for (int i = 1; i < paths.length; ++i) {
if (paths[0].getName().equals(paths[i].getName())) {
count++;
}
}
if( count==paths.length ) {
for (int i = 0; i < paths.length; ++i) {
paths[i] = paths[i].getParentFile();
}
}
else {
break;
}
}
return paths;
}
}
}
The question persists: are there any solutions for at least SDK=15?
P.S.
People downvoting this (absolutely normal) question: you are just declaring yourselves a clowns.
How to find these (two) directories programmatically from withing Android application?
You don't.
The one labeled "Phone" presumably is what the Android SDK refers to as external storage. I say "presumably" because device manufacturers seem to change this label — I usually see it called "Internal" or "Internal storage". To get the root of external storage, use Environment.getExternalStorageDirectory(). Note that this requires that you hold the READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permissions, which includes asking for those permissions at runtime.
The one labeled "Card" presumably is referring to some removable media. You cannot work with the root directory of removable storage.
Maybe this will help you:
https://stackoverflow.com/a/40123073/5002496
thanks to that method you can list all mounted external storages paths. I am using it in my project to store data in sd-card and tested it on more than 20 devices.
I need to list all images in a users drive cloud.
I use https://www.googleapis.com/drive/v2/files with the correct filter to query all images. I need to group the result in my app in folders. I know a file can have multiple parents, that's fine.
I would like to avoid making and calls (for every single file a single call) to get a files folder via https://developers.google.com/drive/v2/reference/files/get using the parent id from the first call.
Is there a network friendly way to get all files inclusive there folders?
EDIT
A simple solution would be to get all folders with ids in one query and lookup folder names in this result. Maybe that's somehow possible?
As you answered yourself in the comments above (but you can't match names, you have to match IDs; names aren't unique).
Step 1: get all your folders in one shot (paging results, filtering unneeded fields, skipping the trashed ones):
private static Drive mGOOSvc;
....
static ArrayList<ContentValues> getFolders() {
ArrayList<ContentValues> cvs = new ArrayList<>();
if (mGOOSvc != null) try {
Drive.Files.List qry = mGOOSvc.files().list()
.setQ("mimeType = 'application/vnd.google-apps.folder'")
.setFields("items(id,labels/trashed,parents/id,title),nextPageToken");
String npTok = null;
if (qry != null) do {
FileList gLst = qry.execute();
if (gLst != null) {
for (File gFl : gLst.getItems()) {
if (gFl.getLabels().getTrashed()) continue;
for (ParentReference parent : gFl.getParents())
cvs.add(newContentValues(gFl.getTitle(), gFl.getId(), parent.getId()));
}
npTok = gLst.getNextPageToken();
qry.setPageToken(npTok);
}
} while (npTok != null && npTok.length() > 0);
} catch (Exception e) { /* handle Exceptions */ }
return cvs;
}
Step 2: Parse the resulting ArrayList to build the tree structure (match ParentIds, handle multiple parents)
Step 3: Do the same for files with mime type ""image/jpeg", "image/png", ... "whatever img mimetype" (just modify the code above to get files) and parse again.
Of course the 'execute()' method will produce exceptions that should be handled as pointed out here.
... and you can take the 'not so network friendly' approach of iterating down the folder tree as seen in the 'testTree()' method here. Recursion is necessary if you have no knowledge how deep your tree structure is.
Good Luck
The process seemed quite simplistic at first, but there must be something that I am missing going forward with this task. There was a settings file that I wanted to create local to my application for storing a whole bunch of data (not preference worthy). I ended up saving the file with the following code snippet.
protected File createSettingsFileLocation(String fileNameF)
{
File directoryFile = context_.getDir("settings", Context.MODE_PRIVATE);
File settingsFile;
settingsFile = new File(directoryFile, fileNameF);
if (!settingsFile.exists())
{
try
{
settingsFile.createNewFile();
} catch(IOException e)
{
Log.e(MyConstants.LOG_TAG, "Could not create the file as intended within internal storage.");
return null;
}
}
return settingsFile;
}
and then proceeded to retrieve the file later by looking for it locally with the following code snippets.
public String getCurrentFileContainingSettings()
{
List<String >settingFilesInFolder = getLocalStorageFileNames();
if (settingFilesInFolder == null || settingFilesInFolder.isEmpty())
{
return null;
}
String pathToCurrentSettingsFile = settingFilesInFolder.get(0);
return pathToCurrentSettingsFile;
}
protected List<String> getLocalStorageFileNames()
{
return Arrays.asList(context_.fileList());
}
However, the settingFilesInFolder always returns no entries, so I get null back from the getCurrentFileContainingSettings(). As what I could see from the documentation it seems as thought I was doing it right. But, I must be missing something, so I was hoping that someone could point something out to me. I could potentially hard-code the file name once it has been created within the system in a preference file for access later the first time that the settings are created, but I shouldn't have to do something like that I would think.
fileList() only looks in getFilesDir(), not in its subdirectories, such as the one you created via getDir(). Use standard Java file I/O (e.g., list()) instead.