There's no risk if the procedure is correct.
And as for the reliability of sdcard being available and having enough
space; that's a B.S. excuse for doing nothing and I'll tell you why:
if (sdcard mounted && sdcard enough space available){
do stuff;
} else {
do nothing;
}
On Aug 13, 12:52 pm, Jean-Baptiste Queru <[email protected]> wrote:
> One point is that repartitioning "live" devices is not an option
> anyway, it's far too risky.
>
> Also, there's no guarantee that users will have an SD card in the
> system, or that it'll be mounted, or that there'll be space on it, so
> it's not a reliable enough solution.
>
> JBQ
>
>
>
> On Thu, Aug 13, 2009 at 9:35 AM, lbcoder<[email protected]> wrote:
>
> > ... unless you divide the system up into smarter chunks. *IF* you
> > updated to allow apps to be installed to SD, that opens up quite a big
> > chunk of internal storage space for the system.
>
> > Then of course, there is again that big wasted chunk of /cache.... why
> > again was it that you don't allow OTA updates to be cached to the
> > sdcard instead of internal memory?
>
> > To translate: Dream has 256 MB of internal space. Of this, 67.5 are
> > available to the system, 74.8 to /data, and 67.5 are (mostly) a
> > complete waste sitting in /cache waiting for OTAs.
>
> > Might be better to redistribute as such: /data: 50 (or even less...
> > 25?) + apps-go-on-sdcard, /system: 159.8, /cache-->/sdcard/cache or in
> > the least, drop the size of /cache down to something more sensible and
> > keep the OTAs on the sdcard.
>
> > To consider: OTA update files (update.zip) can *already* be installed
> > from sdcard using recovery mode.
>
> > Now implementation, a challenge, of course...
> > Changing the partitioning in the SPL breaks the data on the internal
> > memory, so this would require a 2-stage update and some free space on
> > the SDCARD. Move *all of* /data to sdcard, update the SPL to one that
> > will boot a recovery.img off the SDCARD and put a recovery.img on the
> > SDCARD that will apply /sdcard/update.zip without asking questions and
> > then moving certain components from the sdcard BACK to the internal
> > memory (not the apps), and then finally, of course, by deleting
> > itself.
>
> > I think that should fix all the space limitations for the next few
> > years.
>
> > Are you interested in hiring an engineer to implement this? I would be
> > happy to volunteer my services if the pay is right.
>
> > On Aug 13, 12:13 pm, Jean-Baptiste Queru <[email protected]> wrote:
> >> This is a bit of a no-win situation:
>
> >> (1) we could stop upgrading "small" devices altogether.
>
> >> (2) we could restrict the entire platform to features that will fit on
> >> the smallest devices.
>
> >> (3) we could maintain different feature sets for different devices,
> >> such that e.g. the smallest devices could receive updates to the core
> >> platform but no new major features.
>
> >> Neither of those is a great option: (1) penalizes the early adopters,
> >> (2) penalizes the entire ecosystem by making the latest phones less
> >> competitive, (3) penalizes the early adopters less than (1) but adds
> >> quite some engineering cost to maintain the parallel variants.
>
> >> Where the situation is really tricky is that the system partition on
> >> the US G1 was already filled to the brim with cupcake, and we were
> >> routinely flirting with build sizes that were a few dozen kB under the
> >> limit (or several MB over...), which means that even small changes to
> >> the core platform could very easily push the system size over the
> >> limit and staying under the limit took some effort.
>
> >> JBQ
>
> >> On Thu, Aug 13, 2009 at 8:51 AM, Fred Grott<[email protected]> wrote:
> >> > Romain,
>
> >> > The backward support of first gen devices via the firmware size limit,
> >> > will
> >> > that limit always be there as we go forward in Android version or do you
> >> > see
> >> > at some point firmware size limits being increased?
>
> >> > Thanks
>
> >> > Fred Grott
> >> >http://mobilebytes.wordpess.com
>
> >> > On Wed, Aug 12, 2009 at 12:00 PM, Romain Guy <[email protected]>
> >> > wrote:
>
> >> >> > OK, how about David Goldfarb's video ringtone support patches? He
> >> >> > started working on those a long time ago. Originally the patches had
> >> >> > several issues with them, Google was quick to jump in and point out
> >> >> > what was wrong. He resolved the issues and submitted his patches again
> >> >> > (over a month ago). Once the patches lacked the issues pointed out,
> >> >> > what happens then? Nothing.
>
> >> >> David had long discussions directly with the media team and myself by
> >> >> email about his patch. Last time I checked his work the UI he was
> >> >> proposing was still not acceptable for inclusion in the platform.
>
> >> >> > It seems you don't understand. The entire ecosystem is being strangled
> >> >> > by this. It's not a nice to have feature. It seems like if someone
> >> >> > over there did understand, this would be a feature in Donut. If you've
> >> >> > starred the feature request in the bug database you'd understand how
> >> >> > angry people are about this. But I don't think anybody is even
> >> >> > notified when people post "Wow! I am getting way too much email from
> >> >> > having this issue starred, so I'm unstarring it".
>
> >> >> Wanting this feature does not mean we will add it at this point of the
> >> >> development process. The same applies to all of the features the core
> >> >> Android team would like to add and know would be enjoyed by many. In
> >> >> this particular case, and I talked briefly with the author about it,
> >> >> we also need to take into account the binary size of this feature (at
> >> >> least if you guys want the final build to fit on an HTC Dream/T-Mobile
> >> >> G1), the added dependency (new library) and the extra QA. This just
> >> >> cannot happen for Donut. We also need to see if it's something that
> >> >> makes sense to support in Android. Yes this issue was starred by 80
> >> >> people. But this number is (unfortunately) dwarfed by the number of
> >> >> users of Android and we need to question the fact whether this feature
> >> >> would be used by enough people to warrant its inclusion. That's true
> >> >> of all features we include. Now in this particular case an Android
> >> >> engineer has been actively participating on the bug report and even
> >> >> took measure of the impact on batter life. Not having this feature in
> >> >> Donut is not a question of us ignoring it, it's just about the fact
> >> >> that it's too late in the development cycle. Period.
>
> >> >> > That's what you say.
> >> >> > Name one significant user visible feature that
> >> >> > has made its way from a non OHA member contributor from the public
> >> >> > repository into Donut in Google's private repo. Not a bugfix, or a
> >> >> > typo. Something visible to the user in the way that FLAC support or
> >> >> > Video Ringtones or something of that ilk would be. My point is, how
> >> >> > many contributions do you expect to receive when the worthy ones so
> >> >> > far are still unattended to?
>
> >> >> FLAC was too late and video ringtones were still not in good enough
> >> >> state. I just told you I am committed to accepting features and bug
> >> >> fixes from the community in specific areas. I cannot point you to
> >> >> features that have been merged in these areas if I don't receive
> >> >> patches in the first place. I would also be happy to discuss potential
> >> >> changes and their impact and relevance. Also please remember that
> >> >> because a feature, even if great, is submitted it does not mean it
> >> >> will make it into Android. There should be little reason for a feature
> >> >> to not make it but accept the fact that we cannot accept just *any*
> >> >> feature, especially considering some constraints we have to deal with
> >> >> (like the firmware size limit on 1st generation phones.)
>
> >> >> --
> >> >> Romain Guy
> >> >> Android framework engineer
> >> >> [email protected]
>
> >> >> 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
>
> >> --
> >> Jean-Baptiste M. "JBQ" Queru
> >> Software Engineer, Android Open-Source Project, Google.
>
> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.
>
> --
> Jean-Baptiste M. "JBQ" Queru
> Software Engineer, Android Open-Source Project, Google.
>
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
