> App1 is installed on the SD card. SD card gets ejected. App2 (which
> requests a shared UID with App1) is installed on internal storage. SD
> card is put back in. App2 notices that App1 is around, tries to access
> App1's files. If they don't have the same UID, kaboom.

> (extend the scenario a bit further, assume that you have that scenario
> covered with shared UIDs, insert SD card 2, install App3 on SD card 2
> that requests the same UID as App1. Now you need to have apps on SD
> cards 1 and 2 that need to share a UID).

> Seriously, really really don't try to use the same apps installed on 1
> SD card onto multiple devices. Really, don't. The associated can of
> worms is so huge that it would delay apps2sd by months or doom it
> forever.

> Even with many simplifying assumptions (1 device, 1 SD card, no
> hot-plug) this is a tricky enough problem.

> JBQ

> PS: don't forget the case where you install updates for system apps.
> Chances are, those really need to only ever go on internal storage
> (yet another simplifying assumption), at least so that both the
> original and the new variant share the same data directory.

> On Thu, Oct 22, 2009 at 1:30 PM, Al Sutton <a...@funkyandroid.com> wrote:

> > On the UIDs issue, can't a "drive id" be used as part of the UID
> > associated with an app?

> > For example, if we use 0 for internal, 1 for the first SD, etc. then
> > an app can get a UID of 0x1234 when its' installed, but would be run
> > with a UID of 0x001234 if its' run from internal storage, 0x011234 if
> > run from "drive" 1, 0x021234 if user from "drive" 2, etc.

> > That way any device an SD card is inserted into only needs to worry
> > about uniqueness of the UID within the device as opposed to uniqueness
> > across any system it's inserted into.

> > Al.
> > --

> > * Looking for Android Apps? - Tryhttp://andappstore.com/*

> > ======
> > Funky Android Limited is registered in England & Wales with the
> > company number  6741909.

> > The views expressed in this email are those of the author and not
> > necessarily those of Funky Android Limited, it's associates, or it's
> > subsidiaries.

> > On 22 Oct 2009, at 20:31, Jean-Baptiste Queru wrote:

> >> All right, here are a few hints of things which I think have been
> >> discussed in the past (though I don't remember whether that was in
> >> public or not).

> >> -application and its data stored on the same volume. Internal apps
> >> store data internally, sdcard apps store data on sdcard.

> >> -apps and their data as stored on SD are tied to the device that
> >> installed them, can't be read on a PC or on another device (i.e.
> >> crypto).

> >> -shared UIDs need to work, one way or another. That's the tricky
> >> design part IMHO when it comes to dealing with UIDs (or maybe this is
> >> where we need to make big simplifying decisions).

> >> The basic idea for the filesystem-level work is to create an e3fs
> >> image (or equivalent) in an encrypted disk image on the SD card. with
> >> the crypto key being stored on /data (so that access to it goes away
> >> after a factory reset).

> >> A significant implementation detail is that all processes that have
> >> file opened on the SD card either need to close them or be killed.
> >> Once apps get on the SD card, you end up in a situation where the
> >> system server will need to do that too; in addition to all the
> >> "legitimate" codepaths to deal with, we also think that there are
> >> cases there the system server leaks open file descriptors of apks.

> >> A further simplifying assumption might be to only allow one SD card
> >> with apps tracked by the system at any time.

> >> JBQ

> >> On Thu, Oct 22, 2009 at 11:43 AM, Eric F <ericfrie...@gmail.com>
> >> wrote:

> >>> A bold move lbcoder!

> >>> I think first we should get a confirmation from Google that the list
> >>> of requirements is both complete and correct. Otherwise any designed
> >>> solution might be for nothing. Also confirmation that they are not
> >>> working on this already in their private repo would be nice
> >>> (although,
> >>> we have to be realistic here, this is AOSP we are talking about).

> >>> I think there should be some discussion as to #5 on the requirements.
> >>> Apps installed on an SD card in an Android 2.5 device and then
> >>> plugged
> >>> into an Android 2.1 device should not necessarily function correctly,
> >>> or display at all. What about an app that is tightly coupled with the
> >>> contacts of one phone that wouldn't make sense to run on a second
> >>> phone with the same app data, and would make more sense to start
> >>> separate app data per phone.

> >>> Also, I think added to the requirements should be determined if the
> >>> capability to support multiple cards should be:
> >>> 1) Designed to be explicitly never supported
> >>> 2) Designed to one day work with more improvements in a way that is
> >>> compatible with the design for supporting one card
> >>> 3) Designed to be supported

> >>> A good design takes into account where Android and Android devices
> >>> might be in 2 years, not just what's in the stores today.

> >>> I agree that some kind of loopback filesystem on the fat32 card is in
> >>> order. I had a post a while back describing how I thought the UI and
> >>> the user should have to deal with creating this section of the memory
> >>> card, changing its size, deleting, installing apps etc. Remember
> >>> people can also eject the card and insert it into a card reader on
> >>> their computer, so I am not sure how well just reporting fat32 over
> >>> usb mass storage is sufficient to protect users from formatting their
> >>> cards by accident.

> >>> -E

> >>> On Oct 22, 10:47 am, lbcoder <lbco...@gmail.com> wrote:
> >>>> In looking through the various threads, I see that there are some
> >>>> questions on how to handle application storage on SDCARD safely and
> >>>> securely.

> >>>> I would like to propose a mechanism for handling this in a manner
> >>>> that
> >>>> is fair, safe, and secure,  however there are bound to be questions
> >>>> and or unforseen issues.

> >>>> First, in simplest form, the minimum requirements:

> >>>> 1) Application and all application data to be stored externally on
> >>>> sdcard.
> >>>> 2) SDCARD must be able to be removed and replaced at will, including
> >>>> possibility of being replaced with a different sdcard.
> >>>> 3) Contingency must be made for possibility of installing
> >>>> application
> >>>> both internally as well as on sdcard.
> >>>> 4) Protected applications installed to sdcard must remain secure.
> >>>> 5) Insertion of sdcard into another device should allow
> >>>> application to
> >>>> function in other device except in the case where the application is
> >>>> "protected".
> >>>> 6) SDCARD must be protected from MS-hostility, i.e. mounting
> >>>> sdcard to
> >>>> a computer (via usb to phone) must not prompt non-expert users that
> >>>> they should format it.

> >>>> Scheme:
> >>>> i) Need to segregate a group of user id's for use as sdcard-UIDs
> >>>> (i.e.
> >>>> 20000-29999).
> >>>> ii) Need app, app-private, data, and dalvik-cache directory on
> >>>> sdcard.
> >>>> iii) Need a packages.xml on sdcard.
> >>>> iv) Upon unmount need to (in order):
> >>>> a) kill all running sdcard processes.
> >>>> b) refresh package list (modify the package manager to update
> >>>> package
> >>>> status by rereading /data/system/packages.xml and sdcard's
> >>>> packages.xml).
> >>>> c) actually unmount the partition.
> >>>> v) Need to modify installer to prompt for where to install to (if
> >>>> sdcard is available).

> >>>> Problems:
> >>>> 1) When sdcard is yanked-without-unmount by non-expert user, running
> >>>> application may crash.
> >>>> 2) Multiple current installations of the same application -- how to
> >>>> select between?
> >>>> 3) Copying of protected applications is trivial.
> >>>> 4) How to control per-process permissions on a card from an unknown
> >>>> source?
> >>>> 5) How to safely allow sdcard to be mounted to a separate computer
> >>>> without non-expert user reformatting.
> >>>> 6) SDCARD applications added to the home screen.

> >>>> Solutions:
> >>>> 1) Android already kills off background processes to free up memory.
> >>>> This can be extended to kill off ALL background processes running on
> >>>> SDCARD. The problem here is in the event that a running/foreground
> >>>> app
> >>>> is forcibly removed. SDCARD removal (forcefully) should kill all
> >>>> processes that would safely be killed off for memory cleanup, and
> >>>> forcefully (kill -9) all processes that can't be safely killed.
> >>>> Should
> >>>> also show the user an error message that says something like "You
> >>>> removed the sdcard without unmounting, the following sdcard
> >>>> applications were running and had to be killed. All unsaved data has
> >>>> been lost." There is no need to get fancy and save the application
> >>>> states.
> >>>> 1b) In the event that the user chose to safely unmount the sdcard,
> >>>> IF
> >>>> there are running applications, show a message like "The following
> >>>> applications on the SDCARD are currently running: ... If you
> >>>> continue,
> >>>> these applications will be killed. Would you like to proceed?"
> >>>> 2) In the event of multiple of the same applications installed
> >>>> (internal and sdcard), choose to run the one on INTERNAL (do not add
> >>>> the external one to the application manager). I.e., when scanning
> >>>> the
> >>>> applications on the sdcard, if (application exists on internal
> >>>> memory)
> >>>> do not add to application manager. The assumption being that if you
> >>>> have it installed internally, then the REASON is that you want it to
> >>>> be available when you remove or change sdcard.
> >>>> 3) Two possible solutions to this;
> >>>> a) (I don't like this one) -- don't allow protected apps to be
> >>>> installed to sdcard at all. This would be perceived as hostile to

> ...

> read more »