Is it a typo is the CDD requirement really this backwards? You say:

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 the internal storage partition of such devices.

So the API named EXTERNAL storage is required to return the "INTERNAL
storage partition"!

Sounds pretty contradictory to me.

On Feb 28, 7:23 pm, Dianne Hackborn <[email protected]> wrote:
> 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 the internal storage partition of such devices.  The very first
> devices that introduced multiple storage areas caught us a bit by surprise,
> implemented this in a broken way (leaving the code to return the SD card
> storage which was actually shipped without a card on those devices), and the
> CDD has since been clarified about how the device needs to behave.
>
> On Mon, Feb 28, 2011 at 9:25 AM, Indicator Veritatis <[email protected]>wrote:
>
> > Dianne rightly observes: "The platform really needs to define a good
> > UX story around this before just
> > throwing APIs at developers. "
>
> > Which would be a lot easier to do if OEMs would insist on a good UX
> > story also before implementing bizarro features like two SD cards!
> > Unfortunately, their history of failing to do this extends to long
> > before the beginning of Android.
>
> > But I still see no answer to the question: do such devices, for having
> > such a non-standard configuration, fail CDD and therefore are not on
> > the Market? I am sure such info would still be useful for the OP.
>
> > On Feb 26, 4:32 pm, Dianne Hackborn <[email protected]> wrote:
> > > It returns the main partition, that you can count on being populated; for
> > a
> > > device with a built-in USB mass storage and an external SD card it will
> > > return the built-in one.
>
> > > Android does not yet define the behavior for dealing with multiple SD
> > cards.
> > >  Devices that use that configuration are outside of the core platform,
> > and
> > > should provide their own mechanism for them if they want -- such as a
> > shared
> > > library to find out about the secondary storage.
>
> > > The platform really needs to define a good UX story around this before
> > just
> > > throwing APIs at developers.
>
> > > On Sat, Feb 26, 2011 at 4:11 PM, Indicator Veritatis <[email protected]
> > >wrote:
>
> > > > What does this API do on a phone that has two SD cards? Does it just
> > > > pick only one of them? Or do all such devices fail CDD and so are not
> > > > on the Google Android Market?
>
> > > > On Feb 26, 3:41 pm, Dianne Hackborn <[email protected]> wrote:
> > > > > On Fri, Feb 25, 2011 at 8:31 PM, Dimitry Golubovsky <
> > > > [email protected]>wrote:
>
> > > > > > I am not worried about Market at all. I am worried about the
> > portable
> > > > > > way to tell my program where is the sdcard root directory is
> > mounted
> > > > > > because part of the usage scenario is user being able to upload
> > > > > > certain files to sdcard where my program must be able to find them.
>
> > > > > > To clarify, this is a port of Squeak (Smalltalk) [1], [2] to
> > Android
> > > > > > which I am trying to alter to fit my needs; in particular the
> > original
> > > > > > port loaded the image from assets, but I would like to be able to
> > load
> > > > > > it from sdcard where user may place it after customization using an
> > > > > > instance of Squeak on user's PC.
>
> > > > > The correct way to do this is
> > Environment.getExternalStorageDirectory().
>
> > > > > If you want to make your application work on an incompatible device
> > that
> > > > has
> > > > > this API broken, you will need to write code specifically for that
> > > > device.
> > > > >  There is no magical solution that makes your app work regardless of
> > what
> > > > > someone has done to Android.
>
> > > > > --
> > > > > Dianne Hackborn
> > > > > Android framework engineer
> > > > > [email protected]
>
> > > > > Note: please don't send private questions to me, as I don't have time
> > to
> > > > > provide private support, and so won't reply to such e-mails.  All
> > such
> > > > > questions should be posted on public forums, where I and others can
> > see
> > > > and
> > > > > answer them.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Android Developers" group.
> > > > To post to this group, send email to
> > [email protected]
> > > > To unsubscribe from this group, send email to
> > > > [email protected]
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/android-developers?hl=en
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer
> > > [email protected]
>
> > > Note: please don't send private questions to me, as I don't have time to
> > > provide private support, and so won't reply to such e-mails.  All such
> > > questions should be posted on public forums, where I and others can see
> > and
> > > answer them.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails.  All such
> questions should be posted on public forums, where I and others can see and
> answer them.

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to