More Applications on SDCARD

180 views
Skip to first unread message

lbcoder

unread,
Oct 22, 2009, 1:47:44 PM10/22/09
to android-platform
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.

Eric F

unread,
Oct 22, 2009, 2:43:36 PM10/22/09
to android-platform
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

Jean-Baptiste Queru

unread,
Oct 22, 2009, 3:31:17 PM10/22/09
to android-...@googlegroups.com
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
--
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.

Al Sutton

unread,
Oct 22, 2009, 4:30:49 PM10/22/09
to android-...@googlegroups.com
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.

Jean-Baptiste Queru

unread,
Oct 22, 2009, 4:44:36 PM10/22/09
to android-...@googlegroups.com
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.

Eric F

unread,
Oct 22, 2009, 8:05:48 PM10/22/09
to android-platform
I think the idea of swapping "SD cards" is a bit of an antiquated
notion. Back when people bought 512 MB cards this maybe made sense.
But today's cards are 16 or 32 GB. They are more like a configurable
hard disk for the cell phone. Like when 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
putting the flash card underneath the battery. I just can't imagine a
real situation where a real user would want to swap between two
different sets of installed apps.

The most realistic thing I can think of is a video fiend carries
around a huge movie collection split between 3 or 4 32GB cards. In the
situation where external apps are only located on one card per device.
One of the cards contains say 4GB of apps and the rest are videos. The
rest of the cards contain no apps (because of this proposed
limitation) and all videos. What are the possible problems? The user
only switches to one of the "non apps" card when they want to watch
one of the films. So they aren't likely to be using many apps. The
apps that the user wants to use will hopefully fit on internal
storage. Whereas most of the SD card based apps are large games,
foreground stuff.

Anyone see this in a different way?
> >> On Thu, Oct 22, 2009 at 11:43 AM, Eric F <ericfrie...@gmail.com>
> ...
>
> read more »

Al Sutton

unread,
Oct 23, 2009, 2:56:22 AM10/23/09
to android-...@googlegroups.com
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? - 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.

Al Sutton

unread,
Oct 23, 2009, 2:58:31 AM10/23/09
to android-...@googlegroups.com
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.

Jean-Baptiste Queru

unread,
Oct 23, 2009, 8:28:47 AM10/23/09
to android-...@googlegroups.com
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

Jean-Baptiste Queru

unread,
Oct 23, 2009, 8:05:37 AM10/23/09
to android-...@googlegroups.com
That's the kind of simplification I had in mind. It's unfortunate,
though, as shared UIDs are a great mechanism, and it'd be sad if we
gave developers a negative incentive against using it ("if you used
shred UIDs, your app won't be installable on the SD card").

JBQ

Al Sutton

unread,
Oct 23, 2009, 8:51:03 AM10/23/09
to android-...@googlegroups.com
My view on this is shared UID apps don't lose anything by this, but non-shared UID apps gain the ability to run from SD cards, so its' improving the platform in general whilst not taking anything away.

Hopefully future work will help shared-UID apps as well, but I think the benefits to users from implementing this outweigh the benefits of trying to create the perfect solution for both types of apps.

Al.
________________________________________
From: android-...@googlegroups.com [android-...@googlegroups.com] On Behalf Of Jean-Baptiste Queru [j...@android.com]
Sent: 23 October 2009 13:05
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD

Al Sutton

unread,
Oct 23, 2009, 8:56:19 AM10/23/09
to android-...@googlegroups.com
Fair points. I can see the benefits of not trying to solve this as part of the first step towards SD-card apps given that a solution which addresses all these points will only delay things and may only benefit a limited number of users.

Al.
________________________________________
From: android-...@googlegroups.com [android-...@googlegroups.com] On Behalf Of Jean-Baptiste Queru [j...@android.com]
Sent: 23 October 2009 13:28
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD

lbcoder

unread,
Oct 26, 2009, 12:20:33 PM10/26/09
to android-platform
For your first point, yes obviously the app and associated data must
be on the same volume.

For the second point, why? Should it not be that only *protected* apps
be associated with a particular device? Since it is the protection
itself that defines whether the app is or is not portable to other
devices, i.e., being UNprotected should be considered as authorization
to copy/backup/etc. Why else would they be separated within /data/app
and /data/app-private. I suggest that /sdcard/app-private be encrypted
and that /sdcard/app be open. My concern on this point is the
performance impact associated with encryption/decryption, particularly
with such weak processors. Also, the entire volume need not be
encrypted as a single unit. What is wrong with simply encrypting the
particular files themselves?

Note: the same encryption key could be used for multiple SDCARDs.

Regarding the shared UIDs, the simpler the better. Which is why I
propose that a specific RANGE of UIDs be used for external-apps. If
ALL external apps are given an ID within a specific range, and no
OTHER apps are given an ID within that range, then you are guaranteed
that no unit can possibly have (accidentally) overlapping UIDs. ** now
I understand the need for multiple installed packages to share UIDs by
design, but this is in the case of app-dependencies. The simplest
resolution to this is that for an app to be installed INTERNALLY using
a shared UID, the UID that it shares must ALSO be installed
INTERNALLY. If the app that it depends on is stored EXTERNALLY, then
it must too be installed EXTERNALLY. I don't know about the case of
installing an app externally with a dependency that is already
installed internally. Might be easiest for such dependencies to always
be stored in the same place.

Regarding open sdcard files....
Given a safe unmount of the external media, would this not allow the
system to track and safely close open file descriptors? I.e., the
umount command will fail if there are open file descriptors, so a
minor extension to this would allow us to cleanly kill processes
holding open file descriptors to that media -- I would be inclined to
simply put a "There are open files, these will be closed. Are you
sure?" message, which would then go and kill those processes safely.
Given an unsafe unmount, could we not just "kill -9" all processes
within "lsof | grep '\/sdcard'" or whatever? Isn't something like that
happening already? I.e., any process that has an open file descriptor
on the sdcard *in current versions* must have those file descriptors
closed/processes killed/etc.
> ...
>
> read more »

lbcoder

unread,
Oct 26, 2009, 12:24:30 PM10/26/09
to android-platform
Yes, force app dependencies to be installed to the same media.

App2 shares UID with App1. They must both be installed internally or
must both be installed externally.
I can't see any way that there could be a conflict given this scheme.
> >> On Thu, Oct 22, 2009 at 11:43 AM, Eric F <ericfrie...@gmail.com>
> ...
>
> read more »

lbcoder

unread,
Oct 26, 2009, 12:41:58 PM10/26/09
to android-platform
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.

Jean-Baptiste Queru

unread,
Oct 26, 2009, 1:28:46 PM10/26/09
to android-...@googlegroups.com
The notion of encrypting per-device auth stuff is pretty interesting,
though it obviously adds quite an extra level of complexity.

Keeping the filesystem unencrypted, though, opens quite some cans of
security worms that might be worth avoiding as a starting point.

JBQ

Patrick Ethier

unread,
Oct 26, 2009, 2:40:38 PM10/26/09
to android-...@googlegroups.com
Would someone care to elaborate how the keys to perform all this encryption
are going to be managed?

I've been poking around the source code looking at the JCE stuff (mainly
bouncy castle) and my assumption here is that in order for this to work
properly we'd need to have a definitive key store. Although seems trivial to
generate a Java keystore it becomes less apparent how to integrate the
securing and management of the key store from an end-user perspective.

I'd assume that the private key on each device would have to be protected and
integrated with the phone security mechanisms (Unlock Pattern/SIM PIN) in
order to make any sense or be usable for the end-user. We'd need probably
need a way to "tie" the key and the keystore to the actual device so it
cannot simply be copied off the device and replicated (moving from a
hardware device to an emulator for example). Ideally using some hardware
link, maybe leveraging some of the SIM's crypto capabilities (The intent is
to avoid making this a GSM specific feature but I don`t see how else to
manage right now).

Once you generate this secured key, you can then start doing things like
encrypting packages onto a card and doing signed meta-data manifests.

I'm struggling with a similar problem right now looking at how to get a
device specific PGP (or GPG) key installed on a device in order to enable
secured communications.

If the above is something that the AOSP team would be interested in as a
feature I`d definitely be open to attempt taking it on as a project.

Regards,
Pat


-----Original Message-----
From: android-...@googlegroups.com
[mailto:android-...@googlegroups.com] On Behalf Of Jean-Baptiste Queru
Sent: October-26-09 1:29 PM
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD


Jean-Baptiste Queru

unread,
Oct 26, 2009, 2:45:52 PM10/26/09
to android-...@googlegroups.com
The plan is to store the (randomly-generated) key on /data, with no
user intervention - it doesn't need to be stored any more securely
than anything that's already on /data, since it protects data that's
not any more sensitive than the one on /data.

JBQ

Al Sutton

unread,
Oct 26, 2009, 3:03:18 PM10/26/09
to android-...@googlegroups.com
So what would stop someone with root extracting the key and passing it
over to someone else, thus making the SD card & key a pair?

It might be worth encrypting the key with PKCS#5 (password based
encryption, which is already present in the build according to http://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/package-descr.html
) using the device ID in the OS so that any key copied around won't
decrypt on another device without a fair chunk of work.

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.

Patrick Ethier

unread,
Oct 26, 2009, 3:08:24 PM10/26/09
to android-...@googlegroups.com
This is what I`m alluding to. Using any PBE mechanism will be somewhat
frustrating to the end-user (always think that your grandmother is stuck
operating the device) unless it's integrated in the phone lock/unlock
mechanism.

And yes, copying the key off of /data will be somewhat trivial for anybody
who is motivated enough to get an app working on multiple devices when it
shouldn't unless that key is protected somehow.

Pat


-----Original Message-----
From: android-...@googlegroups.com
[mailto:android-...@googlegroups.com] On Behalf Of Al Sutton
Sent: October-26-09 3:03 PM
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD


Jean-Baptiste Queru

unread,
Oct 26, 2009, 3:10:53 PM10/26/09
to android-...@googlegroups.com
Nothing would stop someone with root access from reading the key, but
then if they have root access they can already read all the files that
the key protects, so this doesn't weaken security.

JBQ

lbcoder

unread,
Oct 26, 2009, 4:58:47 PM10/26/09
to android-platform
I don't think that we need to worry about passwords here... fact is
that if a user password is the key to decryption, then the user knows
the key, which means that they can copy the data we are trying to keep
from being copied. The key has to be random, generated by some
gatekeeper (who would that be?), or hardware-based (i.e. IMEI/SN). The
problem is that no matter what the key is, it *must* be stored
somewhere, and at some point *must* be in memory, and with root, there
is NO place on the phone where it can be stored where it can't be
read, including in ram. This means that the best copy protection
available is equal to the *existing* copy protection, which is
dependent on *regular* users not being able to read anything out of /
data/app-private due to lack of permissions.

The security against root access copying currently works like this;
if (device==ADP1) market-enable-private=false; //or something to that
effect

And quite frankly, it doesn't work since it is trivial for a root user
to pretend to be a G1.

Which means that the whole copy protection issue is there to *limit*
copying (i.e. with regards to the *majority* of users who don't have
root), rather than block it entirely. Regardless of the anti-piracy
scheme, there will always be *someone* who will find a way to get
around it, but for the majority of users, the objective is simply to
make it too technical for them to easily be able to email programs
back and forth to each other, i.e., they will have to find a hacker
website or a root user who isn't worried about the moral issues of
piracy.



On Oct 26, 3:08 pm, "Patrick Ethier" <patr...@secureops.com> wrote:
> This is what I`m alluding to. Using any PBE mechanism will be somewhat
> frustrating to the end-user (always think that your grandmother is stuck
> operating the device) unless it's integrated in the phone lock/unlock
> mechanism.
>
> And yes, copying the key off of /data will be somewhat trivial for anybody
> who is motivated enough to get an app working on multiple devices when it
> shouldn't unless that key is protected somehow.
>
> Pat
>
> -----Original Message-----
> From: android-...@googlegroups.com
>
> [mailto:android-...@googlegroups.com] On Behalf Of Al Sutton
> Sent: October-26-09 3:03 PM
> To: android-...@googlegroups.com
> Subject: Re: More Applications on SDCARD
>
> So what would stop someone with root extracting the key and passing it  
> over to someone else, thus making the SD card & key a pair?
>
> It might be worth encrypting the key with PKCS#5 (password based  
> encryption, which is already present in the build according tohttp://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/p...
> escr.html
> ) using the device ID in the OS so that any key copied around won't  
> decrypt on another device without a fair chunk of work.
>
> 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 26 Oct 2009, at 18:45, Jean-Baptiste Queru wrote:
>
> > The plan is to store the (randomly-generated) key on /data, with no
> > user intervention - it doesn't need to be stored any more securely
> > than anything that's already on /data, since it protects data that's
> > not any more sensitive than the one on /data.
>
> > JBQ
>
> > On Mon, Oct 26, 2009 at 11:40 AM, Patrick Ethier <patr...@secureops.com
> ...
>
> read more »

lbcoder

unread,
Oct 26, 2009, 5:02:44 PM10/26/09
to android-platform
The problem is that where there's a will, there's a way... it would
actually be quite trivial. A simple patch to the decryption program to
input the device ID/IMEI/whatever manually rather than actually
reading it from hardware.

On Oct 26, 3:03 pm, Al Sutton <a...@funkyandroid.com> wrote:
> So what would stop someone with root extracting the key and passing it  
> over to someone else, thus making the SD card & key a pair?
>
> It might be worth encrypting the key with PKCS#5 (password based  
> encryption, which is already present in the build according tohttp://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/p...
> ) using the device ID in the OS so that any key copied around won't  
> decrypt on another device without a fair chunk of work.
>
> 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 26 Oct 2009, at 18:45, Jean-Baptiste Queru wrote:
>
>
>
> > The plan is to store the (randomly-generated) key on /data, with no
> > user intervention - it doesn't need to be stored any more securely
> > than anything that's already on /data, since it protects data that's
> > not any more sensitive than the one on /data.
>
> > JBQ
>
> > On Mon, Oct 26, 2009 at 11:40 AM, Patrick Ethier <patr...@secureops.com
> ...
>
> read more »

Eric F

unread,
Oct 27, 2009, 5:35:26 PM10/27/09
to android-platform
I've followed every single Apps on SD card thread that's ever been on
android-platform AND android-discuss. People act like "this issue has
been hashed out over and over again previously" as a way of dismissing
any communication on this. The truth is the tip of the iceberg has
barely been reached each time.

Now that it is clear that Android 2.0 does not support any kind of
apps on SD and that Google still neglected to hit the send button on
the email saying "512MB isn't really enough guys". We need to revisit
this. We need a complete list of requirements from OHA that are non
negotiable (as in, a guarantee that a solution meeting those
requirements can be merged into AOSP master). We need the Android
developers responsible for:

vold
Package Installation Manager
All the SD card related settings, setup, etc
Application security model
Possibly someone low level on Dalvik to answer questions on memory
management and process killing in the event of SD card failure
Launcher (we want to gray out unavailable programs)
and we probably need an Android Product Manager (if you have such a
role)

We need these people to join this discussion and make sure at the very
least they put in what OHA requirements are non-negotiable, what
problems they foresee, and optionally ideas on how to go start a final
design.

Let's be serious. Just tell us this will or won't happen so we don't
waste OUR valuable time. Otherwise whatever ends up sounding good here
after a lot of careful design will just be discarded in one sentence
by the above individuals at a later date. I would just like an end to
the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
next year" if that's what you mean. Otherwise, the people involved
should start collaborating, perhaps a wiki design doc and start making
serious progress on this.

-E

Avtar Singh

unread,
Oct 28, 2009, 7:50:28 AM10/28/09
to android-...@googlegroups.com

IMHO, security (all the detail that has been discussed in this thread) and doing it reliably are the main challenges in this requirement. Finding a solution would require fair amount of ingenuity. Whether Google / anyone else like OHA is ready to finding a solution using a community approach is not something that I think will happen in these times. But this is just my opinion...

Jean-Baptiste Queru

unread,
Oct 28, 2009, 8:29:10 AM10/28/09
to android-...@googlegroups.com
All the engineers you mention routinely take part in open discussions:
San for vold and SD card management, Dianne for the application and
security model, Fadden for the dalvik side (though I'm not sure why
that's relevant), Romain for the Launcher side (though anything that'd
require to modify Launcher will need to be considered carefully as it
implies that we're breaking compatibility to some extent).

As for product management, I can play one for 10 seconds: "yes, that
sounds like a good idea, you're the engineers, figure out how to make
it happen when you have time for it".

Some of the hard requirements are:
-security: apps2sd must safeguard users' data and developers' code
with as much security as internal storage.
-stability: apps2sd must not cause the system to crash or leak
(including in situations where an SD card is permanently lost).
-compatibility: apps2sd must allow all existing applications (using
supported APIs) to work without modification (to the extent possible).
-ease of use: apps2sd must work with any SD card without requiring any
complex configuration.
-interoperabilty: apps2sd must work with UMS, and the space used for
apps2sd must be recoverable on a regular computer with no special
tools.
-performance: apps2sd must not cause any significant performance
degradation, including CPU, RAM, and battery life.

There's an additional "soft" requirement:
-hot-swap: apps2sd should work on devices with hot-swappable SD cards.

There might be more requirements, but those are probably a decent
starting point.

A major issue is resources: I'd expect that the people I mentioned
above will have time to discuss the design, the code, etc... but
probably won't have time to actually write any of it in the short
term, so there's no clear black-or-white statement about whether
anyone can or will get involved.

JBQ

lbcoder

unread,
Oct 28, 2009, 9:58:06 AM10/28/09
to android-platform
Actually, I think that this project would be a perfect fit with
another possibility that you mentioned... the community-AOSP branch.
It would allow US to develop the system over a period of time, in the
earlier stages perhaps relaxing some of the security considerations in
favor of getting a stable system (of course taking into consideration
the eventual security requirements). I.e., the first step is to build
the infrastructure that allows a group of apps to be added and removed
from the package manager, the second step is to actually get that onto
a single SDCARD and trigger it by sdcard mount/unmount, the third step
is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
system has advanced to a state where it meets the core-AOSP security
and stability requirements (most likely with the assistance of google
engineers in the latter stages), then it can be merged in and everyone
will be happy.

Obviously, as I'm sure that everybody can agree, the current community-
type apps-on-sdcard system leaves a LOT to be desired, and I think
that this is due to the very limited organizational infrastructure
available to the community. When dealing with a project of this
magnitude, there is simply no sensible way to organize the community.
I'm sure that there are a LOT of people who would like to contribute
to this as long as the entire project doesn't rest on one person's
back.

Disconnect

unread,
Oct 28, 2009, 10:08:47 AM10/28/09
to android-...@googlegroups.com
You're forgetting something easy though, on the security side. It is
required to offer the same protection as onboard storage. So all the
encryption/security mess can go away (for now) because aosp ships with
root. And since the word from the beginning was "its not our fault
devices are all locked down" a "complete" solution for android
doesn't have to include encryption or data-signing. (Yes, that leaves
out retail devices, but it also puts some of the more finicky work out
later and possibly gets vendors to contribute it.)

lbcoder

unread,
Oct 28, 2009, 10:17:21 AM10/28/09
to android-platform
I thought that I just said that...
"in the earlier stages perhaps relaxing some of the security
considerations in
favor of getting a stable system".

The main thing to be wary of is that the infrastructure we develop not
preclude the possibility of security, since this would block it from
ever being merged. That means that we need to discuss and assess the
security issues, just not necessarily IMPLEMENT them [all].

On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> You're forgetting something easy though, on the security side. It is
> required to offer the same protection as onboard storage. So all the
> encryption/security mess can go away (for now) because aosp ships with
> root. And since the word from the beginning was "its not our fault
> devices are all locked down"  a "complete" solution for android
> doesn't have to include encryption or data-signing. (Yes, that leaves
> out retail devices, but it also puts some of the more finicky work out
> later and possibly gets vendors to contribute it.)
>

Disconnect

unread,
Oct 28, 2009, 10:22:34 AM10/28/09
to android-...@googlegroups.com
My point is that it will likely get merged ANYWAY. It offers exactly
as much data protection as the onboard storage does.

Christopher Tate

unread,
Oct 28, 2009, 11:09:30 AM10/28/09
to android-...@googlegroups.com
For the record there is at least one more hard requirement: the
solution has to support swappable SD cards, and must "do the right
thing" when an app on SD card winds up having the same uid assignment
as an app already installed on the internal disk. REALLY doing the
right thing involves correctly handling the case of explicitly
shared-uid apps in this situation as well as not-shared-uid.

--
chris tate
android framework engineer

lbcoder

unread,
Oct 28, 2009, 12:46:17 PM10/28/09
to android-platform
Guessing at what is and is not likely to be merged is probably a
little off-topic for this thread, but I have to go with the assumption
that it wouldn't be merged without the security features. And this I
judge not by yours or my own relative perception of the security of
this system wrt the existing security, but rather based on statements
made by JBQ on the matter.

And remember that there is more to security than simply copy-
protection. Take for example the situation where you swap sdcards with
someone, and the sdcard you shove into your phone has a malicious app
on it that wants to steal all of your personal information and send it
off to some hacker. There needs to be a permission verification scheme
in place to handle this possibility. When installing an app
internally, *every* app goes through the process where it shows what
permissions it requires and gives you the option to decline if you
aren't comfortable with it -- and obviously, if you shove in an sdcard
with 500 apps installed, you can't individually verify the security
for *every* app *every* time you insert the card... One possibility
would be to verify security at RUNTIME, but this would get invasive/
annoying very quickly, which is why I proposed the encrypted per-
device configuration file. Perhaps security verification at FIRST-
runtime and added to the per-device configuration file? But even that
would create problems since it would require a *very significant*
change in the package manager and what would it be... dalvik?

So we are left with the possibility of leaving it to a single device,
or to use per-device configurations. If it is left to a single device,
then we need only one encrypted packages.xml file on the sdcard
showing all the apps and all installed apps are authorized. If we use
a per-device configuration, then we need a master (unencrypted)
packages.xml file and a per-device file for each device. Regardless of
which device an app is installed from, it is added to the *master*
list and to that device's configuration file.

The way I look at the per-device configuration file is this;
The package manager is only interested in the per-device configuration
file associated with *that device* and needs to be triggered to
refresh whenever the per-device configuration is *changed*. This has
to happen regardless of whether it is a single-device or multi-device
scheme. The package installer needs to be extended to write BOTH the
per-device configuration file as well as the master file in the event
of multi-device configuration. No other (user visible) functions need
to be added to existing infrastructure to handle multi-device
configurations, but will rather be handled by a separate sdcard-app
maintenance program, which has functions as follows; create app-
storage, destroy app-storage, delete app from sdcard (regardless of
what device owns it), delete per-device configuration file (regardless
of what device it relates to), create per-device configuration file
for *current device*, adjust app authorizations (add or remove from
per-device file pertaining to *current* device).

Scheme: insert sdcard, attempt to mount external apps filesystem. If
exists but there is no per-device config file, launch "sdcard
application management interface", which lists all apps on sdcard,
associated permissions for each, and has a checkbox next to each one,
if checked, it is added to the per-device config file (and package
manager/launcher). If it is a protected app, it is shown, but greyed
out for all devices except the authorized device (being encrypted, it
wouldn't be runnable even if it was authorized). Protected apps are
always authorized to the authorized device (so no checkbox). Protected
apps and per-device configuration files can be *deleted* from *any*
device. Upon sdcard insertion, if per-device configuration *does*
exist, verify that all items within the per-device configuration are
within the master configuration and purge as required. Trigger
application manager to incorporate the apps in the per-device
configuration file.

I think that this is actually quite *necessary*.

Now off the topic of security, I would like opinions regarding the
filesystem for storing these apps. Obviously, it needs to be something
that supports a unix security model. But what are our options? Is extX
suitable? There are issues with ext2 associated with an unclean
unmount. Journaled? BTRfs?

And how do we deal with the filesystem? The downside of putting it in
its own partition is that MS's hostility routines will tell users to
format it (which they WILL do for lack of understanding -- so this is
OUT), another downside is that it will have to be configured at
initial sdcard setup. Partition resizing, though possible and safe in
a controlled situation, is too slow and too unreliable to be
implemented in a phone. Loopback mount? Advantages are that there
won't be a format-this prompt on MS and that it can be safely grown as
needed. Disadvantage there is a limit of 4GiB (fat32 filesize limit).
Is there a way around this limit? LVM would do it, but that's way too
resource intense for the hardware (i.e. major performance impact). Any
simple way to create a spanned file? I.e. you have 3 files ".extapps.
1, .extapps.2, .extapps.3", which are regarded as a single file
".extapps", which contains a single loopback filesystem of up to
12GiB. Does it even matter if we are limited to 4GiB? I suppose that
this could be considered as "future expansion" and doesn't necessarily
have to be implemented right away.


On Oct 28, 10:22 am, Disconnect <dc.disconn...@gmail.com> wrote:
> My point is that it will likely get merged ANYWAY. It offers exactly
> as much data protection as the onboard storage does.
>

lbcoder

unread,
Oct 28, 2009, 12:47:49 PM10/28/09
to android-platform
This has already been discussed.
Look back at the first post of this thread.

lbcoder

unread,
Oct 28, 2009, 12:54:07 PM10/28/09
to android-platform
To be more precise..
First post under "Scheme:" (i), and
13th post (second by me), second paragraph starting with "Regarding
the shared UIDs".

What are your thoughts on this?

On Oct 28, 11:09 am, Christopher Tate <ct...@google.com> wrote:

Patrick Ethier

unread,
Oct 28, 2009, 12:58:44 PM10/28/09
to android-...@googlegroups.com
Just a thought on what you describe below.

Wouldn't it be easier to make a "per application" configuration that gets
stored on the device? The device reads the .APK's stored on the card. At
first runtime it generates a hash of the APK and then prompts for
permissions.

Any time that app comes across the device (whether on another SDCARD that the
user used to back up or whatever) the launcher checks the hash to make sure
it's the same application that got approved previously.

You could also, in the same config file, link each app to a local UID so that
you don't run into the UID problem.

Of course, this feels like you now need changes to the app launcher and the
package manager...

Pat


-----Original Message-----
From: android-...@googlegroups.com

Jean-Baptiste Queru

unread,
Oct 28, 2009, 1:01:18 PM10/28/09
to android-...@googlegroups.com
3 words: simplify, simplify, simplify. Assume it's a really hard
problem (if it wasn't, we'd have solved it a long time ago).

-aim to make the SD card work in a single device. Heck, even if the
system can only track a single SD card at a time it's probably still
fine. Personally, I'd hate to put restrictions on shared UIDs but I
guess that's just a pet peeve of mine.

-filesystem: let's assume some permission-enforcing filesystem in an
encrypted disk image stored in a single file (skip the encryption for
initial development). Start with ext2 or ext3. Once the rest of the
system works, we can refine this part as necessary. Partitioning the
SD card isn't an option. Keep UMS in mind, it's probably more tricky
than it seems.

JBQ

lbcoder

unread,
Oct 28, 2009, 1:20:17 PM10/28/09
to android-platform
Could you check your email client settings... it marked this as spam
and added an ugly ***SPAM*** into the thread title.

I think I understand what you are proposing, but here's where it
breaks down; each application has its home path -- currently in /data/
data/package.name. These files are owned by the UID associated with
that particular app in the system. This means that the same UID must
be maintained regardless of what device the card is inserted into.

Could you go back and please consider my UID range segregation
proposal.

Regarding changes to the app launcher and package manager...
obviously, no matter what scheme is settled on, changes will be
required. Though I don't think necessarily to the launcher (although
it would ultimately be nice to have external apps visually separated
from internal apps...).
> ...
>
> read more »

lbcoder

unread,
Oct 28, 2009, 1:48:08 PM10/28/09
to android-platform
I agree that we need to start simple.
However, I am concerned that design decisions early on may negatively
impact the possibility of future enhancements.

I also understand the issue with restricting shared UIDs... so I'll
propose a scenerio:
Application A is installed internally, B is installed externally,
shared UID. Card is removed, application A is uninstalled and then
reinstalled (so it has a new UID). Card is put back in. Now the UIDs
no longer match unless it stores card info internally. Given the
condition proposed by Mr. Tate, we *must* allow swappable sdcards,
which suggests an eventual requirement to be able to track multiple
sdcards containing apps (I think this would lead to user problems
otherwise). And also, given an ultimate goal of being able to share
sdcards between multiple devices (even if it isn't implemented
initially), then shared UIDs become a real nightmare.

So I'm going to suggest that at least this requirement is fairly
simple to deal with.. during the install process, check for shared
UIDs, if shared UIDs are to be used, only allow installation to the
same location as the existing app in the pair. In the event that an
sdcard is inserted containing an app that wants to share UIDs with an
already-internal app, require that this app be installed internally,
i.e. prompt saying "for this app to function, it must be installed
internally. Do you wish to proceed?". Per one of my previous
suggestions, if the app exists in both places, only the internal one
is regarded as being "present".

On Oct 28, 1:01 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> 3 words: simplify, simplify, simplify. Assume it's a really hard
> problem (if it wasn't, we'd have solved it a long time ago).
>
> -aim to make the SD card work in a single device. Heck, even if the
> system can only track a single SD card at a time it's probably still
> fine. Personally, I'd hate to put restrictions on shared UIDs but I
> guess that's just a pet peeve of mine.
>
> -filesystem: let's assume some permission-enforcing filesystem in an
> encrypted disk image stored in a single file (skip the encryption for
> initial development). Start with ext2 or ext3. Once the rest of the
> system works, we can refine this part as necessary. Partitioning the
> SD card isn't an option. Keep UMS in mind, it's probably more tricky
> than it seems.
>
> JBQ
>
> ...
>
> read more »

Disconnect

unread,
Oct 28, 2009, 1:50:37 PM10/28/09
to android-...@googlegroups.com
There is a LOT of info here about requirements. With that in mind, I
created a google doc:
https://docs.google.com/Doc?docid=0ATHAIHhsIvlLZGQ5Zmh3cDJfNWNycTQyOGc4&hl=en

If I missed any features, or miscategorized any, etc please update the
doc. Please don't destroy it. (Does google docs have wave-style undo?)

Jean-Baptiste Queru

unread,
Oct 28, 2009, 1:54:38 PM10/28/09
to android-...@googlegroups.com
The issue of hot-swapping SD card is orthogonal to that of shared UIDs
- you could turn off the phone, swap the SD and turn it back on, and
the same issue would still exist.

There are so many issues with the notion of sharing cards between
devices that I think it should be a non-goal at this point. Really.
It's great to think about it as we go, but I'd have no qualms making
simplifying decisions right now even if those prevent an immediate
extension to card-sharing.

JBQ

Disconnect

unread,
Oct 28, 2009, 1:55:04 PM10/28/09
to android-...@googlegroups.com
As far as filesystem, can I suggest something like encfs?
(http://www.arg0.net/encfs) That specific tool uses some c++
libraries, but that should be fixable. It does per-file encryption, so
space is trivially recoverable, and it uses fuse and openssl (it
should be fairly independent of any underlying hardware changes, and
able to take advantage of any platform/device level ssl enhancements.)

On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>

Jean-Baptiste Queru

unread,
Oct 28, 2009, 1:59:43 PM10/28/09
to android-...@googlegroups.com
That's out of my league, to be honest. I guess that it is sufficiently
tamper-proof (i.e. that it's possible to detect whether someone tried
to modify the data from outside this one device, including
adding/deleting files), that should work.

I think that it would make sense to write a first implementation of
the filesystem stuff in order to unblock work on the higher layers,
and then write "real" filesystem-level code.

JBQ

lbcoder

unread,
Oct 28, 2009, 2:32:42 PM10/28/09
to android-platform
Regarding the filesystem... ok, loopback ext3 located at /
sdcard/.extapps limit to 4GiB (for now, we can deal with that limit
later). I like ext3 over ext2 because it (typically) doesn't need an
fsck upon harsh unmount. UMS is no issue here since whatever system
mounts the fat32 filesystem will regard the .extapps as any regular
file. Is there any way we can set the file as "hidden" to MS from
within linux?

So to start;
mkdir /data/extapps
dd if=/dev/zero of=/sdcard/.extapps count=200000
mkfs.ext3 /sdcard/.extapps
mount -o loop -t ext3 /sdcard/.extapps /data/extapps

Step 1... enhance the sdcard mount to first mount /sdcard and then try
to mount /sdcard/.hidden to /data/extapps (or is there another
location that would be preferred?), and then unmount function to first
unmount /sdcard/.hidden and then unmount /sdcard.

Step 2... add to the unmount (before unmounting anything) a check for
open file handles and a request to kill the processes or cancel the
unmount.

Question: What is the preferred way to kill off applications? If the
user answers yes, can we just go and *kill* the processes? or is there
a sane shutdown mechanism? Whatever the answer, we need to go and do
it if the user says to.

Question 2: Where is the current mechanism for handling sdcard removal-
without-unmount?

Step 3: (where it gets fun) fix up package manager to be able to add
and remove apps.

Question: Where is the application home directory location and dalvik
cache location established? (I know where they are presently, I need
to know how *it* knows where they are.)

** after this it should *work* (sortof) -- won't be possible to
install apps onto sdcard and won't be sane shutdown of apps if the
card is forcibly removed without unmounting.

Step 4: update installer to prompt for install location.

** here it will be able to install and run apps from sdcard, but
nothing is done to handle UIDs.

Points of failure after completion of step4:
1) things crash bad when sdcard is pulled without unmount,
2) installation of packages when sdcard is OUT will break things in a
BAD WAY,
3) shared UIDs should still work regardless of where things are
located, but may give unexpected results if member of pair is missing
(card out),
4) applications that refer to their home directory by absolute path
will be broken. I don't know what (if anything) we can do about this
except advise app developers to use '~' to refer to home directories.
Is there any way we can internally rewrite paths that look like "/data/
data/my.package.name/" into "~/"? Or maybe runtime-symlink?,
5) no tracking for sdcard, so if the user swaps in another sdcard with
apps, things will crash.
*note: at this point it is already way better than community-hack.

Step 5+: more installer and package manager updates, handling UIDs,
etc. deal with it when we get there.

Disconnect

unread,
Oct 28, 2009, 2:36:41 PM10/28/09
to android-...@googlegroups.com
Where do you put dalvik cache in this plan? I'm thinking it needs to
be associated with the apk for size, but for speed it shouldn't be
encrypted. (At least for now.) And there should be some way of
detecting tampering, or just regenerate all the caches on insert (SLOW
but unlike boot-time, at least we can provide feedback.)

lbcoder

unread,
Oct 28, 2009, 2:40:42 PM10/28/09
to android-platform
I like that document. I have only skimmed through it so far, and only
two question;
- does "mount -o loop -t ext3 /wherever/it/is/located/.extapps /mnt"
count as "standard tools" or "special tools"? it is perfectly standard
on a linux system, but I doubt that it is at all possible on MS.
- *IS* it really a requirement? A regular user doesn't have the
ability to read files off the internal /data partition unless they
have some specific technical know-how.

On Oct 28, 1:50 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> There is a LOT of info here about requirements. With that in mind, I
> created a google doc:https://docs.google.com/Doc?docid=0ATHAIHhsIvlLZGQ5Zmh3cDJfNWNycTQyOG...

Disconnect

unread,
Oct 28, 2009, 2:45:42 PM10/28/09
to android-...@googlegroups.com
I think - esp for now - it would be considered a pass if "delete
.extapps" was possible. (EG no partitioning or other weirdness)

As an additional thought it might make sense to do each app as it's
own bundle. That way a user can say "Oh! That 2 gig mess is
JoesGiantTileGenerator". Means added complexity on the mounts though.
(Hmm. Adds to security though - even with shared-uid, if a user
refuses the perms on an app it is not mounted..)

lbcoder

unread,
Oct 28, 2009, 2:46:51 PM10/28/09
to android-platform
The APK itself, the application's home directory, and the
application's dalvik-cache must all be within the same device. I was
just about to write 'within the same filesystem', but this isn't
necessarily a requirement, i.e., if you use filesystem-level
encryption vs file-level encryption.

And for the initial development, we aren't going to make any (major)
consideration for encryption, except to note that it eventually must
be done (just so we don't write ourselves into a corner).

On Oct 28, 2:36 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Where do you put dalvik cache in this plan? I'm thinking it needs to
> be associated with the apk for size, but for speed it shouldn't be
> encrypted. (At least for now.) And there should be some way of
> detecting tampering, or just regenerate all the caches on insert (SLOW
> but unlike boot-time, at least we can provide feedback.)
>

Disconnect

unread,
Oct 28, 2009, 2:55:06 PM10/28/09
to android-...@googlegroups.com
Right, I keep getting twisted up on that :)

The data -should- eventually support encryption, and the cache
-should- support tamper detection or encryption (to match the apk
security) but right now we're assuming aosp with root. Doh.

I updated the doc as well, since data-protection is a soft requirement
(and I fleshed that out a bit, so if someone - eg jbq - could
doublecheck that it is correct from google's side that'd be nice.)

lbcoder

unread,
Oct 28, 2009, 2:55:14 PM10/28/09
to android-platform
An application can't have a negative impact on security except in two
conditions; 1) it is added by the package manager, or 2) it is a
protected app that can easily be copied. Basically, if everything was
within a single external filesystem, it doesn't matter if some of it
is untrusted as long as you don't allow it to run or be accessed by
other regular users, and it can't run unless it is given the
permission to be added to the package manager.

And it is most definitely possible to delete .extapps (i.e. right-
click, delete). And I don't think there is any reason to secure
against it since it must, by definition, be an intentional and user-
initiated event.

On Oct 28, 2:45 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> I think - esp for now - it would be considered a pass if "delete
> .extapps" was possible. (EG no partitioning or other weirdness)
>
> As an additional thought it might make sense to do each app as it's
> own bundle. That way a user can say "Oh! That 2 gig mess is
> JoesGiantTileGenerator". Means added complexity on the mounts though.
> (Hmm. Adds to security though - even with shared-uid, if a user
> refuses the perms on an app it is not mounted..)
>

Disconnect

unread,
Oct 28, 2009, 3:00:11 PM10/28/09
to android-...@googlegroups.com
It could be considered a security impact if an app is refused by the
user (eg tampering or unwanted) and the associated data is accessible
to a different shared uid app. (EG "No, I don't want to run
JohnsKeyLoggerKeyboard" but oops, the logging it did last time is
already available to "JimsInnocentLookingWebSender". If the user
refuses permission, it should behave as if it was not installed - no
app or data access.)

lbcoder

unread,
Oct 28, 2009, 4:13:54 PM10/28/09
to android-platform
Hmm.. that's an interesting perspective.

I'm trying to wrap my head around this; obviously, it must be clear if
there are shared UIDs in use on the card.

The first thing to think about is that this issue only exists in the
case where multiple devices may share the same sdcard. The second is
that it is impossible for the other device to install a program into
YOUR device -- you must explicitly authorize it. Which means that if
you run the key logger program, then the web sender program can only
be run from the OTHER device unless you actually *do* give it
permission.

The next realization is that BOTH programs must be signed by the same
key, which means they must be published by the same developer.
Naturally, this doesn't stop someone from making manual changes to the
configurations for THEIR device (i.e. manually change the user ID for
a program), however, the security issue here comes from the fact that
the(any) other DEVICE can read YOUR DATA, and this risk has nothing to
do with user IDs.

I think that ultimately, when dealing with sharing between multiple
devices, we may want to implement a per-device USERDATA encryption --
make it optional upon creation, i.e., ask the user if they want to
encrypt userdata, however, this would actually make for SUPERIOR
security compared to the existing model (not that I have anything
against that)... i.e., when in the sdcard setup menu, there is the
button that says "setup sdcard to allow applications to be installed
to sdcard" -- It asks for initial size to devote to apps, and it asks
"would you like to encrypt your application user data? Encrypting data
will have a minimal impact on performance but ensures that your data
is protected in case your sdcard is misplaced. Yes, No."

But since right now this is about getting a minimum-working-system-
that-isn't-an-ugly-hack, i.e., single device, single card, lets just
write this down for deeper consideration when we actually get to that
stage... ;)

On Oct 28, 3:00 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> It could be considered a security impact if an app is refused by the
> user (eg tampering or unwanted) and the associated data is accessible
> to a different shared uid app. (EG "No, I don't want to run
> JohnsKeyLoggerKeyboard" but oops, the logging it did last time is
> already available to "JimsInnocentLookingWebSender". If the user
> refuses permission, it should behave as if it was not installed - no
> app or data access.)
>

Disconnect

unread,
Oct 28, 2009, 4:27:54 PM10/28/09
to android-...@googlegroups.com
I think the loopback method has another major problem -
expanding/shrinking is effectively impossible. (And convincing a user
of this is going to be difficult. Even worse is "I only have 1 app
installed! Why can't I copy it to a smaller sd card?")

Per-file encryption allows for dynamic (and automatic) grow/shrink.
(I'm not sure if encfs supports layering unix access controls on
non-unix filesystems, but that is a clear requirement. Its even in the
doc ;) ..)

I think there is another usecase that applies to the shared-uid issue
but I'll have to think about it to flesh it out better.

lbcoder

unread,
Oct 28, 2009, 4:48:58 PM10/28/09
to android-platform
Actually, expanding and shrinking is trivial.

Expand:
truncate /sdcard/.extapps newsizeM
resize2fs /sdcard/.extapps

Shrink:
resize2fs /sdcard/.extapps newsizeM
truncate /sdcard/.extapps newsizeM

Done.
Note: though 'truncate' makes you think small, it will actually grow a
file by appending 0's.
Note2: for expanding, in order to *feel* safe (even though it makes no
difference), you can replace 'truncate' with 'dd if=/dev/zero
count=amount_to_grow_by_in_blocks | cat >> /sdcard/.extapps'
Note3: do we really want to enable shrinking? a shrink can take a long
time, and if it goes wrong, the data can all be lost.
Note4: expanding is really fast and virtually zero chance of data
loss.

Re: "I only have 1 app... etc." -- if we enable shrinking, they CAN.
Shrink the filesystem so that it fits on the new smaller sdcard, copy
it onto their computer, copy it to the smaller sdcard.

On Oct 28, 4:27 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> I think the loopback method has another major problem -
> expanding/shrinking is effectively impossible. (And convincing a user
> of this is going to be difficult. Even worse is "I only have 1 app
> installed! Why can't I copy it to a smaller sd card?")
>
> Per-file encryption allows for dynamic (and automatic) grow/shrink.
> (I'm not sure if encfs supports layering unix access controls on
> non-unix filesystems, but that is a clear requirement. Its even in the
> doc ;) ..)
>
> I think there is another usecase that applies to the shared-uid issue
> but I'll have to think about it to flesh it out better.
>

Disconnect

unread,
Oct 28, 2009, 4:53:19 PM10/28/09
to android-...@googlegroups.com
Note3. :)

Eric F

unread,
Oct 28, 2009, 4:59:24 PM10/28/09
to android-platform
Is it really impossible to expand or resize? Shrinking is usually
tough, but expansion should not be impossible. Or am I missing
something ( I come from a VM, lvm background where I do a lot of
resize2fs etc )? To me it seems like a good simplification to do the
one file, filesystem approach. It adds a lot of simplifications to the
design. Remember there will be file name restriction differences so a
per-file approach will have to maintain some kind of DB translating
file names.

I also don't think that hiding the Android files on the SD card from
windows file readers is a good idea. I have an 8GB SD card I haven't
used in a while. I only see 4GB available WTH? Format it.. Only the
next day to realize, oh crap, that had all my apps on it.

I think it should be more like

/AndroidInstalledApps/PhoneNameOrID (or if multiple files are used, a
directory instead of an FS image)

So it's clear to the user that there IS something on the card and it
is for Android.

-E

lbcoder

unread,
Oct 28, 2009, 5:01:47 PM10/28/09
to android-platform
Well, if you're worried about that, then its just a question of being
clear about it from the start. When you go to ask the initial size to
devote to apps, you say "you can make it bigger any time you want, but
you can't make it smaller without deleting all the apps and associated
data from the sdcard and starting over fresh, recommended starting
size is 50MiB".

Oh, and we call it "reserved" space. That way it is clear that this
full amount of space is removed from the available total rather than
just being a set limit.

On Oct 28, 4:53 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Note3. :)
>

lbcoder

unread,
Oct 28, 2009, 5:09:47 PM10/28/09
to android-platform
My response to that must have come after you started typing out your
reply...

And regarding the file naming convention... sure. That sounds fine.
Its not really important at this stage though, so lets not get overly
sidetracked.

Gergely Kis

unread,
Oct 28, 2009, 5:52:40 PM10/28/09
to android-...@googlegroups.com
Hi,

Just my 2 cents: I also think it is a good idea to use an overlay
filesystem instead of a loop mounted image file. I think it is easier
to handle, and may provide a user with a more seamless experience. For
example: if the user installs an app on the sdcard, then decides to
delete it. In order to reuse the space that now should be available
(at least the user will think so!), the image file must be shrinked.
When an overlayed filesystem is used, such extra steps are not
necessary, everything works as expected, from the user's point of
view.

The root directory for this filesystem could be marked system + hidden
to signal to users that the they should not mess with the contents
manually, when the sdcard is mounted on a PC.

I am not sure about the performance implications of using Fuse,
probably it would be good enough.
I recall, that in the early days of Linux there was a similar
filesystem that overlayed on msdos filesystems. I don't know if that
FS is still maintained, or if it would be a good idea to use it.

There is one issue with overlays: applications (malicious or simply
buggy) could allow the user to peek under the hood. One solution to
this is to use 2 overlay file systems:

Under /sdapps (or whatever) the system mounts the sdcard applications
and any other directories needed (data, cache ... etc.)
Under /sdcard a very simple overlay is mounted, which simply hides the
storage directory of the sdapps filesystem. This could even be
implemented in kernel space to minimalize the overhead.

What do you think?

Best Regards,
Gergely

lbcoder

unread,
Oct 29, 2009, 10:46:26 AM10/29/09
to android-platform
Gergely:

I have considered that, but have come to the conclusion that it is
quite impossible, or in the least, impractical.

And again, the reason is that the filesystem MUST support unix file
permissions, regardless of the machine upon which it is mounted. Which
means that overlay or not, the filesystem must exist *SOMEWHERE* and
DISTINCT from the existing fat32. It also MUST NOT allow MS to mess
with/move files around due to the potential to screw with permissions,
i.e., the filesystem itself MUST be invisible to MS. See, the problem
is that despite whatever system/hidden/etc. tags you place on the
files, the regular user has no concept of what these mean, so they'll
mess with the files ANYWAYS. Also, leaving the filesystem open to
access by MS means the potential for damage due to system failure/
virus/etc. Better to kill the entire filesystem than to have random
damage done to files within the filesystem causing general
instability. This particular filesystem DEPENDS on certain RIGID
permission structures, which means that a *regular user* MUST not be
able to mess with it directly (they WILL screw it up). Delete it,
sure. Alter it? NO!

Note that the likelihood of it being screwed up by the user increases
greatly when you start messing with permission overlays that are
outside of the underlying filesystem. I think the FS you had in mind
was UMSDOS. Note that UMSDOS is dead -- removed from kernel starting
with 2.6.11. One of the issues with UMSDOS was the need to run umssync
every time it hit MS in order to repair broken permissions. The whole
system was just flakey and we really don't need the headache. That
means regular filesystem.

There are precisely TWO places where you can create a filesystem;
either in its own partition (discussed and rejected -- reason being MS
hostility routines), or as a loopback filesystem within the existing
fat32 filesystem.

There is also a possible future need for encryption at a filesystem
level. This is simply irreconcilable with USMDOS type filesystem
overlays. We would definitely be restricted to file-level encryption,
and with a lot of files, this makes things messy.

ALL:

Something interesting that you brought up (Gergely) that I was
thinking about though... fuse. Not for the purpose of overlaying unix
file permissions, but for the purpose of synchronizing UIDs... I'm
thinking of two (combined) uses... First, EACH package on the sdcard
is assigned a unique FILESYSTEM-UID, so that no two packages on the
SDCARD share a UID (even if they are shared UID packages). The fuse-
filesystem is integrated with the package manager, so it can REMAP
UIDs on the SDCARD packages, including assigning shared UIDs with
internal packages. If a package is not authorized for that device,
then by its UID, it is inaccessible to anything but root. For example,
if the on-base-filesystem UID is 30001, and the assigned system UID is
20001, then fuse looks up UID 20001 and sees that it maps to 30001, so
it is able to access the files having UID 30001.

The SECOND use is for HOME DIRECTORY and DALVIK CACHE entries. This
filesystem could be set up such that ALL package home directories and
dalvik cache entries appear in the expected location -- /data/data,
and /data/dalvik-cache. The filesystem can INTELLIGENTLY union entries
in these locations by UID/GID/filename/etc., i.e., on mount, it adds
the sdcard files in with the internal files, when new files are
created, it intelligently chooses where those files are to reside
based on the UID/GID/filename assigned to that file -- if the ID or
path name matches an external app, the file is created on the external
filesystem. If the ID or path name matches an internal app, the file
is created on the internal filesystem. The really nice thing about
THIS is that it entirely solves the problem of apps accessing their
home directory by *absolute path*, which means that it won't break ANY
app. Also note that with this scheme, the home directories and dalvik-
cache of unauthorized apps can be LEFT OUT from the /data/data and /
data/dalvik-cache.

I figure that we *initially* use fuse simply because it is easier. If
there are performance issues, implementing it in a regular filesystem
might make an interesting longer term goal, HOWEVER, I don't
anticipate any major(measurable even?) performance bottleneck out of
fuse for this use since it is just going to shluff stuff through and
modify UID/GIDs as needed.

I also anticipate that this will help simplify implementation since we
no longer need to track multiple locations for home directories and
dalvik-cache -- we can leave that up to the filesystem. For initial
implementation, we can just leave out this consideration altogether,
i.e. leave the home directories and dalvik cache entries INTERNAL
until we get the thing to (1) be able to merge and unmerge a second
list of packages from the package manager, (2) be able to launch an
app that is stored in a secondary location.

So, revised first steps;
1) upon sdcard mount, attempt to mount loopback filesystem and merge
external list of apps into package manager.
2) revise app launching mechanism to be able to handle apk's in a new
location (note: currently already able to deal with packages from /
system/app, /system/framework, and from /data/app, and /data/app-
private, so this is easy.)
3) upon sdcard unmount, first check for open file handles and running
external apps, ask for permission to close, if permission given,
shutdown running external apps, close open file handles, unmerge
external packages from package manager, unmount loopback filesystem,
unmount sdcard.
4) enhanced installer/uninstaller able to install/uninstall @ new
location

5+) fancy fuse filesystem as defined above for handling home
directories and dalvik cache, sdcard management interface, handle
unexpected removal of sdcard, etc.

NOW, this project is starting to feel manageable ;)
@step 4 we will have a system that is very useful *for root users*,
which will totally obsolete all current versions of community/hacker
apps2sd.

Question:
What is the deal with the dalvik-cache filenames? Note dalvik-cache
file name.... rootpath@subpath@packa...@classes.dex == /rootpath/
subpath/package.apk/classes.dex... I know that this relates to the
path to the actual package, but what is the reason for it? Is it
simply organizational? Or is there more to it?

Note: The current way that 'droid works is that it monitors the app-
install paths for files being added/removed/changed and installs/
uninstalls/reinstalls those packages when such an event is detected.
This *must not* be done for external apps... external apps shouldn't
be auto-installed like this -- auto-uninstall is fine, but install
should be manual (i.e. external app authorization screen) and changes
should only be processed if the change *actually happened* right
there... if upon reinsertion the file is found to be changed, it
should either prompt for action or silently remove it from the
"authorized" list.
** for initial implementation, the automatic install/uninstall/
reinstall behavior should simply be suppressed for external apps
except where initiated by the installer.

Disconnect

unread,
Oct 29, 2009, 10:52:16 AM10/29/09
to android-...@googlegroups.com
Haven't gotten through the whole thing yet, but a couple of quick points inline.

I'll check the rest of the email later and give a better response :)

On Thu, Oct 29, 2009 at 10:46 AM, lbcoder <lbc...@gmail.com> wrote:
> There are precisely TWO places where you can create a filesystem;
> either in its own partition (discussed and rejected -- reason being MS
> hostility routines), or as a loopback filesystem within the existing
> fat32 filesystem.

The third place addresses your next point as well - an encrypted (or
signed) overlay on top of the existing filesystem. (EG encfs). And
note that encryption is not required here - the user SHOULD have
access to their data, just as they would on the onboard flash. What
MUST be in place is protecting one app's data from another.

> There is also a possible future need for encryption at a filesystem
> level. This is simply irreconcilable with USMDOS type filesystem
> overlays. We would definitely be restricted to file-level encryption,
> and with a lot of files, this makes things messy.

> The SECOND use is for HOME DIRECTORY and DALVIK CACHE entries. This
> filesystem could be set up such that ALL package home directories and
> dalvik cache entries appear in the expected location -- /data/data,
> and /data/dalvik-cache. The filesystem can INTELLIGENTLY union entries
> in these locations by UID/GID/filename/etc., i.e., on mount, it adds
> the sdcard files in with the internal files, when new files are
> created, it intelligently chooses where those files are to reside
> based on the UID/GID/filename assigned to that file -- if the ID or
> path name matches an external app, the file is created on the external
> filesystem. If the ID or path name matches an internal app, the file
> is created on the internal filesystem. The really nice thing about
> THIS is that it entirely solves the problem of apps accessing their
> home directory by *absolute path*, which means that it won't break ANY
> app. Also note that with this scheme, the home directories and dalvik-
> cache of unauthorized apps can be LEFT OUT from the /data/data and /
> data/dalvik-cache.

Bind mounting would allow remapping /data/data/ as needed without
having to change anything extra or do any coding. (FYI)

lbcoder

unread,
Oct 29, 2009, 11:07:32 AM10/29/09
to android-platform
Can't use standard bind mounting since it won't be able to
intelligently segregate the files into their actual locations on
devices, i.e., when you have the bind mount of two filesystems and
create a new file within that filesystem, it MUST know where to
actually put that file -- if the app is installed internally, the file
must be stored internally, if the app is installed externally, the
file must also be stored externally.

On Oct 29, 10:52 am, Disconnect <dc.disconn...@gmail.com> wrote:
> Haven't gotten through the whole thing yet, but a couple of quick points inline.
>
> I'll check the rest of the email later and give a better response :)
>

Disconnect

unread,
Oct 29, 2009, 11:13:34 AM10/29/09
to android-...@googlegroups.com
You're thinking of overlay mounting.

Bind mounting says "make this existing path available at this new
location." Very common for things like chroot (mount -o bind /proc
/newroot/proc). So you add /sdstorage/app in the same way as
app-private (obviously without the perms) to the apk search, then bind
mount -o bind /sdstorage/data/data/com.app /data/data/com.app.

lbcoder

unread,
Oct 29, 2009, 11:32:11 AM10/29/09
to android-platform
You're right.
However, this does have other problems... all the bind mounts
(effectively no different from symlinks) need to be managed somehow,
which means coding things elsewhere anyways. I.e., upon app
installation, the installer needs to build the home path and bind it
into /data/data, upon unmount, all the bind mounts need to be removed,
upon sdcard insertion, all the bind mounts need to be created. And how
about the memory impact of having, for example, 500 apps on the sdcard
bind mounted into /data/data and /data/dalvik-cache ?

But again, lets leave this for now and focus on getting the basics
working. We can revisit this when it is time to start getting home
directories and dalvik cache off the internal and into external.


On Oct 29, 11:13 am, Disconnect <dc.disconn...@gmail.com> wrote:
> You're thinking of overlay mounting.
>
> Bind mounting says "make this existing path available at this new
> location." Very common for things like chroot (mount -o bind /proc
> /newroot/proc). So you add /sdstorage/app in the same way as
> app-private (obviously without the perms) to the apk search, then bind
> mount -o bind /sdstorage/data/data/com.app /data/data/com.app.
>

Disconnect

unread,
Oct 29, 2009, 12:22:02 PM10/29/09
to android-...@googlegroups.com
Wait. Epiphany. Simplify. The system provides methods to get to your
files, going outside of that you are off the SDK. (eg
http://developer.android.com/reference/android/content/Context.html#openFileInput%28java.lang.String%29
and similar.)

All we need to do is flag it in the platform as being on
/sdstorage/data vs /data/data. And its arbitrarily extensible.

Maintain a list of storage locations (and attributes such as
system-only, removable, etc), then each application gets an id into
that list. You can have multiple storage locations at once, can have
different names for each card - eg autofs /media/{CARDNAME} schemes -
etc. You could even use that to allow system apps to dump data on to
special partitions.

lbcoder

unread,
Oct 29, 2009, 12:49:02 PM10/29/09
to android-platform
How does that help for applications that already access their (or
others) home directories by absolute path?
http://developer.android.com/reference/java/io/File.html#getAbsoluteFile%28%29

See, we've got this crazy little thing in that one can generally guess
about what their absolute home directory path will be given that it is
in the form of "/data/data/packagename". It may not be a smart way of
doing it, but it can be (and often is) done. Not taking this into
account *will break* all applications that use this approach.

On Oct 29, 12:22 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Wait. Epiphany. Simplify. The system provides methods to get to your
> files, going outside of that you are off the SDK. (eghttp://developer.android.com/reference/android/content/Context.html#o...
> and similar.)
>
> All we need to do is flag it in the platform as being on
> /sdstorage/data vs /data/data. And its arbitrarily extensible.
>
> Maintain a list of storage locations (and attributes such as
> system-only, removable, etc), then each application gets an id into
> that list. You can have multiple storage locations at once, can have
> different names for each card - eg autofs /media/{CARDNAME} schemes -
> etc. You could even use that to allow system apps to dump data on to
> special partitions.
>

Disconnect

unread,
Oct 29, 2009, 1:04:54 PM10/29/09
to android-...@googlegroups.com, hac...@android.com
/data/data is not part of the spec, and ISTR various googlers
vigorously decrying it down through the months.

(Dianne, cc'd you - can you confirm whether or not
"/data/data/appname" is required to work? Or is it enough to just
support openFileInput and related?)

On Thu, Oct 29, 2009 at 12:49 PM, lbcoder <lbc...@gmail.com> wrote:
>
> How does that help for applications that already access their (or
> others) home directories by absolute path?
> http://developer.android.com/reference/java/io/File.html#getAbsoluteFile%28%29
>
> See, we've got this crazy little thing in that one can generally guess
> about what their absolute home directory path will be given that it is
> in the form of "/data/data/packagename". It may not be a smart way of
> doing it, but it can be (and often is) done. Not taking this into
> account *will break* all applications that use this approach.
>

And so will a new device that perfectly legally creates /system,
/appdata and /packages. Or /system, /appdata, /appdb.

(There are lots of crazy things that break between platform revisions.
And ISTR you generally assume anyone who has broken code between
releases did something wrong. Like, say, making assumptions about
where the data files will live.)

lbcoder

unread,
Oct 29, 2009, 1:11:31 PM10/29/09
to android-platform
True enough, but we still don't want to do something that we *know*
will break them...
Secondly though... how does what you suggest actually simplify
things... seems to me that it requires some framework headaches.

Either way though, can we please get this back on track? This detail
REALLY doesn't need to be sorted out right away. Lets get the thing
working while still keeping the external apps data and dalvik-cache
stored internally, and THEN talk about this again.

On Oct 29, 1:04 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> /data/data is not part of the spec, and ISTR various googlers
> vigorously decrying it down through the months.
>
> (Dianne, cc'd you - can you confirm whether or not
> "/data/data/appname" is required to work? Or is it enough to just
> support openFileInput and related?)
>
> On Thu, Oct 29, 2009 at 12:49 PM, lbcoder <lbco...@gmail.com> wrote:
>
> > How does that help for applications that already access their (or
> > others) home directories by absolute path?
> >http://developer.android.com/reference/java/io/File.html#getAbsoluteF...

Disconnect

unread,
Oct 29, 2009, 1:29:11 PM10/29/09
to android-...@googlegroups.com
I thought one of the requirements was that the data and cache be
stored with the app. And how the data is accessed affects everything -
do we need the big complicated multiple-mounts/etc mess we were
discussing this morning, or can we get away with just saying "behave,
and if you need a real path get one via the sdk"..?

Gergely Kis

unread,
Oct 29, 2009, 2:43:21 PM10/29/09
to android-...@googlegroups.com
Hi,

I think your points are valid, but I am concerned with using a regular
loop mount and this whole shrinking / extending business.

Also, using a general purpose FS like ext3 in a loop mount is probably
not very efficient when used on an already slow Sdcard, on a not very
powerful hardware.

So I was thinking of using a special filesystem that was designed for
exactly this use-case:
- stores the contents in a few larger files (to get around the 4GB
maximum file size limit for example)
- it shrinks / extends its data files as necessary
- it provides full posix semantics
- it can encrypt parts of itself for security
- it includes integrity checks.

So I went to the FUSE homepage, and found MetFS.
(http://www.enderunix.org/metfs/index.php?sect=main&lang=en)
It promises something similar, but its implementation is not even on
the proof of concept level. Also, it uses an external work directory,
so it is a no-go.

I really hope, that someone-somewhere already wrote a filesystem for
fuse that could be used as a starting point.

Using a good Fuse (user space) implementation would make the system
probably more robust when the sdcard is yanked out of the phone, but
maybe it is just an preconception from previous bad experiences.

For a very first try, one of the Fuse archive file systems could be
used: http://sourceforge.net/apps/mediawiki/fuse/index.php?title=ArchiveFileSystems

Of course I am almost sure that none of these provide complete POSIX
semantics...


Best Regards,
Gergely

On Thu, Oct 29, 2009 at 3:46 PM, lbcoder <lbc...@gmail.com> wrote:
>
> Gergely:
>
> I have considered that, but have come to the conclusion that it is
> quite impossible, or in the least, impractical.
>

[....]

lbcoder

unread,
Oct 29, 2009, 2:57:04 PM10/29/09
to android-platform
Ultimately, it certainly IS a requirement, but we don't need to
implement EVERYTHING that is required right NOW.

Start by getting a little bit working, then add on. Just keep in mind
the basic requirements so we don't make something that CAN'T be
developed into something that *eventually does* meet all the
requirements.

Note that the main issue is this;
Though apk's are stored in any number of different locations, ALL of
the dalvik-cache and ALL of the home directories are always *in the
same location*. To change this requires that you track down all the
places that refer to these locations and modify them to (1) understand
about internal vs. external applications, (2) be able to look for
these files in more than one location.

And no, I don't agree that what I brought up this morning was a mess.
It is actually the *simplest* way (thus far) of implementing the
system without having to make serious architectural changes AND WITH
it, it also simplifies the whole UID/sharedUID mapping issue, i.e., it
wouldn't require a range of UIDs segregated from the rest -- it could
just remap to any *available* or *appropriate* UIDs.... at mount time.
That includes shared UID between internal and external app!

My point with suggesting this *note: SINGLE extra mount (not a huge
multi-mount mess as you put it)* to combine the internal with external
home directories and dalvik cache is that if we *happen to be*
inclined to use a UID/GID remapping filesystem (the single extra
mount), i.e., to appease JBQ by supporting internal/external shared
UIDs, then it becomes very simple to add in a few extra features to it
-- in order to solve the multiple home directory and dalvik cache
locations problem without having to rewrite the whole infrastructure
behind it. Nevertheless, having not gone into the actual code (yet),
it may be fairly straight forward to extend the infrastructure in this
manner anyways (in which case this is irrelevant).

Or, it may be simple enough to just symlink external home directories
and dalvik cache entries in to existing locations on mount, and clear
them all upon unmount (either graceful or unexpected) or startup...
except that I don't like repeatedly writing to flash memory when it
isn't strictly needed, and plus, it feels (gut feeling) a little
flimsy. In this context, bind mounts are essentially the same as
symlinks, except that they take up RAM, which is a bad thing.

On Oct 29, 1:29 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> I thought one of the requirements was that the data and cache be
> stored with the app. And how the data is accessed affects everything -
> do we need the big complicated multiple-mounts/etc mess we were
> discussing this morning, or can we get away with just saying "behave,
> and if you need a real path get one via the sdk"..?
>

lbcoder

unread,
Oct 29, 2009, 3:13:09 PM10/29/09
to android-platform
I don't see where it says that metfs is not implemented. In fact, it
looks to me that it has been stable since early last year.

The part that looks funny about metfs is its license... the download
page says something about "you will only use for educational
purposes", and the "copying" file says something along the line of "no
warranties, here you go, have fun".

But once again, we ARE getting bogged down here in details that aren't
relevant to this point in the development.

Lets forget about the filesystem -- just use one that is adequate for
our temporary purposes, ext3 loopback, and get a working apps-to-sd
system that allows the sdcard to be removed and reinserted safely. The
filesystem can be changed *any time*. The details of how to merge
external home directories and dalvik cache with internal can come
later.

Now who wants to look at what?
We need to scope out the mount/unmount routines,
We need to be able to add/remove items from the package manager
without going through install/uninstall,
etc.

On Oct 29, 2:43 pm, Gergely Kis <gergely....@gmail.com> wrote:
> Hi,
>
> I think your points are valid, but I am concerned with using a regular
> loop mount and this whole shrinking / extending business.
>
> Also, using a general purpose FS like ext3 in a loop mount is probably
> not very efficient when used on an already slow Sdcard, on a not very
> powerful hardware.
>
> So I was thinking of using a special filesystem that was designed for
> exactly this use-case:
> - stores the contents in a few larger files (to get around the 4GB
> maximum file size limit for example)
> - it shrinks / extends its data files as necessary
> - it provides full posix semantics
> - it can encrypt parts of itself for security
> - it includes integrity checks.
>
> So I went to the FUSE homepage, and found MetFS.
> (http://www.enderunix.org/metfs/index.php?sect=main〈=en)
> It promises something similar, but its implementation is not even on
> the proof of concept level. Also, it uses an external work directory,
> so it is a no-go.
>
> I really hope, that someone-somewhere already wrote a filesystem for
> fuse that could be used as a starting point.
>
> Using a good Fuse (user space) implementation would make the system
> probably more robust when the sdcard is yanked out of the phone, but
> maybe it is just an preconception from previous bad experiences.
>
> For a very first try, one of the Fuse archive file systems could be
> used:http://sourceforge.net/apps/mediawiki/fuse/index.php?title=ArchiveFil...
>
> Of course I am almost sure that none of these provide complete POSIX
> semantics...
>
> Best Regards,
> Gergely
>

Armando Ceniceros

unread,
Oct 30, 2009, 2:52:09 PM10/30/09
to android-...@googlegroups.com

I really don't think a2sd is a good solution at all (I've been following the discussion at android groups), rather, I believe the lack of an a2sd solution will eventually lead to device manufacturers to increase the amount of internal storage available on the device for applications (this is what this project is all about, isn't it, not enough storage for apps?) like Samsung did with it's Galaxy.
We shouldn't assume that a device is going to be used a particular way because then we'll run into problems. We shouldn't assume that an user will want to have their device used that particular way, be it partitioned or with a custom, secure filesystem stored in the SD. How do we explain that they'll lose some of their sdcard to app storage? If we make it automatic, how do we allow the user to disable it if they do not want it? How do we make it if an user wants to have one SD card with apps on it and another one without them?
Again I believe we should let the demand for more storage drive the evolution for the next android devices instead of just making it work and have manufacturers ignore the real need for increased internal storage.

lbcoder

unread,
Oct 30, 2009, 4:39:32 PM10/30/09
to android-platform
That is the most ridiculously short sighted view I have ever heard of.
What are you? A device manufacturer who just wants to keep selling
more hardware?

And this is most DEFINITELY NOT the place to talk about opinions like
that. We are not here to debate the merits of having applications on
sdcards (universally accepted to be a GOOD thing... except for YOU),
we are here to discuss the IMPLEMENTATION of it.

If you are not interested in discussing or participating in
IMPLEMENTATION, then please go somewhere else as your opinion is not
relevant to this discussion.

lbcoder

unread,
Nov 3, 2009, 3:18:12 PM11/3/09
to android-platform
Ok, I've been looking at the source in some detail (not ready to start
implementing yet, just learning it).

It looks to me like the APK can be stored, literally, ANYWHERE -- the
package manager seems to keep track of this location, which
corresponds to the codePath field in the package tag of the
packages.xml file.

I've also seen some evidence that the home directory location has
similar (but unused) flexibility, i.e., the application home directory
is part of the data structure within the package manager, but rather
than being read from the packages.xml file (since it isn't stored
there), it is generated by concatenating the data path with the
package name. Is this right?

Now from what I can tell, the majority of the work is going to be in
or related to frameworks/base/services/java/com/android/server/
PackageManagerService.java -- it seems to be responsible for virtually
everything related to adding/removing packages. Now the easiest part
of this looks to be moving the apk file itself... change to
mAppInstallDir or mDrmAppPrivateInstallDir at application install time
-- and this should propagate right through the whole thing. We'll
leave the private part for now. The second part of the application
install is, of course, mAppDataDir. It looks a little more complicated
-- changing the mAppDataDir value will result in the home directory
being created at an alternate location, but this won't propagate to
the point where that new location will actually be used when the
application runs... at least not after a reboot since there is no way
to shove this info into packages.xml -- so the read/write of
packages.xml needs to be extended to support this (which can be done
in a backwards-compatible way, i.e., if it isn't there, assume it to
be /data/data/package-name).

Question: When this is done, dalvik-cache will still be located at the
standard location. When is the dalvik-cache file created? At install
time or at run time? (believe to be the former, but haven't verified
this), and where is the mechanism that actually determines the
location of and opens this file? Is it part of dalvikvm? Or does it
get passed there by something earlier in the launch process?

And also, at this point, we haven't made any consideration for UIDs.
The UIDs I presume are fully part of the package manager and stored
in /data/system/packages.xml... is that right?

GC

unread,
Nov 5, 2009, 12:16:51 PM11/5/09
to android-platform
RE: Shared UIDs

I've tried to read a lot of this thread. I did skim some portions so
if I missed where this was addressed, please forgive me.

Honestly, I can't think of a single reason to use shared UIDs. They
seem to greatly complicate things and make security harder.
Furthermore, any UIDs assigned to the FS is completely untrustworthy.
We should never rely on FS UIDs as they are trivially manipulated.
IMOHO, we need a per SD UID model which is protected by some layer of
cryptography.

Insert SD. Phone looks in for meta directory on SD for *this* phone's
UUID (android ID, whatever). Every phone should have as UUID so we
should be safe here.

If the file does not exist the phone knows it has never seen this SD
before. The phone now generates a unique ID for this SD and stores it
in in the UUID named file (per device meta file) on the SD. It also
stores the SD's unique ID internally. Encrypted as needed/desired.
Doing so will use a minimal amount of space so even hundreds of SDs
are not a significant concern. Phone must assign UIDs for all
applications contained on the SD - requiring user permission/prompt,
etc.

If the file does exist the phone knows it has seen this SD before. It
now attempts to match its internally stored sd id with the id saved in
the external meta file. This id could be a hash of all the package
names...etc...lots of options here.

The "per device meta file" requires some sort of cryptographic signing
or secure hash or whatever - depending on the level of desired
security and whatever low level encryption/security model makes sense.
The private key or copy of the hash (whatever) is stored internally on
the device and is used to validate the integrity of the meta file.
Validation of the external meta file via internally stored hash/keys
means the contents of the meta file can now be trusted.

Contained in the meta file are the UIDs which the device should now
load, having been previously generated and stored by this same device,
and assigned based on a list of package names. In other words, when
the launcher spawns an application contained on the SD, it looks it up
and now knows the UID it has previously assigned to it. It spawns and
sets the UID accordingly.

Packages which have been installed on the SD but have not yet been
seen by the phone (and accepted/refused by user) can now be easily
identified. Package updates can also be easily identified. Package
identification can easily be addressed via a cryptographic hash and it
too should be stored in the external meta file.

Finally, when the SD is removed, the external UID cache is flushed and
associated applications/services are terminated and cache deleted.
Aside from space constraints, does cache really need to be deleted?

What this solution provides is per device specific UIDs. We never have
to worry about UID conflict as the device is free to assign UIds in a
conflict free manner without concern for conflict with other device
UID assignments. Furthermore, this solution does not require trust of
FS for UID assignment. This is important as any FS which can be
manipulated externally (all SDs) is completely untrustworthy. We store
associated meta data on a per SD basis and only store a minimum of
data internally such that it allows us to trust the meta data provided
on the SD. The minimal internal storage approach allows for vast SD
libraries with minimal internal storage implications. There is some
additional house cleaning which is required here but this seems very
doable and fairly straight forward as cryptographic scenarios go.

Greg

jbdroid

unread,
Nov 5, 2009, 10:17:21 AM11/5/09
to android-platform
I agree with this totally. The need for a2sd is irrelevant with larger
amounts of storage on the device. Dare I say it but the "Other" phone
that uses apps has larger storage and no one thinks of moving apps
between devices or swapping out cards. Only thing that should be on
the SD card is personal music, photos, videos etc... Keep the apps on
the device.

Now what we do need is something similar to DoubleTwist to backup/
restore/upgrade our devices.

Apps on removable storage for a mobile will be a nightmare and drive
developers away.

Just my 2cents

Disconnect

unread,
Nov 5, 2009, 3:55:12 PM11/5/09
to android-...@googlegroups.com
..then clearly you have wandered in here by accident and should be
somewhere else. Bye now! (And fyi, "the other phone" is the only major
smartphone that does not allow apps on removable storage.)
> --
>
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>
>

chad

unread,
Nov 3, 2009, 11:08:29 AM11/3/09
to android-platform
Wondering if somebody can bring to light how other OS phone systems
handle the sd storage issue.

Superg05

unread,
Nov 6, 2009, 3:11:26 AM11/6/09
to android-platform
i sent a letter to the oha once about an idea i had here a summary of
it

installing apps on SDcard u could easily use encryption like
Microsofts .menc files for windows mobile it can't be used off of
device it was installed on not allowing them to be used any place then
the google account holders phones thus solving them being pirated all
over the net

lbcoder

unread,
Nov 6, 2009, 8:21:51 AM11/6/09
to android-platform
Yeah, that's pretty much already been figured out and is written
through various posts in this thread, with minor differences.

Primarily, the problem with storing a per-device UID for every
application for every card is that you could theoretically run out of
UIDs just by installing and uninstalling from multiple sdcards
frequently (since the external UIDs would need to remain reserved from
the system), which is why instead of using per device UIDs, the
consideration is to use per-card UUIDs within a RANGE that does not
and can not overlap with internal UIDs, OR to assign any available
UIDs dynamically at mount-time -- BUT, this would require a filesystem
that could handle changing UIDs, and right now, there is no such thing
(that I am aware of), which makes the segregation possibility slightly
more attractive and/or easier to implement.

The second problem with using per-device UIDs within the card is that
it would require duplication of application home directories.

And regarding shared UIDs, right now the best option seems to be
disallowing shared UIDs between internal and external apps. Shared
internal-internal is fine, and shared external-external is fine.

lbcoder

unread,
Nov 6, 2009, 8:31:35 AM11/6/09
to android-platform
Yeah, unfortunately, a letter that says the equivalent of "wouldn't it
be great if..." really isn't going to help us implement it.

And also for your information... those ".menc" files are basically
*just any* encrypted file. This we can do trivially. Unfortunately, it
doesn't solve anything.

1) EVILDEATH doesn't have filesystem level access controls,
2) EVILDEATH doesn't have multiple UIDs for limiting application
permissions.

Ever wonder why EVILDEATH is so susceptible to viruses and other
malware? They lack the security considerations that we have to make.

On Nov 6, 3:11 am, Superg05 <superg05.jer...@gmail.com> wrote:
> i sent a letter to the oha once about an idea i had here a summary of
> it
>
> installing apps on SDcard u could easily use encryption like
> EVILDEATH .menc files for EVILDEATH mobile it can't be used off of

lbcoder

unread,
Nov 6, 2009, 8:35:19 AM11/6/09
to android-platform
Other phone OSs don't take security into consideration.

PalmOS, for example -- whatever applications are internal or on the
sdcard get access to EVERYTHING.

Disconnect

unread,
Nov 6, 2009, 9:41:28 AM11/6/09
to android-...@googlegroups.com
symbian is similar to palmos - the files are just 'there' and (while
executables may be signed) there are no inter-app protections or data
protection not handled by the app itself. (Or system-level addon
encryption services, for example.)

On Tue, Nov 3, 2009 at 11:08 AM, chad <chad...@gmail.com> wrote:
> Wondering if somebody can bring to light how other OS phone systems
> handle the sd storage issue.
>

GC

unread,
Nov 6, 2009, 11:34:25 AM11/6/09
to android-platform

On Nov 6, 7:21 am, lbcoder <lbco...@gmail.com> wrote:
> Yeah, that's pretty much already been figured out and is written
> through various posts in this thread, with minor differences.
>
> Primarily, the problem with storing a per-device UID for every
> application for every card is that you could theoretically run out of
> UIDs just by installing and uninstalling from multiple sdcards
> frequently (since the external UIDs would need to remain reserved from
> the system), which is why instead of using per device UIDs, the
> consideration is to use per-card UUIDs within a RANGE that does not
> and can not overlap with internal UIDs, OR to assign any available
> UIDs dynamically at mount-time -- BUT, this would require a filesystem
> that could handle changing UIDs, and right now, there is no such thing
> (that I am aware of), which makes the segregation possibility slightly
> more attractive and/or easier to implement.
>

While I didn't state it, I did implicitly state it, my solution does
assume UIDs would be broken into internal and external categories
(thus flushing the external UIDs). And, in my scenario, its *extremely
unlikely* to run out of UIDS - ever. This is also where some of that
house cleaning I mentioned comes in.

The reason why its extremely unlikely to ever run out of UIDs in my
solution is because you're tracking UIDs by package name and hash by
SD. This means the same package having the same hash on a different SD
need not receive a new UID. Furthermore, the package's signing key can
be validated to further differentiate if a new UID is required. This
means the worst case scenario you portray simply doesn't exist; except
where users are installing many tens of thousands of applications.
Bluntly that's just not likely and house cleaning already takes of it,
should it ever happen.

In short, in my solution, the user needs to NEVER clean house and to
have installed over 50,000+ (or far more, depending on how many you
wish to reserve for "internal" consumption) applications before he
risks running out. In the meantime, chances are much higher internal,
per application storage overhead is becoming a heavier resource
burden.

Simply put, UID exhaustion in my solution is simply not likely in the
least. And if it does occur, house cleaning still allows for extremely
easy recovery.


> The second problem with using per-device UIDs within the card is that
> it would require duplication of application home directories.
>

Not all. That's entirely the point of the process, so you can leverage
all existing information associated with the UID, including any pre-
existing home directories.

> And regarding shared UIDs, right now the best option seems to be
> disallowing shared UIDs between internal and external apps. Shared
> internal-internal is fine, and shared external-external is fine.
>

That distinction is already accounted for in my solution. In short,
for my solution to fail means the entire key signing solution for
Android is already broken and/or the cryptographic solution picked for
extension is broken - in which case we're premature in external
application discussions.

Part of the house cleaning would require users have the ability to
"uninstall" applications which are on external media without the media
actually being present. This allows for reclamation of previously
assigned UIDs and facilitate their re-use. So to be absolutely clear,
running out of UIDs is extremely unlikely. Its simply a fringe, corner
case which is easily addressed for the tiny faction of one percent (if
that high) where it may become relevant.

Also, as for house cleaning, its trivial to maintain the last time a
particular SD was observed which makes way for user purge
recommendations. As in, "SD...blah...blah... has not been placed in
this device in 90-days, do you wish me to purge all associated
application data to reclaim internal storage space?"...etc... At which
time the associated UIDs, internal storage, and per application
directories are all purged.

This last part is actually a good segway into the need to associate a
user provided name with each SD, which allows for easy library
maintenance - without regard for my solution.


Greg

lbcoder

unread,
Nov 6, 2009, 3:58:34 PM11/6/09
to android-platform
You are adding in tons of useless complexity and missing a lot of the
logic.

> The reason why its extremely unlikely to ever run out of UIDs in my
> solution is because you're tracking UIDs by package name and hash by
> SD. This means the same package having the same hash on a different SD
> need not receive a new UID. Furthermore, the package's signing key can
> be validated to further differentiate if a new UID is required. This
> means the worst case scenario you portray simply doesn't exist; except
> where users are installing many tens of thousands of applications.
> Bluntly that's just not likely and house cleaning already takes of it,
> should it ever happen.

1) You can NEVER "clean the house" because you will never know what is
on all of those sdcards unless you do something really stupid.
2) There is no reason to keep sucking out of a limited pool of UIDs.

> In short, in my solution, the user needs to NEVER clean house and to
> have installed over 50,000+ (or far more, depending on how many you
> wish to reserve for "internal" consumption) applications before he
> risks running out. In the meantime, chances are much higher internal,
> per application storage overhead is becoming a heavier resource
> burden.

And here lies some problems...
1) there is no need to have ANY internal per-application storage for
external apps AT ALL! In fact, it is explicitly one of the
requirements: That there be NO use of internal storage for external
apps. This is not a hard requirement for *initial implementation*, but
it is an ultimate requirement. We can't be polluting the internal
storage with junk that will just sit there taking up space when the
sdcard is gone.
2) you can NEVER assume that a user would willingly go and 'clean the
house'. Power users, sure. Regular users? Never. Why do you think that
antivirus programs for mshostile are now fully automated? I.e.
background scans and periodic full system scans... because you can't
expect the user to deal with this kind of thing themselves.

> Simply put, UID exhaustion in my solution is simply not likely in the
> least. And if it does occur, house cleaning still allows for extremely
> easy recovery.

And as I have mentioned, your house cleaning would be a deal breaker.
It CANNOT be part of this system.

> Not all. That's entirely the point of the process, so you can leverage
> all existing information associated with the UID, including any pre-
> existing home directories.

So what happens when you put the card into a second phone, which
doesn't know what UIDs were used by those apps?
1) Because the different phone assigns different UIDs, those apps WILL
NOT have access to the application home directories (which are secured
by UID), and
2) by random convergence of UID, you could end up with application X
gaining access to application Y's home directory when using a
different device.
In other words, this solution cannot possibly be used because (1) it
breaks applications, and (2) it breaks security.

> That distinction is already accounted for in my solution. In short,
> for my solution to fail means the entire key signing solution for
> Android is already broken and/or the cryptographic solution picked for
> extension is broken - in which case we're premature in external
> application discussions.

Except that your solution doesn't introduce anything except unwanted
complexity.

> Part of the house cleaning would require users have the ability to
> "uninstall" applications which are on external media without the media
> actually being present. This allows for reclamation of previously
> assigned UIDs and facilitate their re-use. So to be absolutely clear,
> running out of UIDs is extremely unlikely. Its simply a fringe, corner
> case which is easily addressed for the tiny faction of one percent (if
> that high) where it may become relevant.

Here lies extreme danger...
What happens if you install application X, store some sensitive
information in its home directory, pull the card, uninstall it by
housecleaning, install application Y (which gets handed the same UID
as X had), and put the card back in? Well in that case, application Y
has suddenly got its slimy hands on your sensitive information that
was supposed to be secured to application X.

But again, wasted space, needless complexity. When the card is pulled,
it should be as if those applications WERE NEVER INSTALLED. When the
card is inserted into another device, those applications should have
FULL ACCESS to their home directories, which are stored ON THE SDCARD
(not internally).

> Also, as for house cleaning, its trivial to maintain the last time a
> particular SD was observed which makes way for user purge
> recommendations. As in, "SD...blah...blah... has not been placed in
> this device in 90-days, do you wish me to purge all associated
> application data to reclaim internal storage space?"...etc... At which
> time the associated UIDs, internal storage, and per application
> directories are all purged.

This isn't trivial, its excessive and needless complexity that we can
do without.

> This last part is actually a good segway into the need to associate a
> user provided name with each SD, which allows for easy library
> maintenance - without regard for my solution.

Pointless. If the card isn't there, the applications aren't there, and
there is (should be) no need to worry about them.

Look, I've gone over all of this before, so I'm not going to explain
it again just for your benefit. Read this thread in DETAIL and
understand it. I appreciate your ideas, but to be frank, you seem to
have missed this from the FIRST POST:

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

In other words, there is something of a plan *already in place*. We're
not going back to the drawing board without real reason to do so.
Especially for a solution that has at least THREE reasons why it can
NEVER be merged into AOSP.


Now regarding project state...
We are now more or less beyond the "ideas" stage and getting into the
actual implementation/code stage. A few posts back the initial steps
for implementation are outlined. If you are interested in contributing
to that... then it would be a good idea for you to actually start
going through the AOSP source code to get a good idea of the inner
workings of the system so that you can help in actual implementation.
Reply all
Reply to author
Forward
0 new messages