The update can be mandatory; so far (AFAIK) none have been, but that doesn't make the requirement go away.
On Fri, Aug 14, 2009 at 11:44 AM, lbcoder <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
