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