Live Wallpapers, Launcher2 in 2.1 r1, r2. Forward focus of AOSP

40 views
Skip to first unread message

A.C.

unread,
Apr 15, 2010, 3:05:49 AM4/15/10
to android-platform
I noticed that two features that worked on the original release of
eclair 2.1 are no longer working when building on rev 1 and 2 for the
HTC Dream. I looked through the code changes and couldn't find any
reason that required the break in compatibility, as both apps still
rely on libRS and librs_jni to work. Was this a deliberate move to
break compatibility with the Dream's (and other older devices')
kernel? The same thing had happened with Camera before.
There are currently work paths for msm7k and qsd8k devices, but now
that the focus is being shifted to qsd8k, what's to prevent the old
path be preserved as was for legacy? And why is it that patches that
have been submitted to restore compatibility (unobstructively) take so
long to get approval, things as simple as restoring buildability for
mdpi devices as including appropriate art are being ignored and
without a cohesive, fixed and ready to build source for all devices,
then it further drives AOSP to fragmentation (if we want a working
build, we have to fork).

Romain Guy

unread,
Apr 15, 2010, 3:12:10 AM4/15/10
to android-...@googlegroups.com
RenderScript-based features were never intended for use on an HTC
Dream. HTC Dream-class devices should use the original Launcher and
not Launcher2. FroYo brings Launcher2 to HTC Dream/Sapphire class
devices but turns off 3D all apps in that case, and live wallpapers
are not available by default.

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

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

Romain Guy

unread,
Apr 15, 2010, 3:12:56 AM4/15/10
to android-...@googlegroups.com
> RenderScript-based features were never intended for use on an HTC
> Dream.

In their current form. RenderScript is currently a private API and
thus does not need to be supported across all devices.

Nick Smith

unread,
Apr 19, 2010, 6:08:23 PM4/19/10
to android-platform
Hi Romain,

What is the minimum amount of RAM that Eclair or FroYo can run on? We
currently have 256 MB of RAM available but Qualcomm is claiming that
this is not sufficient. It sounds like you are saying the G1 is
capable of acceptable performance with only 192 MB of RAM.

Of course, that is assuming we disable Live Wallpaper support as well.

Thanks,

Nick

Dianne Hackborn

unread,
Apr 19, 2010, 6:14:03 PM4/19/10
to android-...@googlegroups.com
256MB may/should be fine (that is what is in Droid), though these things get really complicated because different chipsets may reserve a big chunk of that RAM for the radio and other stuff, so "how much RAM" is not something I would feel comfortable making a guarantee about.

The G1 and myTouch with 192MB of RAM (of which less than 100MB is available to the kernel -- that chipset stuff) was on the edge for Donut.  I would strongly recommend not building a device with that little RAM.  If you had that same hardware, with 256MB total RAM, I think you would be in okay shape for Eclair (though again, no guarantees).
--
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.

Nick Smith

unread,
Apr 20, 2010, 12:46:24 PM4/20/10
to android-platform
Dianne,

Thanks for the advice. I understand it is totally different from
device to device since the modem can take a big chunk out of the RAM.

Nick
> > android-platfo...@googlegroups.com<android-platform%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@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.
>
> --
> 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 athttp://groups.google.com/group/android-platform?hl=en.

a genius

unread,
Apr 21, 2010, 1:06:09 PM4/21/10
to android-platform
There is a bunch of speculation and misinformation in here that I
don't like.

First off, 32B devices (HTC DREAM, HTC MAGIC) with 192 MB ram run
elaire just fine. I'm doing so right now. The RAM requirements really
haven't changed all that much.... unless you do something a bit crazy,
like run launcher2 (which has other very ugly side effects besides
just hogging RAM). Note: with elaire on the DREAM, you can still run
big, memory hungry applications, like COPILOT without any problems.

ESPECIALLY it is fine if you run a little bit of COMPCACHE.
OR, if you don't need 3D, do a search for the "10 MB RAM HACK", which
takes a bunch of memory otherwise allocated to the GPU to bump up the
memory available to the kernel.

Now all that aside, it is quite pathetic how much memory is sucked up
by the baseband CPU and media junk on these devices. The only
explanation is that the developers (HTC) have NO IDEA how to write
efficient code. There is no excuse for there to be 94 MB drained by
this stuff. Even if you discount the GPU waste. IMO, this stuff should
not be using more than 8 MB. 16 would be sloppy. Add 20 MB on for the
GPU, and you have 36 MB SLOPPY, which should leave 156 for the kernel,
and THAT would be TONS.

In fact, that would be TOO MUCH.
The way that processes run on android, more memory means more running
processes, which means that the overall experience will be slower.
Processes get killed as new foreground processes need more memory than
what is currently available.

Dianne Hackborn

unread,
Apr 21, 2010, 1:59:24 PM4/21/10
to android-...@googlegroups.com
Sorry but I need to respond to this.

First, as per my response to the original poster, I very strongly recommend building devices today that have more available memory than the G1 or myTouch.  As I said, talking about total RAM is difficult in the face of different designs where things like the baseband running on its CPU may need to take a big chunk of memory.  But I strongly recommend ending up with a device that has well over 100MB available to the kernel, and at least 128MB.

Even total RAM available to the kernel is a tricky metric, because RAM can be allocated different ways.  For example on the myTouch and G1 all display surface memory (I think 16MB) is outside of the kernel address space.  However, on the Droid this is managed by the kernel.  If you have the latter kind of device, you'll want to have more RAM available to the kernel (though the total overall RAM can be the same, all other things being equal).

Further, things like the camera can have a big impact on memory requirements.  Going from a 3 megapixel to 8 megapixel camera greatly increases the amount of RAM needed, and if you have dedicated non-kernel RAM for display surfaces you will need to increase the amount that is reserved for it.

I guess at the end of the day my strong suggestion is: if you don't have a good idea of how much RAM you need, be conservative and use an amount that is sure to work.  Once you build that device and have an idea of how the parts are working, you could look at cost-reducing if you see that it could work well with less RAM.  But if you end up stuck with less RAM than is needed for everything to work well, you are going to be in a really bad spot.

As far as the myTouch and G1 having enough RAM...  I'll say again, they are teetering on the edge.  In fact the vast majority of performance issues on those devices are directly related to struggling with the amount of available RAM.  You can make all the claims you want, but I assure you I have looked at enough devices with performance issues to state that RAM is the #1 culprit.  Some of the performance issues that this causes:

- Going home is slow, because while in another app the system had to kill home's process to get more memory.  This is typically seen when using the browser, because you happened to view a page that needed enough memory to force home to be killed.

- Too much stuff going on in the background causes thrashing through services.  Unfortunately it only requires one or two bad apps to push you into this state, if they leave their services running.  This is actually what drove the introduction of the Running Services UI, when we were finding this to be one of the big culprits of poor performance on devices.  If these devices had more RAM, we probably wouldn't have done the UI at this point because the issue just doesn't come up much when there is more RAM available.

- There is only enough RAM to have a couple background services running, so if you ask for more (such as doing music playback while running navigation) you are going to be in trouble.  In fact on these devices I think if you have navigation running you basically aren't going to be able to sync data during that time since there isn't enough RAM to run the background sync services.

Finally, as for your comment "more memory means more running processes, which means that the overall experience will be slower" -- sorry, but that is just baloney.  156 MB for the kernel would be utterly fine, and I guarantee you would end up with a device that runs much better than one with 100MB.  Processes running in the background don't cause the device to slow down, within any kind of reason.  If you start having 20 processes sitting around you might see a little impact, but that will probably still be well outweighed by the fact that almost all of your switching between apps will just require moving to an already available process whose UI is already attached and ready to be drawn.


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.

Lo Yuk Fai

unread,
Apr 22, 2010, 9:24:12 AM4/22/10
to android-platform
I'm no coder, but after some observation, it does seem to me that the
32B is a bit short on RAM for Android, not just for 2.x, but also for
1.x. Although it seems more pronounced in 2.x.

Yes, one may use those hacks like ramzswap, linux-swap and/or the
10MB, but they're not without their problems, and probably won't make
it into an official release anytime soon, if ever.

Besides, we should probably be blaming Qualcomm instead of HTC, for
those missing RAM, *if* we are going down that route.

So it's fine if you would like to run 2.x on them, or any other
similar memory-constrained devices - Just root it and load the custom
ROM of your favour. But officially...?

I do think Android is under-performing, when compared to other
platforms, on similar hardware. But heck, Google I/O is just a month
away, and maybe the Android team will surprise us all soon.

Cheers.
> > > > > android-platfo...@googlegroups.com<android-platform%2Bunsubscrib e...@googlegroups.com>
> > <android-platform%2Bunsu...@googlegroups.com<android-platform%252Bunsub scr...@googlegroups.com>
>
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/android-platform?hl=en.
>
> > > > --
> > > > Dianne Hackborn
> > > > Android framework engineer
> > > > hack...@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.
>
> > > > --
> > > > 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<android-platform%2Bunsubscrib e...@googlegroups.com>
> > .
> > > > For more options, visit this group athttp://
> > groups.google.com/group/android-platform?hl=en.
>
> > > --
> > > 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<android-platform%2Bunsubscrib e...@googlegroups.com>
> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/android-platform?hl=en.
>
> > --
> > 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<android-platform%2Bunsubscrib e...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework ...
>
> read more »

Lo Yuk Fai

unread,
Apr 22, 2010, 9:30:15 AM4/22/10
to android-platform
To clarify, I meant we shouldn't expect every bell and whistle of 2.x
(e.g. Live Wallpaper) makes it to those memory-constrained devices on
an official ROM.

But a stripped down 2.x...? Yes, I hope Google will make it possible.

Armando Ceniceros

unread,
Apr 22, 2010, 10:46:43 AM4/22/10
to android-platform
By this point everybody and their canine knows 2.2 will be announced
at Google i/o and that a stripped down version will be made for
dream/sapphire (rumors put it on the magic, but that can easily be
ported to sapphire, plus a stripped down version has been implied).
Also, everybody who's looking knows that now google will avoid
releasing sources before it ships on devices to prevent the
embarrassments with donut and eclair having unnoficial versions
running beating any device releases.
Reply all
Reply to author
Forward
0 new messages