Apps on SD, multiple SD cards: a simplification?
Jean-Baptiste Queru
this more than I did, but I didn't quite see any mention of this in
past discussions...
Thinking about the problems related to installing apps on the SD card,
one of the issues that always struck me as a trick one was to manage
the possibility that a user might install apps on multiple SD cards,
and swap those cards.
What if we don't try to resolve this problem? We could significantly
reduce the difficulty reduce the problem by only ever allowing apps on
a single SD card, i.e. by making the system track apps on no more than
one SD card at a time: if the system is already tracking one SD card
and another one is inserted, we could explicitly forget everything
about the first SD card if the user wants to install apps on the
second one. The package database could be purged of any record of any
apps on the first card, and forgetting the encryption key to the
filesystem on the first one guarantees that we won't ever access those
files by accident.
I think that this would still make "apps on SD" useful to our users
while reducing the amount of work that has to happen in a first phase.
We're not talking about a cupcake timeframe, of course, but this might
speed up the process to see apps on SD in a future release.
Thoughts?
--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.
Al Sutton
tracking apps on non-present SD cards is just crazy.
Imho the following should happen;
1) When Android detects a new SD card has been inserted it should
perform some actions which obtain a list of apps installed on the SD card.
2) When Android detects the SD card has been removed it should forget
about *everything* on that SD card (apps, media, data, etc.).
Trying to track apps across multiple-sd cards is nigh on impossible
because if an SD card gets used in two separate android devices then
what happens when one of them uninstalls one of the apps on the SD card?
Al.
--
======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.
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.
Disconnect
(So, for example, you could happily .. well, usually happily.. install an email app to sd and move it between multiple identical devices, carrying settings etc with you..)
The first insert takes a while because it has to run the install scripts, but it also means you can install most everything (non-system-modifying bits) to sd and move it from phone to phone or factory/upgrade/replace your phone at will.
I think its safe to say "g1 to other similar-specced android device" is unsupported right now though. But "g1 to g1" should be a core requirement.
Al Sutton
to apps on SD cards we could simply pop up a "please insert SD
containing app" type dialogue if a shortcut is used for a non-present
app (similar to what happens on a desktop OS if you have a shortcut to a
non-present removable drive).
If we talking about settings (e.g. permission grants, etc.), that could
be stored along with the crypto-signature of the app. This would allow
users to copy apps between SDs (e.g. when they buy a larger card) and
the device will treat the app on the new SD in the same way as it did on
the old SD. A settings manager could be provided which allows users to
delete the settings of any app which isn't used any more (similar to
most games consoles saved game data option).
As for system modifications, I'm against apps being allowed to modify
the system in any way that isn't localised to the apps environment
(mainly because you end up in bun-fights when two apps want a setting to
be different things).
Al.
Joe Onorato
-joe
Disconnect
And then the app database needs to basically say "ok my db is here, plus /sdcard/secure/appsdb/foo"
Al Sutton
based user choices in an app-hash to values map. Beyond that it should
be down to the app (with support from the platform) to decide what to
offer in the way of storage and how to offer it.
I'd suggest the default is to store the apps data with the app (i.e. on
whatever source it was loaded from; internal memory, SD card, NAS,
etc.), this could be extended to allow apps to be loaded from a network
source and put their data back to that source (think about an office
suite where the apks can be downloaded from a web server and the data
documents are pushed back to the server for storage).
I'd suggest we generalise this concept out and think about larger
storage options (e.g. an external hard disk). We have an opportunity to
build now a framework which will scale up beyond the G1 to netbooks and
ever larger processing devices so I think we need to think carefully
about a solution that works will in larger environments as well as one
that works for 'phones (anyone for Google powered by a network of
Android servers :)).
Al.
> <j...@google.com <mailto:j...@google.com> <mailto:j...@google.com
Al Sutton
without a card in, does wome work, and then inserts a card? Does all the
data get hidden by the overlay mount?
I think it would be better for the OS to look for an apps data in
${app_source}/blah then /blah, then /sdcard1/blah, etc., etc., etc.
Al.
Disconnect
Overlay lets it be expanded without spinning a new platform. (n800 right now can have sd1, sd2, usb-hdd 0-n and nfs mounts..)
Plus it makes it transparent to the app - you still open /data/data/com.my.app/ just like before. (So no sdk change.)
Eric F
SD card contains an encrypted file that has a name that is tied to
some unique number of the phone (perhaps after a one way hashing)
Perhaps also with the user readable name of their phone in it too. For
example a phone called "Rex" might have the file named:
AndroidApps-Rex-34edk5etr.bin
Or something like that. If filename length is a problem. Create a
directory called "Android Installed Apps" then put the file with just
the name of the phone and unique ID as the name.
The file is an ext2 file system that is encrypted. When a new SD card
is inserted the user gets to choose how much space to reserve on the
card for app installs (automatic growing and shrinking of the FS on
demand would be a significant performance killer and headache).
However the uesr is able to modify this file size at any later point.
During this resizing or creating, the SD card and any apps on it are
"UNAVAILABLE".
When an app goes from available to unavailable, it is instantly killed
if running, and querying its availability will return unavailable.
Perhaps an activity pops up telling the user "The following
applications which reside on the SD card had to be terminated." So
that there is a bit of education and user surprise is minimized.
Rewrite the default home screen so that on sd card insert / eject, it
re-queries all the apps for which app shortcuts are created on the
homescreen to determine which are available / unavailable. It then
greys out any app that is unavailable and draws a small missing SD
card logo on the corner of the image.
Not so complex. Simplifying to only supporting a single card etc isn't
going to make this problem easier. What would be required to make it
simpler is "SD card is not capable of being ejected" in addition to
"SD card is never ever used on another device". Which pretty much is
what internal memory is.
The remaining complexity is: If I install brick breaker 1.02 on my SD
card. Then swap out another SD card, brick breaker is gone. But if I
install brick breaker 1.02 on that SD card what happens? Given that
many apps the size constraint is in the downloaded datafiles that grow
with use. So even if the app is the same app on the different cards,
they will have widely varied datafiles. Therefor even if it is the
same app, if it exists on two different cards, the phone needs to act
like it's seen two different brick breaker's installed. Two different
application shortcuts etc. Otherwise it would get too complex.
-E
Disconnect
And if I have a brickbreaker button on my home page, I expect it to run whichever one is on the SD, not to have 3 of them listed for 3 cards. (Imagine you have an app deployed out to a salesforce.. do you really want to have to go through 30 pages of "MySales" looking for the one that happens to match the card you're trying to update?)
Romain Guy
reinstalling/updating an app currently triggers two broadcasts:
PACKAGE_UNINSTALL then PACKAGE_INSTALL. If you look in the current
code for Home, you will notice a compile-time flag you can turn on to
automatically remove shortcuts on app uninstall. Unfortunately, doing
so makes you lose your shortcuts whenever you update an app :)
--
Romain Guy
Android framework engineer
roma...@android.com
Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them
Al Sutton
card. It puts a total block on being able to move an SD card between
devices without having to do a re-install (Where would U3 and portable
PC apps be if USB did that?).
If end distributors want to add it, then that's fine. But lets not build
a crude form of DRM into an "Open" OS and not give an option to apps
outside the DRM mechanism.
An SD card is an SD card, putting users through any process beyond
inserting it and being able to use it as storage for apps, data, etc.
and letting them move that between devices is just going to really annoy
people.
Al.
Al Sutton
> ..that is the 2-installs mess.
>
Al.
> Overlay lets it be expanded without spinning a new platform. (n800
> right now can have sd1, sd2, usb-hdd 0-n and nfs mounts..)
>
> Plus it makes it transparent to the app - you still open
> /data/data/com.my.app/ just like before. (So no sdk change.)
>
> On Mon, Dec 22, 2008 at 12:02 PM, Al Sutton <a...@funkyandroid.com
> <mailto:a...@funkyandroid.com>> wrote:
>
>
> I'm not a fan of overlay mounts. What happens when the user runs
> the app without a card in, does wome work, and then inserts a
> card? Does all the data get hidden by the overlay mount?
>
> I think it would be better for the OS to look for an apps data in
> ${app_source}/blah then /blah, then /sdcard1/blah, etc., etc., etc.
>
> Al.
>
--
David Turner
Please lest not go down the route device tied encryption for the SD card. It puts a total block on being able to move an SD card between devices without having to do a re-install (Where would U3 and portable PC apps be if USB did that?).
isn't encryption the only way to prevent other apps from freely reading the content of the "special partition" file on the SD Card ?
Al Sutton
If apps need verify they have been purchased for that device or user
then that's something we need to provide a DRM API for, but free apps
should be freely (and easily) moveable between devices and we shouldn't
look to a solution which gives a poor user experience for free apps just
to accommodate pay-for ones.
The DRM API could be as simple as having a set of license keys which are
associated with the user and/or device which are downloaded when the
user makes a purchase. The keys are stored in a secure location in the
devices internal memory which can't be "adb pulled", include a digital
signature to verify they are authentic, and when an app wants to check
what rights have been purchased it calls an IP which checks the license
keys on the device, returns to the app the features which have been
purchased, and the can unlock functionality as necessary.
Everything in the last paragraph except the protected license key
storage mechanism is something I've already coded as an app, the keys
are <1K each, and this method allows SD cards to contain apps in an
unencrypted file system, and thus negates the need for a re-install
every time a new device is encountered.
Imho any mechanism which stops a user taking an SD card full of free
applications from one android device, putting it in another, and just
using it is just going to annoy users and so should be rejected. You
only need to look at things like the SecuROM saga with Spore to see the
kind of backlash that can be expected.
Al.
Al Sutton
Thanks,
Al.
Disconnect
It makes a few guarantees for apps, including data privacy and data integrity. Unfortunately, they can't be handwaved away, and so any apps-on-sd implementation that will be accepted must make those same guarantees - even if the card is removed from the phone.
On a related note though, I wonder if encfs isn't a better fit - it uses openssl for encryption (I believe we already have an arm-optimized port, and if not we need it anyway for browser etc) and FUSE (which works fine on arm.) There is minor information leakage (size/depth of files) but names and contents are protected, and it has (at first glance) minimal userspace requirements. The biggest advantage is it is dynamically sized - each file is just a file (with encrypted name and standard perms) so it grows/shrinks with the underlying filesystem.
Al Sutton
if anything has been sold to the carriers in relation to it.
I have no problem with data privacy and data integrity where the
application wants them, what I'm against is forcing apps that don't need
(or want) these features into a system that blanket enforces them at the
cost of transportability of applications.
There seems to be a lot of "hacked" functionality. When Mike Jennings
gave his talk in London in September he was being quizzed of trust
mechanisms I offered an option by explaining how the Symbian system
works. His response gave me the impression it was something that hadn't
even been discussed inside the team to the extent he wanted to talk to
me about it afterwards. He got crowded, I gave him my card, I've not
heard anything since.
Hacked functionality may get a job done in the short term, but it
always comes back to bite you in the long term, and from I've seen I
think the big bite on this will be user reaction to not being able to
move around apps on a SD card stick the way they can move portable apps
on their desktops.
Al.
> <mailto:a...@funkyandroid.com <mailto:a...@funkyandroid.com>>>
> <mailto:j...@google.com <mailto:j...@google.com>>>
Disconnect
"Your car alarm prevents people from starting the car." "Ok." .. later.. "..oh, sorry, I didn't expect you to park it under cover. If you park it under cover the alarm doesn't work."
Al Sutton
the plans there is no method of saying "I wan't to park my car in the open".
I'm not saying we remove functionality. I'm saying we offer the ability
not to be bound by it in a context where it may not make sense.
Al.
Disconnect
If an application uses it's default protected path (/data/data/tld.domain.app/) then it should continue to receive those protections, regardless of whether it's path is mapped in some way to an sd card or not.
The choice is there, with the application, no different than it is today. (And if this is just a roundabout way of you saying "I wish the devices/platform were more open" well.. sure.. me too.. but it's not and that isn't going to change. ♞ ..)
http://code.google.com/android/devel/security.html:
A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc.
If you can explain to me how to accomplish that ("no application..has permission to..read or write another application's files") on a FAT-formatted sd card, without encryption, I'd love to hear about it. But you need to include the case where the card is removed from the phone and read in an external device (or where the card is usb-mounted.)
Also note that the document talks specifically about the world-accessible case: "you can use the MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE flags". (So, again, with /data/data/com.my.app mapped strangely or not, other apps can - as expected - continue to just open /data/data/com.my.app/shared/thisfileisshared.txt) That is another good reason for overlay mounting, as well - I shouldn't, as an app writer, have to scan 300 directories looking for the file a different app is exporting.
(And on rereading that doc for the millionth time, it does not actually say the application -itself- is protected. So techincally I guess you could leave the app jar on the unencrypted side. I suspect that is just a omission due to the natural-language formatting rather than an intended gap in the protection..)
Al Sutton
needing to install it on every device the card is inserted into....?
As for permissions on top of a FAT
filesystem...http://en.wikipedia.org/wiki/UMSDOS :)
Al.
> <http://code.google.com/android/reference/android/content/Context.html#MODE_WORLD_READABLE>
> and/or MODE_WORLD_WRITEABLE
> <http://code.google.com/android/reference/android/content/Context.html#MODE_WORLD_WRITEABLE>
> <mailto:j...@google.com <mailto:j...@google.com>>>>>
Disconnect
And the second (or, better, an selinux profile..) is fine inside the device, not so fine outside or with usb mount.
(And for any device builders who are listening.. I'd happily trade the uselessly small microsd that came with it for another 64M usable onboard. I suspect a lot of people would.)
Al Sutton
either using an unencrypted file system, or distributing the key on the
SD (Definatley not a good idea).
As for the UMSDOS, it works, and if it falls short in some places, well,
it's looking for a maintainer :).
Al.
ecompositor
look for the key ( based on user settings pointing to local file or s3
for shared key ). If key is not found user would be prompted. If they
don't have access to the key. They should probably not be running the
app.
On Dec 23 2008, 1:34 pm, Al Sutton <a...@funkyandroid.com> wrote:
> The only way I can see of the run-on-insert apps being possible is
> As for the UMSDOS, it works, and if it falls short in some places, well,
> it's looking for a maintainer :).
>
> Al.
>
> Disconnect wrote:
> > The first depends entirely on how the key generation is handled. (And
> > personally, I think it is better handled through an autorun-style
> > method than through screwing with the main app profile. That covers
> > And the second (or, better, an selinux profile..) is fine inside the
> > device, not so fine outside or with usb mount.
>
> > (And for any device builders who are listening.. I'd happily trade the
> > uselessly small microsd that came with it for another 64M usable
> > onboard. I suspect a lot of people would.)
>
> > On Tue, Dec 23, 2008 at 1:04 PM, Al Sutton <a...@funkyandroid.com
> > <mailto:a...@funkyandroid.com>> wrote:
>
> > into....?
>
> > As for permissions on top of a FAT
> > filesystem...http://en.wikipedia.org/wiki/UMSDOS:)
>
> > Al.
>
> > Disconnect wrote:
>
> > If an application wants it's data to be exposed, it just
> > continues to do what it does today - save it in /sdcard.
>
> > If an application uses it's default protected path
> > (/data/data/tld.domain.app/) then it should continue to
> > receive those protections, regardless of whether it's path is
> > The choice is there, with the application, no different than
> > it is today. (And if this is just a roundabout way of you
> > saying "I wish the devices/platform were more open" well..
> > sure.. me too.. but it's not and that isn't going to change. ♞ ..)
>
> > http://code.google.com/android/devel/security.html:
> > A central design point of the Android security architecture is
> > that no application, by default, has permission to perform any
> > operations that would adversely impact other applications, the
> > operating system, or the user. This includes reading or
> > writing the user's private data (such as contacts or e-mails),
> > reading or writing another application's files, performing
> > network access, keeping the device awake, etc.
>
> > If you can explain to me how to accomplish that ("no
> > application..has permission to..read or write another
> > the case where the card is removed from the phone and read in
> > an external device (or where the card is usb-mounted.)
>
> > Also note that the document talks specifically about the
> > world-accessible case: "you can use the MODE_WORLD_READABLE
> > and/or MODE_WORLD_WRITEABLE
> > <http://code.google.com/android/reference/android/content/Context.html...>
Al Sutton
Al.