> 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.
