Will android support installing applications on sd cards in the foreseeable future?

[Arron]

Looking at the roadmap, I do not see this being addressed in the
foreseeable future or ever at all. I think it's a big limitation
since I am so conscious of memory right now on my G1 that it's hard to
do anything. I can see this being a hard feature to add but any
insights at all?

If for instance if someone were to try to tackle this problem, would
it need acceptance by the Projects Leads first? I guess I am still
unclear how to request/submit changes for android (even after reading
everything on the site).

[hackbod]

This is something we want to do, but it is not on the immediate
roadmap. If you want to talk about how to implement it, we can, but
be aware that actually doing a production quality implementation is
very non-trivial. Some things that would need to be addressed:

- Security on the SD card, so that apps there don't break the security
model. (The SD card needs to be a FAT filesystem so this will require
trickery of some sort, we are currently looking at putting an
encrypted file system inside a file on the sd card.)

- Dealing with SD cards being removed and inserted, and switching SD
cards. This also needs to work with a paid marketplace, where the
user can't just copy an application from one phone to another and have
it work.

- Management of storage, allowing the user to decide where to install
an app, and probably moving apps between internal and sd card
storage. Key is providing a really simple, intuitive UI.

So this requires significant work across the entire stack: low-level
file systems in the kernel, framework application management, and
settings and installer app UIs.

[Jean-Baptiste Queru]

I'll add a few bits of information here:

-There are obvious problems for the apps installed on the SD card that
are currently running when the SD card is removed: in such a
situation, they can't possibly rely on being able to save any state to
disk: the code that would be used to save data might simply not be in
RAM (and even if the code is there, the logical location to save the
data would be the SD card itself, which would be gone).

-Several aspects of the system itself open application files (the
installer, the system server, just to name a few), and therefore have
to be prepared for the fact that those files might disappear at any
time (and that the file descriptors would have to be closed within
seconds or the entire phone would crash).

-There are a lot of open issues around app management in general:
*if the user installs an app on the SD card, pulls the card, installs
that same app on the internal flash, and puts the SD card back in, the
situation is a bit messy.
*if an app queries the list of installed apps (to know what file types
are handled), a decision has to be made whether it can see the apps
that were installed on the SD card. The result might depend on whether
the querying app is on removable storage itself. It might also depend
on whether the SD card is inserted.
* also, things become more interesting if you start to consider the
possibility that there might be multiple removable slots (I have a PDA
like that), or if you think of how it impacts legacy apps.

-And that's just a quick list of a few ideas going through my head,
which is sure to be incomplete.

JBQ

[DiscoDapper]

The fact that the running of apps off the sd card is difficult to
implement is very understandable, but why release a first Android
showcase device with such limited internal application storage space
if this is the case? I mean, of course it was going to be a problem
and this should have been spotted a mile away. I have spent way too
much time over the years managing storage space on my former WinMo
devices for this to be any fun and am very disappointed in this aspect
of the G1. Good luck implementing it.

[Aaron]

I feel the same way. I think this feature should definitely be pushed
up the roadmap. Two features that will definitely make android more
usable are the virtual keyboard and the ability to install apps on SD
cards. I hope project leads feel the same way and bump this up on the
roadmap. It will become a VERY big problem.

1) when paid applications are available and no one is able to download
anything due to limited memory. Will people also delete applications
and need to repay just to redownload? No one will have memory to try
any applications out.
2) Games coming out will also cost too much memory. Look at all the
good games on the Iphone. They are all 10 megs +.
3) The Market, Email, Browser applications will continue to grow and
take up more and more memory. The market application is the worse
since there is no way to clear it and it keeps on growing and growing.

[Jean-Baptiste Queru]

This isn't as much an issue of roadmap as an issue of actually
implementing all the relevant components. Saying "we'd like it
implemented tomorrow" doesn't mean that it can be implemented in a
day, even if it's made the top priority for all the people involved.
Some things take time. Like I wrote earlier in this thread, there are
still some open design questions, which means that we're not yet at a
point where we can have a good idea about how long the implementation
will take, and therefore putting it on a roadmap would be premature at
this point.

It's obviously one of the pain points with the G1, it's likely to be a
pain point with other devices, and it is important that Android
eventually provide some platform-level solution for this situation. It
has to be balanced against all the other high-priority tasks that the
Android engineering community is working on.

You can help, though, even without writing code, by taking part in the
discussions about the various design decisions. The more brains we
have thinking about the design, the faster it'll be possible to start
an implementation, and the fewer surprises we'll have during and after
the implementation.

JBQ

[ericwong]

Hi everyone,

Why don't the Android team implement and allow the apks on the SDcard
to run like as a "portable application" without even installing at
all?
i.e. just like portable firefox, thunderbird, etc that can be run on a
PC on a USB stick without any installation.

This feature would be very useful for large or seldom used
applications like games which can be swapped and played on a different
Android phones, or stored/archived away on the SDcard without affect
the phone memory.

Cheers
Eric
Portable Electronics Ltd
www.hdmp4.com

On Nov 17, 3:05 am, Jean-Baptiste Queru <j...@google.com> wrote:
> This isn't as much an issue of roadmap as an issue of actually
> implementing all the relevant components. Saying "we'd like it
> implemented tomorrow" doesn't mean that it can be implemented in a
> day, even if it's made the top priority for all the people involved.
> Some things take time. Like I wrote earlier in this thread, there are
> still some open design questions, which means that we're not yet at a
> point where we can have a good idea about how long the implementation
> will take, and therefore putting it on a roadmap would be premature at
> this point.
>
> It's obviously one of the pain points with the G1, it's likely to be a
> pain point with other devices, and it is important that Android
> eventually provide some platform-level solution for this situation. It
> has to be balanced against all the other high-priority tasks that the
> Android engineering community is working on.
>
> You can help, though, even without writing code, by taking part in the
> discussions about the various design decisions. The more brains we
> have thinking about the design, the faster it'll be possible to start
> an implementation, and the fewer surprises we'll have during and after
> the implementation.
>
> JBQ
>

[al74]

I'm a user, not a developer and certainly can't give solutions. I can,
however tell you what you already know:

I am using the App Market very carefully and try not installing apps
unless I truly like them. After a month with the phone and very few
apps I got a message that my memory is too low. I had to remove K3
email (that for some reason included 16MB of data (maybe because of
pop3 emails) application to be able to install new apps. I have no
games installed because my motto is: if you don't absolutely dig this
don't even try it. This phone has no future if people are running low
on memory so early in the game. You must. I repeat must solve this
issue.

[Aaron]

I am not saying that it can be implemented in a day or week or month
but I am just hoping that it will be placed on the roadmap as a high
priority item so more resources are put into it. I know how
challenging it can be, but I am just hoping to see it implemented in
the foreseeable feature, not 1 or 2 years later.

On Nov 16, 4:05 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> This isn't as much an issue of roadmap as an issue of actually
> implementing all the relevant components. Saying "we'd like it
> implemented tomorrow" doesn't mean that it can be implemented in a
> day, even if it's made the top priority for all the people involved.
> Some things take time. Like I wrote earlier in this thread, there are
> still some open design questions, which means that we're not yet at a
> point where we can have a good idea about how long the implementation
> will take, and therefore putting it on a roadmap would be premature at
> this point.
>
> It's obviously one of the pain points with the G1, it's likely to be a
> pain point with other devices, and it is important that Android
> eventually provide some platform-level solution for this situation. It
> has to be balanced against all the other high-priority tasks that the
> Android engineering community is working on.
>
> You can help, though, even without writing code, by taking part in the
> discussions about the various design decisions. The more brains we
> have thinking about the design, the faster it'll be possible to start
> an implementation, and the fewer surprises we'll have during and after
> the implementation.
>
> JBQ
>

[al74]

By the way, all of my Windows Mobile Devices were able to run apps
from the SD card. I don't believe anybody ever identified this as an
issue. A potential device crash (which I assume can be solved with a
restart) is much better than a non expandable one. Its been a month
and I don't have room for applications. I don't see how it can get any
worse. Users can do a lot of stupid things that are not recommended by
the manufacturer that will cause their phone to be unstable or crash.
That's life. Make this ability available, include some strong initial
statement about how it is no longer an option to get the SD card out
unless you turn off the phone and make sure the G2 has enough internal
memory to be fool proof. We cannot wait a year or even 6 months for a
solution. We are running out of space now!

[Christopher Joel]

Even if you are a non-technical user, you should probably make an
effort to understand the current barriers to this feature as outlined
broadly but informatively by hackbod and JBQ earlier in this thread. I
totally agree with you regarding people and their capacity to crash a
device as long as the potential is there, but there are additional
considerations that need to be made for the sake of an effective,
monetized app ecosystem that, above most things, developers trust.
Also, would you really sacrifice the ability to mount your SD card as
a disk on your larger pc? Not saying this feature is perfect or
anything, but it is nice (not to mention one of the G1's major selling
points over the iPhone) and if a system can be achieved, whether it be
through an encrypted virtual FS or some other solution, where
externally-stored apps can co-exist with that mountability, I think
that good planning will be worth everyone's while.

- c

[al74]

No not realy. I am a pretty techy consumer, but although I may
understand that there are no magic solutions I do expect that things
work as long as it is technically possible. There are technical
diffculties in the implemetation of any feature or solution, but
Google needs to understand the urgency of this matter for the sake of
the developers, users and the operating system's future. There is no
point in an huge app market when there is no ability to actually use
it. Developers would have no user base if that user base can install
no more than 20 apps on their phone. I know this can be done with no
major issues on Blackberries and Windows Mobile devices. I could sync
my old Windows Mobile device and drop files to my sd with a small sync
app so I'm not sure why this ability sould not exist on Android (I
assume that you mean that this is not as good as a true usb drive
abilities, well I would rather install a sync app on my desktop than
run out of space for apps on my phone).

I am not saying that you need to ignore technicall issues. I am saying
that this problem is much more urgent than Google seems to think it
is. From reading this forum it appears that Google does not see this
as a priority. Delaying a solution here can proved to be a much bigger
marketing mistake than not including decent media apps, business apps
or decent email app out of the box (which I think was a huge mistake
that made the G1 and thus Android irrelevant compared to the existing
competition). I love this phone but there is no way I will recommend
it to anybody until I know that it can actually store the applications
created for it, like a real smartphone can do.

> > > issue.- Hide quoted text -
>
> - Show quoted text -

[Chris]

I think the one over-arching point you are missing here is that Android isn't intended to be a one-phone OS. The future limitations of the current Android feature-set really sit in the hands of the hardware manufacturer. It would be a mistake to assume that just because your experience with the G1 is dissatisfactory, your experience with a phone running Android is always going to be that way moving forward. If an Android device were released tomorrow that had 8 gigs of internal storage, this would be a non-issue on said device. That is why I doubt that this missing feature is the marketing disaster you claim it is.

On Nov 24, 9:42 am, Christopher Joel <Aar...@gmail.com> wrote: > Even if you are a non-technical us...

[Jean-Baptiste Queru]

The fact that something is urgent or important does not change the
amount of work necessary to make it work.

The fact that Google engineers have commented repeatedly on multiple
threads related to this matter might suggest that Google is very much
aware of the situation.

I'm not quite sure what makes you believe that there's any kind of
delay going on.

JBQ

[al74]

Here are quotes of Dianne Hackborn from a separate thread "Apps on
SD", which made me beleive this is far from sitting near the top of
Google's list:

"There really isn't much more thinking on this than what I said. This
is an
area we are thinking about, but right now there are higher priorities
so
there is not much active work going on."

"I do expect the core Android platform developers to implement this
feature
at some point, but it is not currently on our roadmap (but that also
isn't
saying much, since our roadmap currently only extends to Q1 next
year :p)."

If I'm wrong then I apologize. What you need to understand is that
when apps are free, it is easy enough for the end-user to test
applications and download them with the assumption that if he or she
ran out of space, he will just delete those not used often. However,
coming January, I don't see myself actually paying for an application
knowing that I may need to remove it in a few months if I ran out of
space and a better or a must have app comes along. That's why I think
it is very urgent to resolve this and assure us that we won't have to
remove apps that we paid for just because we ran out of storage space.
The other problem is that there is no way to manage that space. I
installed very few applications under the assumption that the apps are
pretty small so there is actually enough space for future apps.
However, I was surprised to realize that each app (and the market app
itself) consumes additional storage due to additional data that keeps
growing as you use the app. That took out the option for me to
continue using POP email as very quickly it consumed more than 16MB
and I got the low memory warnning. There is no way to know how much
storage you are actually going to have in the future so you can't
realy plan a head. With many apps sized more than 1mb (and the good
ones actually get to 6mb each) this is a real issue.

> >> - Show quoted text -- Hide quoted text -

[Jean-Baptiste Queru]

All right, I'll clarify Dianne's statements a tiny bit, since I
understand how they could be misinterpreted.

Those higher priority items that Dianne is talking about are bugfixes
for features that were put on the roadmap a long long time ago and
have been implemented already. Those higher priority items are not new
features that are competing with "apps on SD" for engineering
resources. No feature implemented from this point on can ship before
those bugs are fixed. At this point, the roadmap that Dianne mentioned
is essentially the roadmap for the bugfixes in question, which means
that "apps on SD" could become the first new feature to be added on
that roadmap (this is not a commitment, and the choice isn't mine to
make).

JBQ

[al74]

Thanks for clarifying.

[Chris]

In addition to considering what JBQ pointed out, you should consider that, while your concerns about app space are legitimate and as a G1 owner I share them, developers won't flock to Android and release truly purchase-worthy apps if they think that the distribution system is too insecure or poorly thought out to be worth their time.

Furthermore, is it set in stone that the only way to re-aquire a purchased app you have deleted is to re-purchase it? I know that Apple's app store remembers your purchases, as they are tied to your Apple account, and let's you re-download previously- purchased apps for free (something I wish they had done with their music years ago). Surely a system could be arranged where app store purchases are tied to a user's Google account, thereby enabling unlimited, free post-purchase downloads?

- c

On Nov 24, 10:39 am, Jean-Baptiste Queru <j...@google.com> wrote: > The fact that something is urge...

> On Mon, Nov 24, 2008 at 7:03 AM, al74 <aviadle...@gmail.com> wrote: > > > No not realy. I am a pre...

[al74]

Applications for BlackBerry, Symbian and Windows Mobile are kept on SD
cards and I never heard of any issues on Dev part. From copyright
protection perspective, why should this be any different than
installing apps on a Desktop PC? As to the possibility to reinstall
apps, that's not going to help if I can't reinstall due to the space
issues. I will have to give up the app because I want to installl
something better but have no room.

[Christopher Joel]

It should be different because piracy is a real problem on the PC, and
digital distribution needs to provide real answers to that problem -
ones that are fair to both developers and consumers - if we want to
further its momentum as a rising way to distribute software. Look at
the game industry, for instance, where developers are flocking away
from the PC in favor of consoles because of how badly piracy is
perceived to hurt their sales figures. Consoles offer a (relatively)
secure platform for distribution, and that small gain in security is
enough to make developers and users alike sacrifice the freedom to
choose their platform.

I think the take-away here is that you shouldn't worry because it
sounds as though everyone agrees with your main concern - the current
implementation is not ideal, especially considering the G1's internal
storage limitations. However, I think that you need to accept the
reality of the situation, which is that Android won't die if this
feature doesn't come out in the immediate future, and the Android-
developing and -using communities will both be much better off if the
solution to this problem, when it does come, is carefully planned out
and executed.

- c

[al74]

Thanks for your input. Just as a note, one of the reason me and many
other chose Android was the huge publicity on its openness. As a law
abiding person who stays aways from DRM'ed solutions like fire due to
their restrictive nature I will be very disappointed if Google will
choose to restrict our ability to use software as long as we comply
with the licensing terms. DRM failed with music. It will fail with
video and software as well. If I wanted total control and restricted
content, I would have turned to Apple and the iPhone. I sure hope that
any solution to this issue will not be delayed due to DRM and content
restriction issues.

> > > enabling unlimited, free post-purchase downloads?- Hide quoted text -

[Dianne Hackborn]

This is not about DRM.  Applications that are on the SD card in its current form can be the victim of viruses and trojans and other such malware, completely breaking down the security system.  Essentially, by giving an app on the raw SD card permission to do something, you would effectively be giving everyone permission to do that thing, since they can just go and put their own code in that app and do whatever they want with its permissions.

A cornerstone of Android is to allow for an open environment in which a user can still feel safe in downloading and trying whatever apps they want without fear of them taking over their phone or doing things they don't want them to do.  We are trying as hard as we can to -not- replicate the desktop environment in this area, where historically there is little to no control over applications and you end up with a sea of viruses and virus checkers and all sorts of problems as a result.  (And note that Microsoft and others are also trying to get out of this world in their current operating systems.)

Putting applications on the SD card without any security or control over what is going on there would be a huge step backwards.

It is to everyone's benefit -- users who feel safe in installing applications and developers who get more users of their applications as a result -- that the system maintain firm control what applications are allowed to do.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[al74]

Dianne,

Thanks for clarifying. I completely agree.

> hack...@android.com

>
> Note: please don't send private questions to me, as I don't have time to
> provide private support.  All such questions should be posted on public

> forums, where I and others can see and answer them.- Hide quoted text -

[Lauren Weinstein]

Of course, in many ways running *any* application is a leap of faith.
( http://lauren.vortex.com/archive/000446.html ). Any app (including
any of the many free apps appearing) could, in theory, use
permissions granted for other than the stated purposes.

Having been involved in applications security design in Unix (later
Linux) environments for several decades, I am unconvinced that there
is a necessary relationship in the Android security model that should
depend on whether or not a particular object is on internal or
mountable media. We've been dealing with setuid (for example)
applications on removable media of all sorts since Unix Version 6
(and earlier). And as others have noted, other mobile platforms
have achieved reasonable security levels while not restricting
applications to internal memory storage.

Creating a system to verify the integrity of applications and their
permissions, independent of stored location, even if tied to phone
IMEI, should not be a major effort and should be a high priority,
unless having G1 buyers feel that they were sucked into something
of a bait-and-switch situation is not a concern.

--Lauren--
Lauren Weinstein
lau...@vortex.com or lau...@pfir.org
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR
- People For Internet Responsibility - http://www.pfir.org
Co-Founder, NNSquad
- Network Neutrality Squad - http://www.nnsquad.org
Founder, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com

- - -

"Dianne Hackborn" <hac...@android.com>:
>
> ------=_Part_19772_22164025.1227562254140
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline

> ------=_Part_19772_22164025.1227562254140
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> This is not about DRM.&nbsp; Applications that are on the SD card in its current form can be the victim of viruses and trojans and other such malware, comple
> tely breaking down the security system.&nbsp; Essentially, by giving an app on the raw SD card permission to do something, you would effectively be giving ev
> eryone permission to do that thing, since they can just go and put their own code in that app and do whatever they want with its permissions.<br>
> <br>A cornerstone of Android is to allow for an open environment in which a user can still feel safe in downloading and trying whatever apps they want withou
> t fear of them taking over their phone or doing things they don&#39;t want them to do.&nbsp; We are trying as hard as we can to -not- replicate the desktop e

> nvironment in this area, where historically there is little to no control over applications and you end up with a sea of viruses and virus checkers and all s

> orts of problems as a result.&nbsp; (And note that Microsoft and others are also trying to get out of this world in their current operating systems.)<br>
> <br>Putting applications on the SD card without any security or control over what is going on there would be a huge step backwards.<br><br>It is to everyone&
> #39;s benefit -- users who feel safe in installing applications and developers who get more users of their applications as a result -- that the system mainta
> in firm control what applications are allowed to do.<br>
> <br><div class="gmail_quote">On Mon, Nov 24, 2008 at 1:07 PM, al74 <span dir="ltr">&lt;<a href="mailto:aviad...@gmail.com">aviad...@gmail.com</a>&gt;</sp
> an> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> <br>
> Thanks for your input. Just as a note, one of the reason me and many<br>
> other chose Android was the huge publicity on its openness. As a law<br>
> abiding person who stays aways from DRM&#39;ed solutions like fire due to<br>
> their restrictive nature I will be very disappointed if Google will<br>
> choose to restrict our ability to use software as long as we comply<br>
> with the licensing terms. DRM failed with music. It will fail with<br>
> video and software as well. If I wanted total control and restricted<br>
> content, I would have turned to Apple and the iPhone. I sure hope that<br>
> any solution to this issue will not be delayed due to DRM and content<br>
> restriction issues.<br>
> <div><div></div><div class="Wj3C7c"><br>
> <br>
> On Nov 24, 2:06&nbsp;pm, Christopher Joel &lt;<a href="mailto:Aar...@gmail.com">Aar...@gmail.com</a>&gt; wrote:<br>
> &gt; It should be different because piracy is a real problem on the PC, and<br>
> &gt; digital distribution needs to provide real answers to that problem -<br>
> &gt; ones that are fair to both developers and consumers - if we want to<br>
> &gt; further its momentum as a rising way to distribute software. Look at<br>
> &gt; the game industry, for instance, where developers are flocking away<br>
> &gt; from the PC in favor of consoles because of how badly piracy is<br>
> &gt; perceived to hurt their sales figures. Consoles offer a (relatively)<br>
> &gt; secure platform for distribution, and that small gain in security is<br>
> &gt; enough to make developers and users alike sacrifice the freedom to<br>
> &gt; choose their platform.<br>
> &gt;<br>
> &gt; I think the take-away here is that you shouldn&#39;t worry because it<br>
> &gt; sounds as though everyone agrees with your main concern - the current<br>
> &gt; implementation is not ideal, especially considering the G1&#39;s internal<br>
> &gt; storage limitations. However, I think that you need to accept the<br>
> &gt; reality of the situation, which is that Android won&#39;t die if this<br>
> &gt; feature doesn&#39;t come out in the immediate future, and the Android-<br>
> &gt; developing and -using communities will both be much better off if the<br>
> &gt; solution to this problem, when it does come, is carefully planned out<br>
> &gt; and executed.<br>
> &gt;<br>
> &gt; - c<br>
> &gt;<br>
> &gt; On Nov 24, 10:14&nbsp;am, al74 &lt;<a href="mailto:aviadle...@gmail.com">aviadle...@gmail.com</a>&gt; wrote:<br>
> &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; &gt; Applications for BlackBerry, Symbian and Windows Mobile are kept on SD<br>
> &gt; &gt; cards and I never heard of any issues on Dev part. From copyright<br>
> &gt; &gt; protection perspective, why should this be any different than<br>
> &gt; &gt; installing apps on a Desktop PC? As to the possibility to reinstall<br>
> &gt; &gt; apps, that&#39;s not going to help if I can&#39;t reinstall due to the space<br>
> &gt; &gt; issues. I will have to give up the app because I want to installl<br>
> &gt; &gt; something better but have no room.<br>
> &gt;<br>
> &gt; &gt; On Nov 24, 11:57&nbsp;am, Chris &lt;<a href="mailto:aar...@gmail.com">aar...@gmail.com</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt; &gt; In addition to considering what JBQ pointed out, you should consider that,<br>
> &gt; &gt; &gt; while your concerns about app space are legitimate and as a G1 owner I share<br>
> &gt; &gt; &gt; them, developers won&#39;t flock to Android and release truly purchase-worthy<br>
> &gt; &gt; &gt; apps if they think that the distribution system is too insecure or poorly<br>
> &gt; &gt; &gt; thought out to be worth their time.<br>
> &gt;<br>
> &gt; &gt; &gt; Furthermore, is it set in stone that the only way to re-aquire a purchased<br>
> &gt; &gt; &gt; app you have deleted is to re-purchase it? I know that Apple&#39;s app store<br>
> &gt; &gt; &gt; remembers your purchases, as they are tied to your Apple account, and let&#39;s<br>
> &gt; &gt; &gt; you re-download previously- purchased apps for free (something I wish they<br>
> &gt; &gt; &gt; had done with their music years ago). Surely a system could be arranged<br>
> &gt; &gt; &gt; where app store purchases are tied to a user&#39;s Google account, thereby<br>
> </div></div>&gt; &gt; &gt; enabling unlimited, free post-purchase downloads?- Hide quoted text -<br>
> &gt;<br>
> &gt; - Show quoted text -<br>
> </blockquote></div><br><br clear="all"><br>-- <br>Dianne Hackborn<br>Android framework engineer<br><a href="mailto:hac...@android.com">hac...@android.com</
> a><br><br>Note: please don&#39;t send private questions to me, as I don&#39;t have time to provide private support. &nbsp;All such questions should be posted
> on public forums, where I and others can see and answer them.<br>
> <br>
>
> ------=_Part_19772_22164025.1227562254140--

[Mark Murphy]

Lauren Weinstein wrote:
> Creating a system to verify the integrity of applications and their
> permissions, independent of stored location, even if tied to phone
> IMEI, should not be a major effort

How long would it take you to write it? Perhaps we can raise the funds
to hire you to create that implementation. Then there is no dependency
on perceptions of priority.

I'm thinking of something along the lines of Gregory Brown's Ruby
Mendicant project from earlier this year:

http://rubymendicant.wikidot.com/proposal

--
Mark Murphy (a Commons Guy)
http://commonsware.com

Android Training on the Ranch! -- Mar 16-20, 2009
http://www.bignerdranch.com/schedule.shtml

[Lauren Weinstein]

Much as I could use and would appreciate such support (believe me!)
it doesn't seem clear that an independent development effort for
such a core functionality would make much sense, given the currently
expressed sentiments of the primary Android development team to hold
off on this aspect of the system. There's a significant risk
of "being all dressed up with no place to go" at the end of the line,
if I'm reading the situation correctly.

--Lauren--
Lauren Weinstein
lau...@vortex.com or lau...@pfir.org
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR
- People For Internet Responsibility - http://www.pfir.org
Co-Founder, NNSquad
- Network Neutrality Squad - http://www.nnsquad.org
Founder, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com

- - -

>

[Dan Bornstein]

On Mon, Nov 24, 2008 at 3:12 PM, Lauren Weinstein <lau...@vortex.com> wrote:
> Of course, in many ways running *any* application is a leap of faith.
> ( http://lauren.vortex.com/archive/000446.html ). Any app (including
> any of the many free apps appearing) could, in theory, use
> permissions granted for other than the stated purposes.
>
> Having been involved in applications security design in Unix (later
> Linux) environments for several decades, I am unconvinced that there
> is a necessary relationship in the Android security model that should
> depend on whether or not a particular object is on internal or
> mountable media. We've been dealing with setuid (for example)
> applications on removable media of all sorts since Unix Version 6
> (and earlier).

I think you may be ignoring some key distinctions / differences here:

* As a necessary part of compatibility, external SD cards use the FAT
filesystem, which has no permissions.

* The Android permissions model doesn't have a way to give
fine-grained access to external storage. A process either has full
access or no access. No middle ground.

In contrast, access to the internal filesystem is fine-grained. An app
gets write access only to a controlled subset of the filesystem, and
its slice can be monitored (e.g. for quota).

The threat that is being prevented by not allowing apps to live on
external storage is this: One app, Mallet, is trusted by the user to
use external storage but not trusted to do anything else. Another app,
Alice, is trusted to do something else (say, access the net). If Alice
is installed directly on external storage, then Mallet could alter
Alice's code to do Mallet's bidding and abuse Alice's permissions,
despite the device owner's desire for Mallet to be confined.

This isn't about an app being able to use permissions in a deceptive
way, and I don't think anyone has claimed otherwise. It is about apps
not being able to subvert other apps.

> And as others have noted, other mobile platforms
> have achieved reasonable security levels while not restricting
> applications to internal memory storage.

I'm not going to say it's not true, but I don't think I read any
well-backed claims in this regard. I think the claims were more at the
level of "[platform x] seems to work well for me" and not "here is how
[platform x] achieves the same level of security while still allowing
applications to be installed on an SD card."

> Creating a system to verify the integrity of applications and their
> permissions, independent of stored location, even if tied to phone
> IMEI, should not be a major effort

In fact, a couple of Android folks already outlined what this would
look like for Android in previous messages to this group. I disagree
with you in that I believe it *would* actually be a major effort. As
per previous discussion, it would impact several layers of the system,
from the filesystem drivers up through the UI.

FWIW, I'd love to see it all happen, myself.

-dan

[Lauren Weinstein]

I realize that there is frequently a struggle between what we might
call "cleanliness" (especially when dealing with systems that will
be targeting multiple platforms) and practicality. It's also clear
that this particular issue under discussion would be largely a no-op
on a device with much more internal storage.

But the dichotomy of the current situation shouldn't have been
necessary. The Android platform was clearly going to engender a
cornupcopia of applications, and the combination of that with such
limited applications storage space should have been an obvious
situation to avoid. Given that adding more internal memory could
have genuine cost considerations, dealing with the external storage
aspect from day zero would have been a very desirable course.

The workaround that occurs immediately to me (and that I see has
been mentioned earlier) is of course basaically to dump a virtual fs
on the storage card and either sign or encrypt that fs to prevent
tampering. Rather ugly and somewhat non-generalized? True. Some
negative speed and efficiency issues? Yep. But it would still seem
a practical approach to help solve what really is an immediate
problem. Cleaner and more general solutions could come later.

This really is something that needs to be solved now, even if it's
done essentially with a temporary hack for the time being. Once
non-free Android apps start to appear in quantity, it will become
especially difficult to keep this issue caged up effectively.

--Lauren--
Lauren Weinstein
lau...@vortex.com or lau...@pfir.org
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR
- People For Internet Responsibility - http://www.pfir.org
Co-Founder, NNSquad
- Network Neutrality Squad - http://www.nnsquad.org
Founder, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com

- - -

> On Mon, Nov 24, 2008 at 3:12 PM, Lauren Weinstein <lau...@vortex.com> wrote:

[al74]

I couldn't agree more.

> Tel: +1 (818) 225-2800http://www.pfir.org/lauren
> Co-Founder, PFIR
>    - People For Internet Responsibility -http://www.pfir.org

> Co-Founder, NNSquad
>    - Network Neutrality Squad -http://www.nnsquad.org

> Founder, PRIVACY Forum -http://www.vortex.com

> Member, ACM Committee on Computers and Public Policy
> Lauren's Blog:http://lauren.vortex.com
>
>  - - -
>
> > On Mon, Nov 24, 2008 at 3:12 PM, Lauren Weinstein <lau...@vortex.com> wrote:
> > > Of course, in many ways running *any* application is a leap of faith.

> > > (http://lauren.vortex.com/archive/000446.html).  Any app (including

[Joe Onorato]

At this point, I think the basic outline of how the project leads would like to see this done has been outlined.  If you guys want to implement it, and end up implementing it that way, I think it would be fantastic.  Even better would be to work towards it with us.  We have some amount of time allocated to helping people out with features that they want, but lots of other work to do.  So it's not like you'd have to work in a vacuum and then throw it over the wall, hoping a patch is accepted.

It's just not at the front of Google's list of things to do.  It makes sense that people on this thread want it, but it isn't the #1 desired feature.  Look at the roadmap for what other features are ahead of it in the queue.

-joe

[John Doe]

Hello all,

I tend to agree with the opinion, that the memory limitation on G1 is
a problem. While there may be devices with more memory in future, it's
the currently available devices that will set up the expectations and
acceptance. Of course, it may happen that there will be no devices
with more memory, as there is no clearly communicated roadmap and no
announced releases of other devices (in comparison, Dream was
announced one year in advance).

To summarize, the constrains from technical point of view are:

- the filesystem on the memory card must be FAT: users expect that
they can take the memory card and use it with desktop computer,
devices or use phone as USB mass storage device.

- android security model requires permissions, at least rwx for ugo
(user, group, others). For this reason the applications and their data
cannot be on the FAT filesystem.

- programs cannot have mmaped files from device, that can disappear at
any time.

Now I want to question some assumptions behind these constrains:

- are the constrains above always true? For example, are the users
that want to use the phone as a thumb drive or mp3 player the same
users, that want to extend available memory of the phone?

The users could decide how they want the memory card by formatting: if
they use FAT, it will behave as an mass storage device, without using
it for applications. If they format it using yffs2/ext2/whatever, it
will be used for applications, but not for mass storage and they will
not be to use it with other devices. (For what is worth, the system
could accept partitions and the users would choose, how they want to
allocate the space. Even Apple did something similar with iPods
(shuffle) in the past.)

Also, users with cards formatted as a memory extension are not likely
to take it out. They know, that they have applications running off it
and there is nothing to gain by removing the card while the phone is
booted. And they may be more than willing to lose mass storage
support, provided they have another mechanism to access the files,
OBEX FTP for example. Protocol like this can solve two problems: the
filesystem does not have to be FAT and there will never be concurrent
access by two independent filesystem implementations.

- does the solution has to be 100% foolproof and consider every corner
case?

Imperfect solution that will give the users what they want may be
better, than waiting for months for complicated solution, that may not
provide 100% of requirements anyway. Partition schema is simpler, may
be more robust than complicated scheme with dynamically growing
encrypted file and the users may be satisfied with it anyway.

It also does not commit to doing it this way forever. If in future
there is better way developed, it may be transparent to switch from
using partitions to another approach.


I'm basing this on personal experience with Symbian phone. While it
uses FAT filesystem, you cannot have applications running off the card
and use mass storage simultaneously. You pick one or another. In the
end, it is more comfortable to just leave applications running and use
something else than mass storage (Symbian provides OBEX FTP support).

Also, what I consider important, you can install everything on the
memory card and setup the built-in applications to save their data to
memory card. The net result is, that you can remove the memory card
and sim card, put them into another phone and have everything set up.
This is great, if your phone breaks (yes, it happened to me in the
past and this allowed me to switch easily to new phone in matter of
minutes).

The permissions in Symbian are solved this way: each application has
assigned an unique SID and there are directories named using \Private
\<Number> convection. Each application can access only its' own
directory, where the number in directory name matches its own SID.
Other subdirectories in \Private are denied (except for applications
with AllFiles capability).

Any thoughts?

-jd

[Ian Copp]

> The permissions in Symbian are solved this way: each application has
> assigned an unique SID and there are directories named using \Private
> \<Number> convection. Each application can access only its' own
> directory, where the number in directory name matches its own SID.
> Other subdirectories in \Private are denied (except for applications
> with AllFiles capability).

This sounds like a good idea, but does anyone know how feasible it is?
Would Android apps be able to spoof whatever unique identifier other
apps are using?

[Joe Onorato]

This is basically what android already does.  Each application's data goes into a directory that only it has read access to.  On linux, that is controlled by file permissions.  For that to work, it can't be on a partition formatted with FAT, because FAT doesn't have permissions that are fine grained enough to implement that.  That's why the best possible solution we've come up with is to put a filesystem that does have permission support into a file on the sd card and put the apps in there.

[Ian Copp]

So there's no way to limit the app's access, with some kind of
middleware layer, to only a particular folder/file/whatever?

[Ian Copp]

That is to say, some kind of software function that the app has to get
its access through to use external storage, rather than the normal
file permissions setup. Sorry if that wasn't clear.

[Jean-Baptiste Queru]

Nothing prevents an app from making direct system calls without even
going through the provided C library - i.e. there's no guarantee that
anything exists between the app and the linux kernel.

JBQ

[Aaron]

From the looks of it, the G1 will probably never see the support of
installing applications on SD cards. Even with this feature, you will
easily run out of memory quickly due to so many internal applications
caching to the internal *limited* memory (market, browser, email, and
etc). You can clear the memory (not the market application) but it's
a hassle.

By the time the feature is even completed, I am sure the G1 will be
out-of-date and new phones (ones that will have a ton of internal
memory) will be out. At this point, I guess it's best just to install
wisely, bypass basically any games, and repeatedly clear cache just to
save enough memory for the phone.

It's a disappointment for sure.

*end of rant*

[al74]

It is indeed very disappointing. I love this phone and the operating
system but I would not recommend it or Android only due to this
oversight. After a month of owning it I constantly checking memory and
worried about the low memory notice, trying to figure out how to save
space. I just can't believe that Google still does not see this as a
priority. Right now, it does not seem that Android is an operating
system
that should be installed on phones with small internal memory capacity
like the G1. It's strange that Google, HTC and T-mobile didn't think
about this when
developing the hardware and operating system.

[Tomred]

I have owned numerous high end phones mostly by HTC.
This phone by far is the worst. I also used the original iphone
unlocked for tmobile and that phone is still light years ahead of this
one.
Apps are terrible. Google does not update this phone. I would not
recomend this phone to anyone other than and enemy.
If I could sen this phone back I would.

No auto rotation. No onscreen keyboard. No saving apps to memory.
Why have a 8gig memory card if all you can save this is photos and
ring tones.

Im going back to windows mobile atleast it does everything and more.
Terrible job google. Thanks!

[Jean-Baptiste Queru]

"never" is a very very long time, and putting apps on the SD card
isn't the only way to relieve pressure on the internal storage (I can
think of at least two other options that would make a significant
difference without going as far as having apps on the SD card).

JBQ

[al74]

In terms of the average life of an electronic device such as a cell
phone, never is about a year, year and a half. In terms of a first
device like the G1, which is owned by many early adopters, never is
even less
than that.

If you can implement a quicker temporary solution it will be much
appreciated, but eventually, the only long term viable solution is the
obvious
one: you should not restrict the storage options to internal memory in
a
device with such a low internal storage capacity. That was a mistake
in the first place.

On Dec 7, 9:21 am, Jean-Baptiste Queru <j...@google.com> wrote:
> "never" is a very very long time, and putting apps on the SD card
> isn't the only way to relieve pressure on the internal storage (I can
> think of at least two other options that would make a significant
> difference without going as far as having apps on the SD card).
>
> JBQ
>

[Jean-Baptiste Queru]

You really make it sound like Google is conspiring to make your life
miserable, as if we had had code in place that would have allowed
users to install apps on the SD card and then spent some extra time to
explicitly remove that functionality.

At the risk of ruining your conspiracy theories, that's just not true.

There really were other tasks that were more important than apps on
the SD card that had to be implemented first (e.g. being able to
reliably download apps and other files, being able to install apps at
all, and being able to use the SD card reliably - I'm not joking here,
those got worked on until fairly late in the development process).

We've said it already, I'll repeat it here: a significant amount of
additional work is necessary to allow apps to be installed on the SD
card. We recognize that this the limited amount of internal storage is
causing some pain for some users. There are ways to reduce pressure on
the internal storage that don't require to install apps on the SD card
(and therefore are much easier to implement). We've got some
commitments that have been communicated on the roadmap and that are
competing for resources. We gladly accept high-quality design and code
contributions, and this is the right place for those discussions.

Complaining about things isn't going to achieve much (except getting
people annoyed). Actually working toward a solution will.

Oh, and one last thing: you're right that the shelf life of a device
is about 12 to 18 months. Its useful life is typically 3 to 5 years,
though. With a platform like Android that allows OTA updates, the
latter duration tends to be more relevant than the former, since the
software can be updated at little relative cost even after the devices
have left the factory.

JBQ

On Sun, Dec 7, 2008 at 7:24 AM, al74 <aviad...@gmail.com> wrote:
>
> In terms of the average life of an electronic device such as a cell
> phone, never is about a year, year and a half. In terms of a first

> device like the G1 owned by many early adopters, never is even less
> than that.
>
> If you can implement quickest temporary solutions it will be much
> appreciated, but eventually, the only viable solution is the obvious
> one: you should restrict the storage options to internal memory in a

> device with such a low internal storage capacity. That was a mistake
> in the first place.
>
> On Dec 7, 9:21 am, Jean-Baptiste Queru <j...@google.com> wrote:

>> "never" is a very very long time, and putting apps on the SD card
>> isn't the only way to relieve pressure on the internal storage (I can
>> think of at least two other options that would make a significant
>> difference without going as far as having apps on the SD card).
>>
>> JBQ
>>

[David Given]

Jean-Baptiste Queru wrote:
> We gladly accept high-quality design and code
> contributions, and this is the right place for those discussions.

Would an option to copy the 'internal memory' filesystem onto the SD
card be considered an acceptable solution by the carriers?

The way I'd envision this is to have the phone format the card, create
an encrypted filesystem, and then copy the internal filesystem onto it.
Now, whenever the phone is booted, the card would be mounted instead of
the normal internal flash. Reboot with the card removed and you'd go
back to the internal flash filesystem.

Immediate problems I can see:

- problems if the card is removed while the phone is running
- no way of copying data back into the phone internal filesystem
- no user-accessible SD card any more; /sdcard would have to be a
directory in the filesystem, and there wouldn't be access to it from
other machines

Benefits:

- easy to implement
- user upgradable
- allows different 'phone personalities' by simply replacing the card
and rebooting (it's actually a pity the whole MegaSIM concept died; that
would be ideal for this)

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)'
│ --- Conway's Game Of Life, in one line of APL

[Jean-Baptiste Queru]

You probably want to scroll back to the beginning of this thread about
a month ago for all the gory details.

In a nutshell:
-yes, an encrypted filesystem on the SD card is one of the components.
It works better if the encrypted filesystem lives in a disk image on a
FAT SD card (rather that the opposite) for interoperability reasons.
-from that point the challenges are indeed related to what happens
when the user pulls the SD card (i.e. both the actual action of
removing the card, and the fact that the card isn't there).

JBQ

[al74]

Just to clarify, I don't think and never implied that you are avoiding
this on purpose. I love the G1 and think you are doing a great job. I
am, however, experiencing a major headache very early on in the game
with these low memory notifications. I am not using my pop3 email
because in a week it increased the email data stored on the internal
memory to 17mb. Many times I see an application I like on the market
and I'm disappointed to learn that it's bigger than 1MB (and most of
the nice ones are). I heard of the possibility that Guitar Hero will
come to Android on January and rather than being happy, the first
question I asked myself is how big an app like this is going to be. I
know that I am not going to pay for any app that is not a "must have"
for me simply because I will not pay for something that I will need to
delete in the future due to lack of storage space. The issues I
described here are shared by an alarmingly increasing number of G1
owners and this is getting to be the number 1 issue reported (and
again, it's been about a month since the phone is out).

I love the phone, but I never thought that in the era of $20 8gb
microsd cards my biggest issue with a smartphone will be it's storage
capacity. I have been using smartphones for 5 years and it has never
been an issue. From Symbian to Blackberry to Windows, they all were
able to have data stored into card and it was never an issue. That why
when I read all of your detailed explanations I hear myself saying:
"this has probably made sense if this was the first device
implementing apps on storage card, but why is this guy keep saying
that this is a problem when almost every other operating system on the
planet has this feature implemented".

I am not a developer and don't know how to write code. The only way I
see this is fixed is by making sure Google, HTC and T-Mobile
acknowledge the issue and promise to fix it as soon as possible.
That's what I am trying to do. Sorry that you are annoyed but it's
your product.

[Jean-Baptiste Queru]

Thanks for your feedback.

I think that the issue has been acknowledged already, multiple times,
as recently as 2 hours ago.

At this point all I can promise is that this issue will get fixed when
it gets high enough on someone's priority list for them to spend the
time designing a solution and getting it discussed, writing the code,
getting it verified, approved, and submitted.

Apps on SD card isn't an end in itself. It's only a means to an end:
the real goal is to not run out of storage space on the SD card. You
mentioned that you were having issues because you have 17MB of email
data on your internal storage. Being able to install apps on the SD
card isn't going to help with this, the real solution is to either
store that mail somewhere else, or to have the email app discard it
when space is needed.

In a way, every issue will be fixed "as soon as possible". There are
just so many issues that it's not possible to fix them all right now,
they've got to be prioritized, and the top of the priority list is
what's been communicated on the roadmap. Making hard commitments
beyond that would reduce the ability to adapt to changing conditions
in a short time, so you need to expect the future to remain vague
beyond a couple of quarters.

JBQ

[al74]

Thanks. I appreciate your honesty and I understand that perhaps other
than relaying our frustration to those making such priorities you may
not have the ability (or desire) to speed the solution to this issue,
but what you are telling me is that unless something very unusual
happen, I should not expect a solution before the end of Q2 2009 at
best, and unless you can assure me that you will incorporate other
solutions to the our limited storage issue sooner, your answer and
acknowledgment of the issue are not good enough (although I understand
that it may the best you can do for now). So, until I hear otherwise I
have no choice but to make sure my voice is heard loud and clear and
as often as I can (maybe we should start emailing Google and T-
Mobile's upper management, we will think of something). I just don't
see myself keeping this phone for 2 or 3 more quarters if this problem
persists. Sorry if it makes you unhappy but until I learn how to code,
that's my only course of action I can think of short of getting rid of
the phone and going back to WM. Nothing personal.

On Dec 7, 1:07 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> Thanks for your feedback.
>
> I think that the issue has been acknowledged already, multiple times,
> as recently as 2 hours ago.
>
> At this point all I can promise is that this issue will get fixed when
> it gets high enough on someone's priority list for them to spend the
> time designing a solution and getting it discussed, writing the code,
> getting it verified, approved, and submitted.
>
> Apps on SD card isn't an end in itself. It's only a means to an end:
> the real goal is to not run out of storage space on the SD card. You
> mentioned that you were having issues because you have 17MB of email
> data on your internal storage. Being able to install apps on the SD
> card isn't going to help with this, the real solution is to either
> store that mail somewhere else, or to have the email app discard it
> when space is needed.
>
> In a way, every issue will be fixed "as soon as possible". There are
> just so many issues that it's not possible to fix them all right now,
> they've got to be prioritized, and the top of the priority list is
> what's been communicated on the roadmap. Making hard commitments
> beyond that would reduce the ability to adapt to changing conditions
> in a short time, so you need to expect the future to remain vague
> beyond a couple of quarters.
>
> JBQ
>

[al74]

By the way, I just realized, issues or no issues, one thing that I
could never do when I used WM, Blackberry or Symbian devices is access
and discuss issues with the developers of the operating system. This
just shows how remarkable this OS is. Thank you all team members of
this platform. Whining or not, I am very much grateful for the
opportunity to interact with you.

[Dave Johnson]

I need support for xvid, ogg theora video codec idroidn the media players... I think Android should format the sd card upon insertion.. with (format card? Y / n) dialog. Like the Sony PSP.

On Dec 7, 2008 3:19 PM, "al74" <aviad...@gmail.com> wrote:


By the way, I just realized, issues or no issues, one thing that I
could never do when I used WM, Blackberry or Symbian devices is access
and discuss issues with the developers of the operating system. This
just shows how remarkable this OS is. Thank you all team members of
this platform. Whining or not, I am very much grateful for the
opportunity to interact with you.

On Dec 7, 1:37 pm, al74 <aviadle...@gmail.com> wrote: > Thanks. I appreciate your honesty and I und...

[ericwong]

Well, since we believe that the Android team knew this problem before
the G1 is even sold to the end user.

I would say the quickest and easiest solution was to simply increase
the internal flash to 1GB or larger, before G1 enter production. This
would buy the user a LOT of TIME before Android team can find an
alternative at the small expense of slightly higher price.

Even right NOW, I imagine it is still a viable option to simply
increase the internal flash for the new G1s that are coming off the
production line. If nothing can be done in the short term on Android
itself.

Cheers
Eric
Portable Electronics Ltd
www.hdmp4.com

[Dirk Jäckel]

On Nov 24, 4:17 pm, Chris <aar...@gmail.com> wrote:
> I think the one over-arching point you are missing here is that Android
> isn't intended to be a one-phone OS. The future limitations of the current
> Android feature-set really sit in the hands of the hardware manufacturer. It
> would be a mistake to assume that just because your experience with the G1
> is dissatisfactory, your experience with a phone running Android is always
> going to be that way moving forward. If an Android device were released
> tomorrow that had 8 gigs of internal storage, this would be a non-issue on
> said device. That is why I doubt that this missing feature is the marketing
> disaster you claim it is.
>

I really regret now having ordered an "Android Dev Phone 1".

Regards,
Dirk

[Ian Copp]

> If an Android device were released
> tomorrow that had 8 gigs of internal storage, this would be a non-issue on
> said device.

... right up until you use up those 8 gigs of internal storage, which
I don't see as a matter of impossibility given the sort of things that
have started blooming on the iPhone (full 3d games, band-specific
music applications, and so on)/

[Disconnect]

http://www.gotontheinter.net/content/oooh-hidden-gem-cupcake-sources

Forseeable? Yes. Near? Probably not that close. (But that partially depends on how much external support the google guys get as far as implementing it.)

[Disconnect]

Dunno, have you submitted any patches for it?
(Hint: the message you replied to was almost exactly a year old. There was a much more recent discussion, but - as often happens - it got 75% of the way to the first bare requirements list and everyone kinda wandered away.)

If its required for a vendor device, maybe you should ask the vendor about it.. (Alternately, see if you can talk google into releasing vaguely up to date sources - eg the 2.1 prereleases - and I'm sure any number of people, myself included, will be happy to take a look and see what they've done.)

On Tue, Dec 15, 2009 at 9:59 PM, Robin Bjorklin <robin.b...@gmail.com> wrote:

How's the App on SD feature coming along? It will indeed be needed on
the brand new Samsung Spica released last week.

[lbcoder]

Everyone except me.
Though free time has been pretty tight (bought a slum and am turning
it into a house), I have been thinking about it and working on it a
little from time to time. Not a lot of progress (i.e. enough to bother
sharing) yet.

On Dec 16, 9:43 am, Disconnect <dc.disconn...@gmail.com> wrote:
> Dunno, have you submitted any patches for it?
> (Hint: the message you replied to was almost exactly a year old. There was a
> much more recent discussion, but - as often happens - it got 75% of the way
> to the first bare requirements list and everyone kinda wandered away.)
>
> If its required for a vendor device, maybe you should ask the vendor about
> it.. (Alternately, see if you can talk google into releasing vaguely up to
> date sources - eg the 2.1 prereleases - and I'm sure any number of people,
> myself included, will be happy to take a look and see what they've done.)
>