What if the SD card filesystem becomes corrupted? Or someone installs an app on one SD card that is dependent on another app/library installed on another card?
I'd love apps on SD too lbcoder, but I'm still not convinced it should be rushed out the door prematurely. On Fri, Aug 14, 2009 at 6:01 PM, lbcoder<[email protected]> wrote: > > So put up a message... update not taken due to insufficient space or > unavailable sdcard. Free up some space on or insert the sdcard. If you > haven't taken the update by (some date), functionality will be reduced > to making phone calls only. > > This is not complicated. Yes, all the side effects have to be taken > into account, but EVERY SINGLE ONE can be dealt with in some simple > manner. It is just a matter of sitting down and thinking about it. The > current policy of "we don't know how to do it so we won't even think > about it" is a load of horse crap. > > The first important thing is that getting the cache off the internal > is the EASIEST way to make more space available. The side effects are > NEGLIGIBLE. Repartitioning or not doesn't really matter, if TPTB are > too scared to repartition devices in the wild, then don't, but simply > start shoving data into /cache, i.e. instead of mounting /dev/block/ > mtdblock4 at /cache, maybe mount it at /system/app, or /system/lib and > symlink /cache --> /data/cache. > > > On Aug 14, 11:50 am, Disconnect <[email protected]> wrote: >> 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 -~----------~----~----~----~------~----~------~--~---
