>  From what I've seen most apps don't use a shared UID, so as step one
> down the path to SD-apps goodness could we not allow non-share UID
> apps to run from SD and limited shared UID apps to internal storage.

> I know it's not ideal, but its' one step up from where we are now
> where even if an app doesn't need a shared UID its' still forced to
> only be runnable from internal storage.

> Al.
> --

> * Looking for Android Apps? - Try http://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 21:44, Jean-Baptiste Queru wrote:

>> Where things become messy is really when you start to deal with
>> shared UIDs.

>> 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? - Try http://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
>>>>>> software vendors wishing their apps to be copy protected.
>>>>>> b) encrypt protected app's apk and dalvik cache using a key stored
>>>>>> internally. If the card is inserted into another device, it will
>>>>>> not
>>>>>> have the necessary decryption key and therefore can either not
>>>>>> show
>>>>>> the application at all, or it can show the application as "not
>>>>>> licensed for this device".
>>>>>> (*) note: it is not necessary to secure non-protected apps, free
>>>>>> or
>>>>>> priced, since it is by the seller choice that there is no copy
>>>>>> protection on the app.
>>>>>> 4) THIS IS A BIG ONE... Insertion and removal of other sdcards,
>>>>>> particularly given the possibility that the sdcard belongs to
>>>>>> someone
>>>>>> else and/or stands the possibility that it has been tampered
>>>>>> with. I
>>>>>> suggest that there be a group of secure databases on the sdcard,
>>>>>> one
>>>>>> for each device that the card has been inserted into, this
>>>>>> database is
>>>>>> encrypted by the devices encryption key (the same one as 3(b)). If
>>>>>> you
>>>>>> insert an sdcard which has not been used in your device before, it
>>>>>> will create a new encrypted database and ask which applications to
>>>>>> allow (showing, of course, their permission requests). The
>>>>>> resulting
>>>>>> database would hold the kind of data corresponding to /data/
>>>>>> system/
>>>>>> packages.xml. There would, of course, also be an option to delete
>>>>>> the
>>>>>> databases for "other" devices (which would prompt the same
>>>>>> rebuild).
>>>>>> There must be, of course, a "master" databases on the sdcard
>>>>>> showing
>>>>>> ALL installed apps, upon insertion, this must be compared to the
>>>>>> per-
>>>>>> device database resulting in the user being prompted for any new
>>>>>> applications and for removing from the per-device database, any
>>>>>> obsolete entries.
>>>>>> 5) Since due to other-device compatibility, it must remain fat32,
>>>>>> there are two options I can think of;
>>>>>> a) loopback filesystem within the primary fat32 filesystem. This
>>>>>> would
>>>>>> fly under the radar of MS's hostility routines. Secondary
>>>>>> benefit is
>>>>>> that it would easily allow advanced users to 'mount -o loop' the
>>>>>> application filesystem.
>>>>>> b) modify the mass storage controller code to only show the fat32
>>>>>> filesystem. Makes it a little more akward for advanced users.
>>>>>> (*) there is another FEATURE that could be added, not exactly
>>>>>> relevant, but related... Change the mass storage driver to
>>>>>> present a
>>>>>> *virtual* filesystem, i.e., be able to leave the sdcard MOUNTED,
>>>>>> but
>>>>>> still grant access to it (i.e. how NFS is able to share a
>>>>>> filesystem
>>>>>> to (multiple) other machines without making it unavailable to the
>>>>>> host.
>>>>>> 6) Two options;
>>>>>> a) tag it as unavailable. If a different sdcard is inserted
>>>>>> containing
>>>>>> the same app, it would also activate that one. If the same app is
>>>>>> later added to internal, it would activate that, i.e., the intent
>>>>>> would be the same since it isn't related to the UID.
>>>>>> b) don't allow sdcard apps to be added to the home screen. This is
>>>>>> just slightly easier, but not by much. It is also less "cool".

>>>>>> I would like to hear about any holes in this scheme that anyone
>>>>>> can
>>>>>> think of.
>>>>>> And please, if you wish to contribute, be precise about any
>>>>>> problems
>>>>>> that you see with this, and if possible, a solution *within the
>>>>>> bounds* of the infrastructure I have presented. I would rather not
>>>>>> have this degenerate into a "yeah, its nice, but wouldn't it be
>>>>>> cool
>>>>>> if we did this instead". I would like comments that are
>>>>>> constructive
>>>>>> with respect to making these suggestions happen with absolutely as
>>>>>> little modification as is required.

>>>>>> If we are able to come up with a concrete logical scheme, then at
>>>>>> that
>>>>>> point I would like to begin working on this from an implementation
>>>>>> perspective, i.e., how to *actually* make it happen.

>>>> --
>>>> Jean-Baptiste M. "JBQ" Queru
>>>> Software Engineer, Android Open-Source Project, Google.

>>>> Questions sent directly to me that have no reason for being private
>>>> will likely get ignored or forwarded to a public forum with no
>>>> further
>>>> warning.

>> --
>> Jean-Baptiste M. "JBQ" Queru
>> Software Engineer, Android Open-Source Project, Google.

>> Questions sent directly to me that have no reason for being private
>> will likely get ignored or forwarded to a public forum with no further
>> warning.