Thanks. Very interesting indeed. I see that there is a long history with
this.
Anyway I see a direct contradiction is Dianne's responses:
*The current CDD requires that the API return the directory of the primary
"external" storage, that is the one you can count on always being there,
that is
On 04/18/2012 09:35 PM, Nadeem Hasan wrote:
On Wednesday, April 18, 2012 12:55:00 PM UTC-4, digi owl wrote:
Seems to me like what has happened is that manufacturers have
cooped a feature that was supposed to be for removable storage to
support larger non-removable capacity (a simple
On Wednesday, April 18, 2012 12:55:00 PM UTC-4, digi owl wrote:
>
> Seems to me like what has happened is that manufacturers have cooped a
> feature that was supposed to be for removable storage to support larger
> non-removable capacity (a simple way to upsell). In the process, we have
> found
On Tuesday, April 17, 2012 4:19:19 PM UTC-7, Dianne Hackborn wrote:
>
> On Tue, Apr 17, 2012 at 3:09 PM, Nathan wrote:
>
>> On Monday, April 16, 2012 7:07:33 PM UTC-7, Dianne Hackborn wrote:
>>
>>> On Sun, Apr 15, 2012 at 8:56 AM, digi owl wrote:
>>>
looking at the 3.2 platform API changes,
On 04/18/2012 08:41 PM, Nadeem Hasan wrote:
Environment.getExternalStorageDirectory() returns the non-removable
external memory location.
On tablets that have both "internal external" and "external external"
storage it does.
On tablets and devices that only have "internal external" storage
Seems to me like what has happened is that manufacturers have cooped a
feature that was supposed to be for removable storage to support larger
non-removable capacity (a simple way to upsell). In the process, we have
found ourselves with partitioned internal storage (to allow USB file
transfer) and
On Wednesday, April 18, 2012 8:46:33 AM UTC-7, Nadeem Hasan wrote:
>
> That hasn't stopped many devices from making the removable storage their
>> primary one. But if this is by design, I'd like to link to the design
>> philosophy document. Maybe I can send that to the users. I can't find
>> a
Environment.getExternalStorageDirectory() returns the non-removable
external memory location. But I see what you mean, on devices with only
removable external memory, it could return that location. However, the
point remains that the framework only considers one external storage as
general purp
On 04/18/2012 07:54 PM, Nadeem Hasan wrote:
On Tuesday, April 17, 2012 7:44:34 PM UTC-4, Kostya Vasilyev wrote:
It also hasn't prevented from existing a few hundred million
devices with removable, writable, user controllable and
understandable, officially supported "external" micro
On Tuesday, April 17, 2012 7:44:34 PM UTC-4, Kostya Vasilyev wrote:
>
> It also hasn't prevented from existing a few hundred million devices with
> removable, writable, user controllable and understandable, officially
> supported "external" microsd memory cards.
>
> Yes, I'm talking about phone
>
> That hasn't stopped many devices from making the removable storage their
> primary one. But if this is by design, I'd like to link to the design
> philosophy document. Maybe I can send that to the users. I can't find
> anything official, though. If the other devices are going to be unwritea
Hi,
I faced the same problem of finding external storage devices connected
to the user. My workaround was, I noticed that the LOST.DIR gets created
for all storage devices that are connected to the android device.
So I am searching for the locations for LOST.DIR in the filesystem
sta
18.04.2012 3:17 пользователь "Nathan" написал:
>
>
> On Tuesday, April 17, 2012 7:39:32 AM UTC-7, Nadeem Hasan wrote:
>>
>>
>> The removable external storage by design is not made available to
applications for general purpose storage simply because it's not expected
to be present all the time and
On Tue, Apr 17, 2012 at 3:09 PM, Nathan wrote:
> On Monday, April 16, 2012 7:07:33 PM UTC-7, Dianne Hackborn wrote:
>
>> On Sun, Apr 15, 2012 at 8:56 AM, digi owl wrote:
>>
>>> looking at the 3.2 platform API changes, it appears that Google wants
>>> developers to access SD cards via either Meid
On Tue, Apr 17, 2012 at 2:55 PM, Nathan wrote:
> Is there any reason that the platform will never support something like
> GetStorageDirectories() (plural)?
>
Well, nobody has said that, so I don't see how I could give a reason for it.
--
Dianne Hackborn
Android framework engineer
hack...@andr
On Tuesday, April 17, 2012 7:39:32 AM UTC-7, Nadeem Hasan wrote:
>
> The removable external storage by design is not made available to
> applications for general purpose storage simply because it's not expected
> to be present all the time and is explicitly intended for read-only media
> files
On Monday, April 16, 2012 7:07:33 PM UTC-7, Dianne Hackborn wrote:
>
> On Sun, Apr 15, 2012 at 8:56 AM, digi owl wrote:
>
>> looking at the 3.2 platform API changes, it appears that Google wants
>> developers to access SD cards via either MeidaStore or the MTP API:
>> https://developer.android.
On Monday, April 16, 2012 7:05:58 PM UTC-7, Dianne Hackborn wrote:
>
>
> The current platform defines an single external storage location, which
> these days can be either a physical SD card, a physical partition on
> internal storage, or shared with internal storage, as reported by the
> vari
I think this behavior does make some sense.
The non-removable external storage is what the platform expects the apps to
use to read/write arbitrary files. So this location is made visible to the
apps via the Environment API. The removable external storage is expected to
be used to swap in/out m
On Sun, Apr 15, 2012 at 8:56 AM, digi owl wrote:
> looking at the 3.2 platform API changes, it appears that Google wants
> developers to access SD cards via either MeidaStore or the MTP API:
> https://developer.android.com/sdk/android-3.2.html
>
> https://developer.android.com/reference/android/m
On Fri, Apr 13, 2012 at 11:00 PM, Zsolt Vasvari wrote:
> It appears that no one on this forum has more insight into number 2. Darn.
>>
> If Dianne hasn't chimed in, there is probably not much hope that you will
> get an answer.
>
The current platform defines an single external storage location,
looking at the 3.2 platform API changes, it appears that Google wants
developers to access SD cards via either MeidaStore or the MTP API:
https://developer.android.com/sdk/android-3.2.html
https://developer.android.com/reference/android/mtp/package-summary.html
https://developer.android.com/refe
>
> It appears that no one on this forum has more insight into number 2. Darn.
>
If Dianne hasn't chimed in, there is probably not much hope that you will
get an answer.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this gr
On Thursday, April 12, 2012 10:22:57 PM UTC-7, Zsolt Vasvari wrote:
>
> I think you just need to stop calling the SD Card and call it "External
> storage" or something.
It's really irrelevant what *I* call it. I can't control what the users
call it, or even what the manufacturers call it.
I think you just need to stop calling the SD Card and call it "External
storage" or something. If it's not on the SD card, why do you care?
Presumably, it's accessible if the device is connected to a PC via the
USB, correct?
If you must write to a removable storage, I don't think you can guar
On Thursday, April 12, 2012 6:27:35 PM UTC-7, Zsolt Vasvari wrote:
>
> > According to some reports, ICS, and not just the manufacturers, is
>> locking out all non privileged apps from writing to removable storage.
>>
>
> That's absolutely not true -- my app, on a Galaxy Nexus, can write to the
>
> > According to some reports, ICS, and not just the manufacturers, is
> locking out all non privileged apps from writing to removable storage.
>
That's absolutely not true -- my app, on a Galaxy Nexus, can write to the
folder pointed to by:
Environment.getExternalStorageDirectory().getAbs
On Thursday, April 5, 2012 10:10:50 PM UTC-7, Nikolay Elenkov wrote:
>
> I guess that came out wrong, sorry. My point was, that if you are
> providing a backup/export, etc. feature, saving data to 'the cloud'
> is generally easier than trying to deal with 'external storage'
> in its many shapes an
On Thu, Apr 5, 2012 at 7:03 PM, Kostya Vasilyev wrote:
> It's not me or Nathan.
>
> It's the users of our apps who wish to use the memory card slot on these
> devices.
Right. If they have it, they want to use it. My point was, don't try
to support 'external storage' in your app (see other post)
On Fri, Apr 6, 2012 at 3:33 AM, Nathan wrote:
>
>
> On Apr 5, 2:20 am, Nikolay Elenkov wrote:
>>
>> In short, save yourself the trouble and don't bother :)
>>
>> Using Dropbox, or Google Drive(?), or whatever will
>> give you less headaches.
>
> I'm not sure how that helps developers, and I am n
On Thu, Apr 05, 2012 at 11:33:38AM -0700, Nathan wrote:
>
>
> On Apr 5, 2:20?am, Nikolay Elenkov wrote:
> >
> I'm not sure how that helps developers, and I am not sure I can not
> bother.
>
> My customers easily create 8Gig or more of files with my app, so they
> care about what volume the app
On Apr 5, 2:20 am, Nikolay Elenkov wrote:
>
> Nice indeed. To add more unsubstantiated rumours, it appear that there are
> actually environment variables that store the mount point(s) of secondary
> SD cards. Those have been seen in the wild:
>
> EXTERNAL_STORAGE_ALL
> EXTERNAL_STORAGE
> SECOND_
It's not me or Nathan.
It's the users of our apps who wish to use the memory card slot on these
devices.
And it's Google's imaginary view of the world where there can only one
external storage location per device.
That would be like Microsoft not implementing support for printing in
Window
2012/4/5 Kostya Vasilyev :
> Oh, I see.
>
> Rather than coming up with an API to enumerate and access multiple storage
> locations, the entire feature was made explicitly unsupported for
> third-party applications.
>
> Nice.
>
Nice indeed. To add more unsubstantiated rumours, it appear that there
Oh, I see.
Rather than coming up with an API to enumerate and access multiple storage
locations, the entire feature was made explicitly unsupported for
third-party applications.
Nice.
-- K
5 апреля 2012 г. 8:43 пользователь Nathan написал:
>
> Well, what do you know. WRITE_MEDIA_STORAGE is a b
Well, what do you know. WRITE_MEDIA_STORAGE is a bit like District 13
in
I can put this in my manifest.
This is because the permission is hidden in manifest.java.
/** Allows an application to write to internal media storage
@hide
*/
public static final String
WR
36 matches
Mail list logo
