Will be Donut (Android 2.0) available to ADP1/G1

[vendor.net]

Hi,

I hear rumors that the new major version of Android - Donut may not be
available for ADP1/G1. Is that true?

Thanks!

[Dave Sparks]

I don't believe that has been decided yet, and ultimately it will be a
decision made in conjunction with the carrier. It is even possible
that some carriers may want the update and others won't.

There will come a time in the near future when we won't be able to fit
the latest release on the G1 internal flash.

[Andreas Kostyrka]

Cool, the phone is available in some markets way less than half a year and already it's end of life for it.

Anyway, not sure if it's so cool for the platform, fragmenting it so fast, OTOH the public certainly does not know the sell figures for the G1, although I'd guess it's the most common hardware and will stay so for some time (e.g. I'm not sure what the upgrade path is for keyboard junkies like myself, the 1.5 onscreen kbd is certainly a poor substitute for a kbd).

Anyway, hopefully android 2.0 will stay compatible enough that the community can continue to provide an image, even if it will require a sdcard for part of the os.

Andreas

[Bruce]

I think it can't be true because G1 is the only GPhone now...
Lots' of the fans have G1....

Google can't do that. :^)

[gunnar-medial]

> 6. Jun 2009 7:52 nachm. schrieb am "Dave Sparks" <davidspa...@android.com>:
>
.

> There will come a time in the near future when we won't be able to fit
> the latest release on the G1 internal flash.

.
I hope Google come up with a solution for prolonging ADP1/G1 usability
once you hit the ceiling.
Perhaps stuff can be swapped in from the memory card or a similar OS
solution.
By that time an ADP2 could exist as well one can assume.

[Jean-Baptiste Queru]

ADP1 is not such an acute concern as it's not pre-optimized, so
there's a lot more space available on /system (the flip side is that
an upgrade can require to wipe /data, which is not acceptable on the
G1).

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, 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.

[Nedjalko Milenkov]

Maybe you can make some tool to backup the info and then to wipe->install->restore from backup which could be on the sd card and so on..?

P.S. Please don`t tell us that ADP1/G1 will not be compatible with Android 2.0. Even Apple supports their all 3 types of phones. I know, you are not Apple, but the G1 life cycle in some countries is less than 6 months...

[Jean-Baptiste Queru]

Just to set the record straight, there are currently no official
version numbers for future versions of Android, so let's please not
call anything "2.0" as nobody knows what that refers to.

If the data doesn't fit on /data, no amount of backup/restore will
make it fit. It just doesn't fit.

JBQ

[Romain Guy]

> P.S. Please don`t tell us that ADP1/G1 will not be compatible with Android
> 2.0. Even Apple supports their all 3 types of phones. I know, you are not
> Apple, but the G1 life cycle in some countries is less than 6 months...

First of all there is no such thing as Android 2.0. Donut is Donut,
that's all. Then we never said Donut would not be supported on ADP1 or
G1.

--
Romain Guy
Android framework engineer
roma...@android.com

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

[Nedjalko Milenkov]

I thought that Donut is Android 2. So if it not. Which version is Donut and will be there Android 2 or it will be called Donut?

Glad to hear that you didn`t cut the ADP1/G1 from the road map :)

Thanks!

[Romain Guy]

Donut is not Android 2.0. Donut is Donut, it has no version number yet
and there's no Android 2.0 until one is announced.

[Mike Lockwood]

We don't know what android 2.0 will be. We are doing all our work by
pastry and someone on the marketing side makes up the version number
later :-)

Mike

--
Mike Lockwood
Google android team

[Jean-Baptiste Queru]

Right the only name to use is "Donut".

JBQ

[lbcoder]

There's nothing to decide.
If you want it, you are free to compile and install it yourself.

As for fitting... there's a lot more space available than you think;
1) The /cache partition is HUGE, close to 70MB. This is to accommodate
OTA updates. This can be shrunk down and /cache can be moved over to
the SDCARD -- really no reason it isn't already on the SDCARD.
2) /data partition could be made smaller if the option for installing
apps to SDCARD was made native. Really, just install the critical apps
onto the internal memory, put everything else onto the SDCARD.
Suddenly there's tons of left over space.

Fact is that right now /system is under 70 MB. It could be close to
200. Without shrinking /data (i.e., no issue with upgrading apps),
close to 140. Then to top it off, as JBQ mentioned, there's
optimizations available.

[Disconnect]

Do you have SPL source code to make those changes in?

..yeah me either.

Do you see anything in the (4-6 month old) donut public tree that
shows signs of apps2sd support? Yeah, me either.

Do you have a proposal for OTA updates that allows for reliable (in
the real-world sense) updates without storing them on the device
first? Yeah, me either.

[Jean-Baptiste Queru]

The reason why /cache is used for OTA updates instead of the SD card
is that the SD card could be missing or full, and OTAs need to be
(much) more reliable than that. The code that makes that decision for
Google-Experience devices isn't open-source anyway, so there's little
point discussing it here.

Put an app on the SD card without further care in the system to deal
with the consequences, pull the SD card from the device without
powering off, and suddenly your device crashes. And that's only the
beginning. If you'd like to contribute in that area, you're going to
need to bulletproof your design - lots of people have thought about
that already, and lots of hard problems are already known that you'll
need to overcome. Start by reading the archives of this group (and
possibly android-framework as well), especially going back to the end
of last year if I remember correctly.

JBQ

--
Jean-Baptiste M. "JBQ" Queru

Software Engineer, Android Open-Source Project, Google.

[Dianne Hackborn]

Also I think the chance that we deliver an OTA update to existing devices that repartitions the flash storage as part of the update is...  very small.

--
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, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Anders Nilsson Plymoth]

Thanks for the clarifications.
How about manual non OTA updates? That should still be ok.

Anders

[Disconnect]

It could be done for ADP devices, since they have no OTA requirements..

(Also, total agreement; there is basically zero chance of resizing
anything useful - eg data - without a wipe. And thats ignoring the
chances of a brick. Could prolly put together a tethered method that
does a backup/restore but.. ugh.)

[Anders Nilsson Plymoth]

Could an operator release a manual update for the G1? Not optimal of course, but users who really care should be able to do it with appropriate instructions.

Anders

[Jean-Baptiste Queru]

At the technical level, that's possible.

Whether it makes business sense to do it (given the cost of technical
support) is an entirely different question. Seeing the difficulties
that people report in android-devphone-updating, supporting such a
process is obviously a genuine concern.

JBQ

[Andreas Kostyrka]

Actually, I'm not sure where the problem is to require a SD card for
upgrades. I know it's not okay for official Google releases, because I
think somebody mentioned that the OTA upgrading is part of contracts
with the network operators.

OTOH, an alternate "image provider" like JF should not have big
problems, right?

In practice, the big issue is that downloading stuff while flashing is
not so great, but reading stuff from SD card should be okay, most time.
(Well, guess there are people who think it's essential to pull the SD
card for the photos while the mobile is upgrading itself.)

Andreas

[lbcoder]

Thats some screwed up priorities if updates are more important than
the ability to actually install the update due to limited space...

And last I checked, android is pretty graceful about application data
suddenly being unavailable. It certainly isn't a big deal to add a few
checks on unmounting the media, i.e., that there are no open file
handles in that filesystem. Last I checked though, this is already
handled by the kernel. Ever try unmounting a filesystem with open file
handles? It doesn't let you.

Oh, and pulling the sdcard without unmounting (forget about powering
off, that's irrelevant), even if there are no apps installed to it,
should never be expected to be graceful. It can be expected to crash
whatever program might be holding open file handled, which is, of
course, the reason why filesystems must be unmounted.


As it stands, if you have apps installed to the SD card (unofficial
hack -- using unionfs/aufs), and you suddenly make that device
unavailable, you are guaranteed that launcher will crash, as well as
any apps running from the SD. The apps running from the SD will
disappear, launcher will restart. Android keeps on ticking. Note:
using the old symlink hack, result will be much more disastrous. Want
to make this more stable? Add native support for proper filesystems on
the sdcard, make additions to allow apps, app-data, and dalvik cache
(the three elements required by an installed app) to be stored in
multiple physical locations -- /data and some subdirectory within the
sdcard filesystem. Keep 2 separate app databases, 1 on the device and
1 on the sdcard. When the sdcard is mounted, open the sdcard database
and add to the launcher list. When the sdcard is unmounted (I mean via
the place in the menu where it says to unmount), kill any sdcard apps,
pull the apps from the sd-database from the launcher, unmount. If
that's done, the sdcard-apps won't crash since they're killed, and the
launcher won't crash. Simple.

I suspect that there really isn't much of a problem understanding
this, you just come up with the "we can't do it because we don't know
how" in order to hide the fact that the real reason is that you don't
want apps to leave the protection of the internal storage (in terms of
piracy). Well feel free to keep the protected apps internal -- let
unprotected apps install to sdcard. I find it really funny that with
my old palm treo (palmos5), I could physically rip out the sdcard even
with, say, tomtom running from it, and it wouldn't so much as
hiccup...


Now since this discussion is strongly related to extending the
usefulness of the device beyond designed support, it must be noted
that some of the silly limitations, such as the division of the
storage space as defined in the SPL, can be dealt with withOUT messing
with the SPL. I should point out that the SPL *has been hacked* for a
more sensible division of internal storage (http://andblogs.net/
2009/05/new-spl/) A word of caution though, there have been a number
of people "brick" their device from it due to limited IPL
compatibility (only the latest works). Alternatively, an approach like
LVM can be used to combine and re-divide the space, OR EVEN just
spreading the data out over the 3 large partitions and symlinking as
required.

[Jean-Baptiste Queru]

You really should read the archives on that subject, and you really
should adjust your design constraints, as average joe user *does*
expect things to more graceful than what you're mentioning ("launcher
crashes and comes back" is not graceful enough).

Your so-called "simple" approach should be re-qualified as
"simplistic". You haven't thought it all the way through. There's e.g.
a gaping design hole in your approach that puts an app database
directly on the SD card. Since obviously you're so much smarter than
everybody else to the point where you feel the need to insult the
people who'll be reviewing your contributions, you already know what
it is, so I don't need to spend my time pointing that issue to you.

JBQ

[Disconnect]

Just to point out the obvious, since you are mislabeling my post..
that spl is not "hacked for different partition sizes". It is off a
different device, which has MORE STORAGE. It happens that it adapts to
the smaller overall size by reducing /cache but that is an unintended
side-effect.

[Sirus20x6]

um seriously how much space do we get with our gmail accounts? online
backup sounds like the perect answer. sure it will take a while but
google just announced that new dif engine or chrome updates. why not
do something like that for our phones?

have the phones send a small difff of changes to gmail maybe once a
day or so. make an update trigger another one right before the
download. wipe, update, restore

[Jean-Baptiste Queru]

Before we discuss this much further, I guess it'd be good to have a
proof of concept so that the size efficiency/cost of such a method can
actually be evaluated (just save the backups to SD instead of OTA). At
the same time, you probably want to look in deeper detail at the way
you'll do the "final" backup, since in first approach there seems to
be a race condition between doing that backup and applications
continuing to modify their files.

Yet, that's an orthogonal issue from the size of /cache - shrinking it
on production G1s/dreams still requires to reflash the bootloader,
which is extremely unlikely on its own, and I'm not quite convinced
that there's any space to gain in /cache - add the size of a
non-incremental update to that of a large market app and you'll see
that it's actually sized just about right for the G1. Anyway, that
part of the discussion is only loosely related to the core platform
itself, and would probably belong better on the android-porting list
where people actually need to make decisions about the sizes of their
partitions.

JBQ

[wimbet]

I was reading this old thread I had fav'd and never saw an answer.
Was cupcake the last update for the G1? I know it barely fit in the
system partition. I'm curious if Donut is over the limit. My guess
is yes.

[Jean-Baptiste Queru]

I don't think that anybody on this list can precisely answer your
question at the moment. Size remains a constant concern, not just for
the G1 but also for other devices.

JBQ

[wimbet]

Thank you for the response. I understand it is not the decision of
anyone on these boards. Based on all the information I have, I'm just
going to assume no updates till I hear something different.

[Jean-Baptiste Queru]

That's a wise way to avoid being disappointed.

JBQ

[Chad]

Now, if we had all just been thinking that about Duke Nukem Forever,
we wouldn't have been disappointed so many times over the years ;-)

-Chad

[motoxtremo]

I know that this is the Thread for the G1, but hows about the G2/Hero?
Is the System Partition bigger then the G1 Partition? I really want a
Hero, but if i cant install Eclair or Flan (i think Donut should be
possible) i would wait for a later Model...

[Jean-Baptiste Queru]

I don't have any visibility over the Hero.

I believe that the Magic (as shipping with Vodafone) / MyTouch (as
shipping with T-Mobile US) has approximately 90MB for the system
partition, up from 70MB in the G1, and the difference is significant.

JBQ

[motoxtremo]

I bought a Hero and checked the Size of the System Partition, its
170MB large!

On 15 Aug., 00:35, Jean-Baptiste Queru <j...@android.com> wrote:
> I don't have any visibility over the Hero.
>
> I believe that the Magic (as shipping with Vodafone) / MyTouch (as
> shipping with T-Mobile US) has approximately 90MB for the system

> partition, up from 70MB in theG1, and the difference is significant.

>
> JBQ
>
> On Fri, Aug 14, 2009 at 3:07 PM,
>
>
>

> motoxtremo<tobias.metzsc...@googlemail.com> wrote:
>
> > I know that this is the Thread for theG1, but hows about the G2/Hero?
> > Is the System Partition bigger then theG1Partition? I really want a
> > Hero, but if i cant install Eclair or Flan (i thinkDonutshould be

> > possible) i would wait for a later Model...
>
> > On 14 Aug., 21:14, Chad <innocentkil...@gmail.com> wrote:
> >> Now, if we had all just been thinking that about Duke Nukem Forever,
> >> we wouldn't have been disappointed so many times over the years ;-)
>
> >> -Chad
>
> >> On Fri, Aug 14, 2009 at 2:12 PM, Jean-Baptiste Queru<j...@android.com> wrote:
>
> >> > That's a wise way to avoid being disappointed.
>
> >> > JBQ
>
> >> > On Fri, Aug 14, 2009 at 11:07 AM, wimbet<wim...@gmail.com> wrote:
>
> >> >> Thank you for the response.  I understand it is not the decision of
> >> >> anyone on these boards.  Based on all the information I have, I'm just
> >> >> going to assume no updates till I hear something different.
>
> >> >> On Aug 14, 6:22 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>> I don't think that anybody on this list can precisely answer your
> >> >>> question at the moment. Size remains a constant concern, not just for

> >> >>> theG1but also for other devices.

>
> >> >>> JBQ
>
> >> >>> On Fri, Aug 14, 2009 at 12:50 AM, wimbet<wim...@gmail.com> wrote:
>
> >> >>> > I was reading this old thread I had fav'd and never saw an answer.

> >> >>> > Was cupcake the last update for theG1?  I know it barely fit in the
> >> >>> > system partition.  I'm curious ifDonutis over the limit.  My guess

> >> >>> > is yes.
>
> >> >>> > On Jul 19, 10:49 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >>> >> Before we discuss this much further, I guess it'd be good to have a
> >> >>> >> proof of concept so that the size efficiency/cost of such a method can
> >> >>> >> actually be evaluated (just save the backups to SD instead of OTA). At
> >> >>> >> the same time, you probably want to look in deeper detail at the way
> >> >>> >> you'll do the "final" backup, since in first approach there seems to
> >> >>> >> be a race condition between doing that backup and applications
> >> >>> >> continuing to modify their files.
>
> >> >>> >> Yet, that's an orthogonal issue from the size of /cache - shrinking it
> >> >>> >> on production G1s/dreams still requires to reflash the bootloader,
> >> >>> >> which is extremely unlikely on its own, and I'm not quite convinced
> >> >>> >> that there's any space to gain in /cache - add the size of a
> >> >>> >> non-incremental update to that of a large market app and you'll see

> >> >>> >> that it's actually sized just about right for theG1. Anyway, that

> >> >>> >> >> > the latest release on theG1internal flash.

>
> >> >>> >> >> > On May 30, 10:17 am, "vendor.net" <vendor....@gmail.com> wrote:
>
> >> >>> >> >> > > Hi,
>

> >> >>> >> >> > > I hear rumors that the new major version of Android -Donutmay not be