> I think I touched on this in the thread starter.

> i.e., keep any number of per-device configurations within the same
> sdcard for the possibility of sharing to other devices. If the per-
> device configuration is encrypted, then upon sdcard insertion, only
> those apps permitted by that device are runnable. And we can either
> key-check those apps on insertion, OR run a simple SHA hash of the
> file. If the hash doesn't match what is stored in the per-device
> configuration, request authorization refresh. If the per-device
> configuration doesn't exist, create it and go through the full
> authorization requests. The user can put a checkmark beside each app
> they want to authorize.

> i.e., the sdcard has a "master" packages.xml, and for each device, it
> has a "deviceid-packages.xml" which is a subset of the master
> packages.xml for that card.

> Regarding users not understanding why some apps can't be shared
> between devices... I think that it is important that they be warned of
> this. You can give them a LIST of *ALL* of the apps that are installed
> on the card, and do something along the lines of greying out the
> "protected" apps. If a user tries to authorize a protected app, give
> them a warning that says "This app is not authorized. The app
> developer requires that this app be restricted to the device it was
> initially installed on". That should make it pretty clear. And since
> the apk is encrypted using the same key as the deviceid-packages.xml
> file for the device it was initially installed on, it will be
> gibberish to any other device, so even if they hacked the
> authorization dialog, it would still be impossible to run it.

> On Oct 23, 8:28 am, Jean-Baptiste Queru <j...@android.com> wrote:
>> Well, as soon as we allow something like that, we can't allow
>> forward-locked apps on the SD card, and those are likely to be the
>> largest ones, i.e. the ones that'd benefit most from being installed
>> there. Maybe that could be worked around by keeping the "protected"
>> parts of the app on internal storage, and putting the rest on the SD
>> card. I'm not sure that users would understand why only some of their
>> apps can be shared between devices.

>> This opens a lot of other cans of worms: e.g. this'll create
>> situations where the same app is installed on the internal storage and
>> on the SD card. This doesn't directly allow to guarantee overall
>> uniqueness of UIDs on a given device. This creates some nasty issues
>> of compatibility if developers start to fine-tune individual versions
>> of their app for individual devices and an SD card is shared between
>> non-identical devices. This would also require to re-validate all the
>> permissions of all the SD-card apps whenever that SD-card is mounted
>> on a device (including at each boot). In general, this would create a
>> truckload of security issues, since no device can't trust the content
>> of the SD card.

>> Like I said, this is something that we should really really really not
>> try to do in a first version - it'd doom the feature to being so hard
>> to implement and to have so many subtle issues that I guarantee it'd
>> delay it much further. Enough users have been vocal enough about this
>> that I strongly feel that we should aim for something simple that's
>> more likely to be feasible (because "simple" is already going to be
>> hard enough).

>> JBQ

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

>> > I've never been a fan of assuming how a user uses their device and not
>> > including functionality on that basis.

>> > Personally I can see people temporarily swapping SD cards so they can
>> > try out other peoples apps on their phone, so I can see the need to
>> > handle it properly.

>> > 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 23 Oct 2009, at 01:05, Eric F wrote:

>> >>  you buy a Mac Mini you get to
>> >> choose how big of a disk drive you want. I can't really imagine a
>> >> situation where I'd want to have different apps on different SD cards
>> >> and switch between them. Sure in a perfect world it should still work.
>> >> But if it degrades from the system being able to work smoothly in
>> >> other areas, I don't think this is a bad thing to give up. Especially
>> >> if it's possible to A) take the file that represents the encrypted
>> >> file system and copy it to the computer, and then copy it to a second
>> >> card. So let's say we bought an 8GB card thinking that would be
>> >> sufficient. Later we realize we wanted a 16 GB card, we move the file
>> >> between cards using a computer and then use Android to resize the
>> >> filesystem to our new choice, preserving our installed apps.

>> >> I can't see normal users "swapping cards", so that leaves us with
>> >> power users. I think most power users are hungry for the largest/
>> >> fastest SD card they can get their hands on. Which means 16 (soon 32)
>> >> GB cards, how many of those is a user going to need? Many phones are

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