WAI
Status Update
Comments
am...@google.com <am...@google.com> #2
Hi Google, this is very important for a company that makes product like we do http://carbyne911.com/
We deliver a life saving platform for 911 centers around the world, making it easier to emergency services for all kinds to get faster to citizens, including indoor and outdoor location and we're relaying in some case on the admin area to help us direct the forces
Please consider adding it to Singapore and other missing countries
We deliver a life saving platform for 911 centers around the world, making it easier to emergency services for all kinds to get faster to citizens, including indoor and outdoor location and we're relaying in some case on the admin area to help us direct the forces
Please consider adding it to Singapore and other missing countries
am...@google.com <am...@google.com> #3
Thanks for your suggestion!
We have passed the suggestion on to the product team for further consideration.
Please star to add your vote and receive further updates, and feel free to add any comments to discuss your use case.
*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************
We have passed the suggestion on to the product team for further consideration.
Please star to add your vote and receive further updates, and feel free to add any comments to discuss your use case.
*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************
lb...@gmail.com <lb...@gmail.com> #4
I've transitioned from this team. Thanks!
am...@google.com <am...@google.com> #5
That's correct behavior.
getExternalStorageDirectory() on the device is still pointing at the emulated internal storage.
If you want to use the SD card in this way, you'll have to adopt the card and then move the primary shared storage to that location during the adoption wizard flow. Note that adoption cannot be done on OTG devices because they're unstable, but there is a developer option to enable it.
http://developer.android.com/about/versions/marshmallow/android-6.0.html#adoptable-storage
DUMP OF SERVICE mount:
...
Primary storage UUID: null
StatFs stat = new StatFs(Environment.getExternalStorageDirectory().getPath());
long bytesAvailable = (long)stat.getBlockSize() *(long)stat.getBlockCount();
long megAvailable = bytesAvailable / 1048576;
System.out.println("bytesAvailable :" + bytesAvailable);
getExternalStorageDirectory() on the device is still pointing at the emulated internal storage.
If you want to use the SD card in this way, you'll have to adopt the card and then move the primary shared storage to that location during the adoption wizard flow. Note that adoption cannot be done on OTG devices because they're unstable, but there is a developer option to enable it.
DUMP OF SERVICE mount:
...
Primary storage UUID: null
StatFs stat = new StatFs(Environment.getExternalStorageDirectory().getPath());
long bytesAvailable = (long)stat.getBlockSize() *(long)stat.getBlockCount();
long megAvailable = bytesAvailable / 1048576;
System.out.println("bytesAvailable :" + bytesAvailable);
lb...@gmail.com <lb...@gmail.com> #6
@4 What is the code that you should use to get the total&free space available on all kinds of external storage, including USBOTG storage devices?
Stable or not, the API should be the same, because a file is a file. It doesn't matter where it is created and where it is modified. There should be a universal, easy, way to handle files, and since we already have one from the very first API and on Java itself (File), it should remain this way.
Stable or not, the API should be the same, because a file is a file. It doesn't matter where it is created and where it is modified. There should be a universal, easy, way to handle files, and since we already have one from the very first API and on Java itself (File), it should remain this way.
is...@gmail.com <is...@gmail.com> #7
[Comment deleted]
is...@gmail.com <is...@gmail.com> #8
@4 I did not understand your answer. Your code:
StatFs stat = new StatFs(Environment.getExternalStorageDirectory().getPath());
long bytesAvailable = (long)stat.getBlockSize() *(long)stat.getBlockCount();
gives me a primary (phone, internal) memory size, NOT AN USB OTG FLASH DRIVE SIZE in PORTABLE MODE.
Would you be so kind to explain more precisely or give me a link to a source code with answers on next questions -
if I write file manager application and would like to give my users an access to EXTERNAL USB OTG FLASH DRIVE in a PORTABLE MODE under Android 6.0:
1. Is it possible with API 23? I didn't see file manager apps on Google Play that give such an access. The only way is to use USB host API (ES Explorer). Other way is to use your VERY RUDIMENTARY file manager shipping with Android 6.0 or root the device.
2. Is there API call to give me available memory on EXTERNAL USB OTG FLASH DRIVE in a PORTABLE MODE?
Let me emphasize that:
1. I WOULD NOT LIKE TO ADOPT external USB OTG flash drive as a primary memory - I already have such memory inside of my phone.
2. I WOULD NOT LIKE TO EXTEND existing primary (phone, internal) memory by means of USB OTG flash drive.
3. I WOULD NOT LIKE TO ALLOW Android make any changes on this flash drive such a creation of some junk directories or something else.
StatFs stat = new StatFs(Environment.getExternalStorageDirectory().getPath());
long bytesAvailable = (long)stat.getBlockSize() *(long)stat.getBlockCount();
gives me a primary (phone, internal) memory size, NOT AN USB OTG FLASH DRIVE SIZE in PORTABLE MODE.
Would you be so kind to explain more precisely or give me a link to a source code with answers on next questions -
if I write file manager application and would like to give my users an access to EXTERNAL USB OTG FLASH DRIVE in a PORTABLE MODE under Android 6.0:
1. Is it possible with API 23? I didn't see file manager apps on Google Play that give such an access. The only way is to use USB host API (ES Explorer). Other way is to use your VERY RUDIMENTARY file manager shipping with Android 6.0 or root the device.
2. Is there API call to give me available memory on EXTERNAL USB OTG FLASH DRIVE in a PORTABLE MODE?
Let me emphasize that:
1. I WOULD NOT LIKE TO ADOPT external USB OTG flash drive as a primary memory - I already have such memory inside of my phone.
2. I WOULD NOT LIKE TO EXTEND existing primary (phone, internal) memory by means of USB OTG flash drive.
3. I WOULD NOT LIKE TO ALLOW Android make any changes on this flash drive such a creation of some junk directories or something else.
am...@google.com <am...@google.com> #9
Android is built on Linux, and Linux can have multiple filesystems mounted, and an app may not have access to all of those filesystems. For example, a partition may belong to the radio.
You can use Context.getExternalFilesDirs() to see all of the File[] locations where your app can write data, and then you can add up the free/total space on each of them.
You can use Context.getExternalFilesDirs() to see all of the File[] locations where your app can write data, and then you can add up the free/total space on each of them.
lb...@gmail.com <lb...@gmail.com> #10
[Comment deleted]
lb...@gmail.com <lb...@gmail.com> #11
[Comment deleted]
lb...@gmail.com <lb...@gmail.com> #12
[Comment deleted]
lb...@gmail.com <lb...@gmail.com> #13
@8 Someone on StackOverflow said my code (that's very similar to yours) doesn't work for Android API23 for the case of USBOTG :
http://stackoverflow.com/a/30401010/878126
Are you sure it works ok ?
Try to connect Nexus 5 with Android 6.0.1 and use getAvailableBytes. The docs don't say it's deprecated, so it should work fine even there :
http://developer.android.com/intl/ru/reference/android/os/StatFs.html
Maybe you should update the docs there, and also warn about file.getUsableSpace when using it ?
Since I don't have Android API 23 and even USBOTG, I can't check it out.
About the Linux remark, this doesn't matter: On all Linux variations for the PC, when you access a file it's the same. No matter which programming language or even the console. You never use a special API to read and write files just because you connect a different storage-peripheral to the PC. This is true even on Java on Linux.
So, being as on Linux, I would really love that it will be consistent and easy to use, without the hassle to differentiate what is connected to the smartphone.
In the current situation, not only we have a weird API for "special" external storage, but even basic things don't work well.
I mean, even moving files using the non-File API is bad. Instead of moving, we need to copy and then delete the file.
Are you sure it works ok ?
Try to connect Nexus 5 with Android 6.0.1 and use getAvailableBytes. The docs don't say it's deprecated, so it should work fine even there :
Maybe you should update the docs there, and also warn about file.getUsableSpace when using it ?
Since I don't have Android API 23 and even USBOTG, I can't check it out.
About the Linux remark, this doesn't matter: On all Linux variations for the PC, when you access a file it's the same. No matter which programming language or even the console. You never use a special API to read and write files just because you connect a different storage-peripheral to the PC. This is true even on Java on Linux.
So, being as on Linux, I would really love that it will be consistent and easy to use, without the hassle to differentiate what is connected to the smartphone.
In the current situation, not only we have a weird API for "special" external storage, but even basic things don't work well.
I mean, even moving files using the non-File API is bad. Instead of moving, we need to copy and then delete the file.
is...@gmail.com <is...@gmail.com> #14
@12 "Someone" - it was me.
lb...@gmail.com <lb...@gmail.com> #15
@13 oh sorry. Anyway, I still think the best API is the File API, and that it shouldn't get an extra, weird API just because it's a different storage type.
This should be the responsibility of the OS and VM to handle the differences of various types of storage. Not of the app developer.
This should be the responsibility of the OS and VM to handle the differences of various types of storage. Not of the app developer.
is...@gmail.com <is...@gmail.com> #16
@8 Does Android guarantees that certified device will give me ALL File[] locations where my app can write data by means of Context.getExternalFilesDirs() or it depends on device manufacturer? If it is so, starting from which API this is true?
is...@gmail.com <is...@gmail.com> #17
@14 I completely agree with you.
is...@gmail.com <is...@gmail.com> #18
@8 I have checked your statement on Micromax AQ5001 with Android 5.0. I have
1. internal memory,
2. external SD-card inserted in the slot,
3. USB OTG flash drive connected to USB
on it. The only path I have got from
File[] files = getExternalFilesDirs(null);
is
/storage/sdcard0/Android/data/com.example/files
and it is a path to internal memory (1). Please, give me a code example to get two other paths.
1. internal memory,
2. external SD-card inserted in the slot,
3. USB OTG flash drive connected to USB
on it. The only path I have got from
File[] files = getExternalFilesDirs(null);
is
/storage/sdcard0/Android/data/com.example/files
and it is a path to internal memory (1). Please, give me a code example to get two other paths.
lb...@gmail.com <lb...@gmail.com> #19
@15 Try the compat function :
http://developer.android.com/intl/ru/reference/android/support/v4/content/ContextCompat.html#getExternalFilesDirs(android.content.Context , java.lang.String)
It says in the docs you do get full access there, and starting from API 19 (kitkat) you don't even need the external storage permission for this.
It says in the docs you do get full access there, and starting from API 19 (kitkat) you don't even need the external storage permission for this.
is...@gmail.com <is...@gmail.com> #20
@12 & @18 I have got the same result for
File[] files = ContextCompat.getExternalFilesDirs(BaseActivity.this, null);
It gives me path to internal memory only...
File[] files = ContextCompat.getExternalFilesDirs(BaseActivity.this, null);
It gives me path to internal memory only...
lb...@gmail.com <lb...@gmail.com> #21
@19 and you can go to the paths of those somehow?
I wonder if it's possible using a workaround then.
I wonder if it's possible using a workaround then.
is...@gmail.com <is...@gmail.com> #22
[Comment deleted]
is...@gmail.com <is...@gmail.com> #23
Yes I can. But I am using reflection to read fields of nonpublic StorageVolume class for it. We are discussed it here http://stackoverflow.com/a/34703295/753575
is...@gmail.com <is...@gmail.com> #24
Unfortunately this workaround does not work starting from API 23.
lb...@gmail.com <lb...@gmail.com> #25
@23 well if you create a new post here about this, let me know and I will star it.
is...@gmail.com <is...@gmail.com> #26
@8 So, are you able to give me a code example to get info about USB OTG flash drive capacity on API 23?
am...@google.com <am...@google.com> #27
Please go through the below links
http://developer.android.com/reference/android/support/v4/provider/DocumentFile.html
http://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE
https://android.googlesource.com/platform/development/+/master/samples/ApiDemos/src/com/example/android/apis/content/DocumentsSample.java
lb...@gmail.com <lb...@gmail.com> #28
@26 DocumentFile is a very bad API compared to File API and can't be a good solution. I've created a whole post about it here:
https://code.google.com/p/android/issues/detail?id=201943
lb...@gmail.com <lb...@gmail.com> #29
[Comment deleted]
is...@gmail.com <is...@gmail.com> #30
@27 I have starred your issue!
@26 I will try to find an answer in provided example and write a result here.
@26 I will try to find an answer in provided example and write a result here.
is...@gmail.com <is...@gmail.com> #31
[Comment deleted]
is...@gmail.com <is...@gmail.com> #32
@26
First of all, in links you have provided is nothing about getting free (usable) space on USB OTG. API call to get this parameter IS ABSENT FOR DOCUMENT FILE API! It is present for java.io.File - File#.getFreeSpace() and File#.getUsableSpace() and it is absent for Document File. If you see it or know how to get this parameter - PLEASE, GIVE ME A CODE SAMPLE!!!
In the second place, I am developing a file manager app. I need to show an USB OTG free space for user BEFORE he will write something to flash drive because if flash drive is already full, user should see it BEFORE a write attempt! But your Document API does not give me such opportunity FOR ANDROID 6.0 because I can't read USB OTG by means of java.io.File, that was possible up to Android 5.1.
In Android 6.0 the only way for user to know is there free space on flash drive is to make write attempt and get error message if space is insufficient. IT INDICATES AN INCOMPLETENESS OF YOUR DOCUMENT API !!! Let me remind - EVEN CLOUD SERVICES (including Google Drive!) have API call getQuota() or something similar to estimate a capacity for copying files to it.
1. WHY DID YOU DECIDE TO REMOVE getUsableSpace() call (and others) from Document File API !?!?
2. Is there a way for user to know is space enough for copy some files or not BEFORE AN ATTEMPT TO WRITE!?!?
3. How do you imagine the process of copy files to flash drive by means of some third party file manager? Should user be forced to write something on flash drive in order to know his flash drive capacity? Should he see the capacity from your VERY RUDIMENTARY file manager by his own eyes and should he check does he able to write something on flash drive by means of a calculator!?
First of all, in links you have provided is nothing about getting free (usable) space on USB OTG. API call to get this parameter IS ABSENT FOR DOCUMENT FILE API! It is present for java.io.File - File#.getFreeSpace() and File#.getUsableSpace() and it is absent for Document File. If you see it or know how to get this parameter - PLEASE, GIVE ME A CODE SAMPLE!!!
In the second place, I am developing a file manager app. I need to show an USB OTG free space for user BEFORE he will write something to flash drive because if flash drive is already full, user should see it BEFORE a write attempt! But your Document API does not give me such opportunity FOR ANDROID 6.0 because I can't read USB OTG by means of java.io.File, that was possible up to Android 5.1.
In Android 6.0 the only way for user to know is there free space on flash drive is to make write attempt and get error message if space is insufficient. IT INDICATES AN INCOMPLETENESS OF YOUR DOCUMENT API !!! Let me remind - EVEN CLOUD SERVICES (including Google Drive!) have API call getQuota() or something similar to estimate a capacity for copying files to it.
1. WHY DID YOU DECIDE TO REMOVE getUsableSpace() call (and others) from Document File API !?!?
2. Is there a way for user to know is space enough for copy some files or not BEFORE AN ATTEMPT TO WRITE!?!?
3. How do you imagine the process of copy files to flash drive by means of some third party file manager? Should user be forced to write something on flash drive in order to know his flash drive capacity? Should he see the capacity from your VERY RUDIMENTARY file manager by his own eyes and should he check does he able to write something on flash drive by means of a calculator!?
sa...@gmail.com <sa...@gmail.com> #33
I all, after reading complete conversation above, i have no hope that i can find out the solution. However after spending lots of hours, i find out the way to find out the path of external sdcard. Not sure for USD OTG, can anybody have it, can you please test this code and let me know weather it is working or not so that this can helps to other people also. For my application, I just need to know the external removable sdcard path, and this code is working fine in my devices.
/**
* This method returns the list of removable storage and sdcard paths.
* I have no USB OTG so can not test it. Is anybody can test it, please let me know
* if working or not. Assume 0th index will be removable sdcard path if size is
* greater than 0.
* @return the list of removable storage paths.
*/
public static HashSet<String> getExternalPaths()
{
final HashSet<String> out = new HashSet<String>();
String reg = "(?i).*vold.*(vfat|ntfs|exfat|fat32|ext3|ext4).*rw.*";
String s = "";
try
{
final Process process = new ProcessBuilder().command("mount").redirectErrorStream(true).start();
process.waitFor();
final InputStream is = process.getInputStream();
final byte[] buffer = new byte[1024];
while (is.read(buffer) != -1)
{
s = s + new String(buffer);
}
is.close();
}
catch (final Exception e)
{
e.printStackTrace();
}
// parse output
final String[] lines = s.split("\n");
for (String line : lines)
{
if (!line.toLowerCase(Locale.US).contains("asec"))
{
if (line.matches(reg))
{
String[] parts = line.split(" ");
for (String part : parts)
{
if (part.startsWith("/"))
{
if (!part.toLowerCase(Locale.US).contains("vold"))
{
out.add(part.replace("/media_rw","").replace("mnt", "storage"));
}
}
}
}
}
}
//Phone's external storage path (Not removal SDCard path)
String phoneExternalPath = Environment.getExternalStorageDirectory().getPath();
//Remove it if already exist to filter all the paths of external removable storage devices
//like removable sdcard, USB OTG etc..
//When I tested it in ICE Tab(4.4.2), Swipe Tab(4.0.1) with removable sdcard, this method includes
//phone's external storage path, but when i test it in Moto X Play (6.0) with removable sdcard,
//this method does not include phone's external storage path. So I am going to remvoe the phone's
//external storage path to make behavior consistent in all the phone. Ans we already know and it easy
// to find out the phone's external storage path.
out.remove(phoneExternalPath);
return out;
}
/**
* This method returns the list of removable storage and sdcard paths.
* I have no USB OTG so can not test it. Is anybody can test it, please let me know
* if working or not. Assume 0th index will be removable sdcard path if size is
* greater than 0.
* @return the list of removable storage paths.
*/
public static HashSet<String> getExternalPaths()
{
final HashSet<String> out = new HashSet<String>();
String reg = "(?i).*vold.*(vfat|ntfs|exfat|fat32|ext3|ext4).*rw.*";
String s = "";
try
{
final Process process = new ProcessBuilder().command("mount").redirectErrorStream(true).start();
process.waitFor();
final InputStream is = process.getInputStream();
final byte[] buffer = new byte[1024];
while (is.read(buffer) != -1)
{
s = s + new String(buffer);
}
is.close();
}
catch (final Exception e)
{
e.printStackTrace();
}
// parse output
final String[] lines = s.split("\n");
for (String line : lines)
{
if (!line.toLowerCase(Locale.US).contains("asec"))
{
if (line.matches(reg))
{
String[] parts = line.split(" ");
for (String part : parts)
{
if (part.startsWith("/"))
{
if (!part.toLowerCase(Locale.US).contains("vold"))
{
out.add(part.replace("/media_rw","").replace("mnt", "storage"));
}
}
}
}
}
}
//Phone's external storage path (Not removal SDCard path)
String phoneExternalPath = Environment.getExternalStorageDirectory().getPath();
//Remove it if already exist to filter all the paths of external removable storage devices
//like removable sdcard, USB OTG etc..
//When I tested it in ICE Tab(4.4.2), Swipe Tab(4.0.1) with removable sdcard, this method includes
//phone's external storage path, but when i test it in Moto X Play (6.0) with removable sdcard,
//this method does not include phone's external storage path. So I am going to remvoe the phone's
//external storage path to make behavior consistent in all the phone. Ans we already know and it easy
// to find out the phone's external storage path.
out.remove(phoneExternalPath);
return out;
}
Description
Try to get free space on USB OTG flash drive on devices with API 23 (on Nexus 5 - 6.0.1) by means of any existing way:
StatFs(file.getPath()).getAvailableBytes()
or
file.getUsableSpace()
- What happened:
You will see 972546048 bytes regardless of real storage size.
- What you think the correct behavior should be:
It would be nice to get real space available for writing.
Are you going to give us a reasonable way of working with removable media!? You do nothing in this direction last year. More over, your new API 23 makes things worst - I can't READ (not WRITE!) directory (listFIles()) on USB OTG flash drive without DocumentFIle API!! It was possible before (APIs 19, 20, 21, 22)! Why did you close this opportunity!? Which security reasons may justify it!?