Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Message from discussion More Applications on SDCARD
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
lbcoder  
View profile  
 More options Oct 26 2009, 12:41 pm
From: lbcoder <lbco...@gmail.com>
Date: Mon, 26 Oct 2009 09:41:58 -0700 (PDT)
Local: Mon, Oct 26 2009 12:41 pm
Subject: Re: More Applications on SDCARD
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.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.