Related
Our devices don't have very much flash memory and it's easy to fill up /data with apps but here is a quick solution that can give you a bit more space.
In /data is a directory called dalvik-cache, this is a cache of the classes.dex from every app on the device, including those in /system.
On most android devices this doesn't happen, the system applications and the framework are stored as optimised dex files with a .odex extension.
People have spent a lot of time figuring out how to recreate the apks from the odex files and this is good if you have enough space to put all your apps on the device twice because it allows them to be easily swapped for theming.
The attached script goes through each app and jar in /system, creates an odex file and deletes classes.dex. It will give you about 30M extra space on /data while making /system about 10% bigger.
To run it do the following:
Backup you device
Make sure you have at least 15% free on /system, this is important because if you run out of space things will go badly wrong.
unzip odex.zip and then do:
adb push odex /data/odex
adb shell /data/odex/odex.sh
Wait till it finishes and then reboot the phone.
Another reason for odexing is that it boots very quickly and when testing kernels its nice not to have to wait too long.
If you want to see a simple odexed system try this:
http://www.mediafire.com/download.php?qjyniynyqzz
Rename it to androidinstall.tar and it will give you the donut system in the attached screenshots.
The main disadvantage of odexing is that it means you can't change the theme without reinstalling /system so find a theme you like before doing this to your device.
Thanks to Paul O'Brien for writing the original script.
Have fun.
dzo, once again, Thank you.
This should provide ALOT more breathing room in Eclair and Sense builds. Not to mention more flexibility for ROM devs too.
Thanks!
so would this only be useful for people who are making roms and stuff like that I'm kinda a noob still sorry
Unfortunately with my eclair build, /system is almost full
App2SD or /data on sd card look better
but that's device dependant
thank you for the tip anyway
I was about to ask if this will mess up the zipaligning but then I looked a the script and it also does zipaligning.
jadenj5 said:
so would this only be useful for people who are making roms and stuff like that I'm kinda a noob still sorry
Click to expand...
Click to collapse
The end user could run it, too...
Any thoughts on adding this to the install menu? That way you could install system, apply themes, then odex.
I updated the system tar in the first post to fix the broken calendar. I've been running this on my primary phone for a few days now and it seems much faster than it was. Perhaps there's are fewer file accesses with an odexed system and it needs to keep less data in the fs cache. Whatever the reason, give it a try.
is there anyway to do this from the phone without adb?
Include in vogue tools?
Thanks DZO, great that more performance can be squeezed out of our aging devices!
Just a thought: Could this be included in Vogue tools?
Two strange things with this build (on a Kaiser and I've added Wifi so maybe that has to do with it?)
- It never sleeps, I haven't run any Donut build for very long but I think I had this issue when trying the Warm Donut once.
If I turn off the screen (or if it times out by itself) this shows up in /dev/kmsg:
stop_drawing_early_suspend: timeout waiting for userspace to stop drawing
- When I run GPS Test and use the time screen the updates are irregular and sometimes skips a couple of seconds and sometimes several updates comes quickle after each other (with less than a second between them). I actually spent some time debugging my GPS code before I tried on eclair and realized it was not the GPS code that was causing it.
Perhaps both issues are related. I've a panel 1 Kaiser.
Other than that it feels very quick and snappy but no sleeping is terrible for the battery life.
Oh, and I tried turning off both wifi and background transfer but that doesn't help.
Tried this on Incubus's Tattoo and it got to HTCCamera.apk and failed:
Code:
--- BEGIN 'HTCCamera.apk' (bootstrap=0) ---
--- would reduce privs here
--- waiting for verify+opt, pid=3751
--- END 'HTCCamera.apk' --- status=0xff00, process failed
Unable to create '/tmp.odex': File exists
rm: cannot remove '/data/dalvik-cache/*': No such file or directory
It repeated Unable to create '/tmp.odex': File exists but i removed them from the code above because it's not necessary to have them in there 9473975394 times.
I rebooted and reinstalled the system to be safe.
preardon said:
Tried this on Incubus's Tattoo and it got to HTCCamera.apk and failed:
Code:
--- BEGIN 'HTCCamera.apk' (bootstrap=0) ---
--- would reduce privs here
--- waiting for verify+opt, pid=3751
--- END 'HTCCamera.apk' --- status=0xff00, process failed
Unable to create '/tmp.odex': File exists
rm: cannot remove '/data/dalvik-cache/*': No such file or directory
It repeated Unable to create '/tmp.odex': File exists but i removed them from the code above because it's not necessary to have them in there 9473975394 times.
I rebooted and reinstalled the system to be safe.
Click to expand...
Click to collapse
it might have something to do with most of the apk's already being odexed
I've posted an odex:ed and zipaligned CM5.0.7 port here: http://forum.xda-developers.com/showthread.php?t=700669
It also odexes every app in /data/app on boot (and clears the dalvik cache).
great donut build!
Thanks Dzo, you managed to pull together a great, snappy no frills donut build! it is fantastic on my Kaiser - and it is only a by-product of yet another great contributions of your! Thanks!
how is this donut build for use?
thoughtlesskyle said:
how is this donut build for use?
Click to expand...
Click to collapse
Great, I am using it daily on my kaiser at the moment. I understand that Kalt_Kaffe had problems with sleeping and battery life, but it works fine for me.
yea i shouldnt have the sleep and battery life problems because i run a vogue and they do things a little differently.
i wish i wasnt changing builds like every other day anymore
this is an excellent vanilla donut build dzo. it's very responsive and stable running from my sd card on the vogue so far. i really like myn's warm donut rom but it would frequently lock up requiring a restart; not the case with this build. thanks.
edit: is it possible to run the odex script again considering that i've been funning this build on my sd card? i wanted to odex the additional apps i added since the first install. also, would i have to manually remove the odexed files after updating an apk?
Had this running for a day on my old Kaiser and it's nearly as fast as my Hero! Fantastic work! Thanks!
This is the "snapiest" android build I have run on my vogue.
loving it thus far.
I have been reading about "Fixing permissions" and I can see that ROM Manager on my Nook (running Phiremod v5.2 with CM7) has that function.
But what exactly does "Fixing permissions" mean?
When do I need to do that?
And what are the consequences?
Hope anyone can explain it to me - or guide me to a "ROM Manager/Fixing Permissions for Dummies"
http://en.wikipedia.org/wiki/Filesystem_permissions
Fixing Permissions does exactly what it says really. It fixes the file system access permission to the correct settings if for some reason they aren't set right which seems to happen from time to time. As far as I know there are no issues or consequences to running the script outside of wasting a few minutes while it runs since it's basically restoring things back to how they should of been.
Thanks for the reference and the answer.
Regarding the Nook, what interests me is why this is necessary from time to time. But maybe I shouldn't think about it too much
Caspar...as you add new apps or change ROMS, the filesystem permissions often get changed. sometimes they get changed to values that are detrimental(like a file getting set to read only when it needs to be writable). That's why the need for fixing the permissions.
If you don't do this, you sometimes end up with a scenario where an app expects to be able to write some information and can't. This generates an error, which if the app isn't able to handle it, crashes the app.
A well written app will have thought of this already, but most times developers just expect the proper permissions and don't add in error handling code, saving themselves work and the program some size.
There's been a lot of speculation on what can and can't be removed as well as how to remove them without causing force-closes, boot loops, and other headaches. So I wrote this script that will let you disable all of the bloat with none of the hassle.
After a few prompts to find out if there's anything you want to keep that can't be replaced in the market, it will do its magic -- renaming files to a .bak extension so they are no longer recognized by Android. This will cause some system services to fail and force-close loop until you reboot (and the script reboots for you). Also included is a script that will undo all of this.
If you select every option, including the default launcher and text messaging apps (which are confirmed safe to remove without losing SMS or MMS ability or push notifications), then here's the list of apps removed:
AdService.apk, android-syncservice-app.apk, ArcVideoEditorLite.apk, BackupAssistanceClient.apk, Blockbuster.apk, BlurHome2.apk, BlurSNMessagingEngine.apk, BlurTasks.apk, BlurUpdater_VZW.apk, BooksPhone.apk, CitrixReceiver.apk, CityID.apk, Conversations.apk, DLNA.apk, DlnaSystemService.apk, FriendFeed.apk, gotomeeting-stub-1.0.74.apk, GuidedTours.apk, HelpCenter.apk, IMPresence.apk, IndexingService.apk, Kindle.apk, MessagesWidget.apk, Messaging.apk, MOTOPRINT.apk, MSExchangeService.apk, MyVerizon.apk, NewBayVault_4.2.99.36.Market.apk, NFLMobile.apk, OnlineAlbum.apk, PhotoEditor.apk, PortalStandAlone.apk, Preloaded.apk, RichLocationVzW.apk, SkypeBourbon.apk, Slackerradio.apk, SocialMessaging.apk, SocialShare.apk, StatusWidget.apk, SuggestionsProvider.apk, SuggestionsRuleCheckerCore.apk, SuggestionsServiceScheduler.apk, Swype.apk, ToggleWidgets.apk, UniversalInbox.apk, Upgrader.apk, VCAST_TONES_4_5_7.apk, VCASTMusic.apk, VCASTVideo.apk, VSuiteApp.apk, vzw_vnav_DROID3_rel_PROD_signed.apk, VZWIM.apk, VZWInstaller.apk, WeatherWidget.apk, ZumoCast_1.0.17.apk
Make sure you run these scripts using Script Manager or a comparable app and be sure to enable it to run as root or it won't have permission to make changes to /system/app.
This is version 1 of the scripts -- if any of the apps removed wind up causing problems or more are found, I'll add it to the list. I've tested the scripts back and forth myself and have tested it as much as I can without finding any issues. Also, some apps are removed without asking, such as ZumoCast or VCAST or NFL Mobile. You can find these apps in the market, so there's no point keeping them locked down in system.
Enjoy! Comments are welcome.
UPDATE 9/1/2011: fixed a typo in one of the variables (thanks everyone who reported this), added more options to keep (Swype and Car Dock Voice Commands), split into two versions -- one for the stock 5.5.959 build and 5.6.890 update (late August OTA), added a warning about removing the home screen without a launcher and that it removes the Calendar widget.
Great, but maybe it would be nice to make a y/n option for each .apk where it asks you if you want to delete that apk
script
instructions for use?
thanks
DoubleYouPee said:
Great, but maybe it would be nice to make a y/n option for each .apk where it asks you if you want to delete that apk
Click to expand...
Click to collapse
You shouldn't delete them -- we don't have an SPF yet. Someone posted the complete /system/app contents and you could restore, technically, manually, but it's a bad idea. Renaming to a .bak is completely effective.
lodisax said:
instructions for use?
Click to expand...
Click to collapse
Read the post.
You'll want to use Script Manager -- unzip the two scripts to your SD card (internal or external), launch Script Manager (free version is fine), find the script and click it, then tick on 'root' and then run the script. Follow the prompts from there.
script
thanks for the answer
psouza4 said:
You shouldn't delete them -- we don't have an SPF yet. Someone posted the complete /system/app contents and you could restore, technically, manually, but it's a bad idea. Renaming to a .bak is completely effective.
Click to expand...
Click to collapse
Yeh sorry that's what I meant.. Option to y/n rename the apk.
I'd like to use the script once I get my droid 3 but would like to 'keep' some of the apks.
DoubleYouPee said:
Yeh sorry that's what I meant.. Option to y/n rename the apk.
I'd like to use the script once I get my droid 3 but would like to 'keep' some of the apks.
Click to expand...
Click to collapse
There's Y/N for anything you'd want to keep. About 6-7 questions in total. Anything that you can't find in the market that isn't definitely bloat has a prompt.
script
script manager that you use?
I use script manager and asked me if I want to remove each apk or not.
There is a script manager that does everything automatically?
thanks for the answer
lodisax said:
script manager that you use?
I use script manager and asked me if I want to remove each apk or not.
There is a script manager that does everything automatically?
thanks for the answer
Click to expand...
Click to collapse
Please read the thread thoroughly -- I'm going to ignore obvious questions like these.
psouza4 said:
There's Y/N for anything you'd want to keep. About 6-7 questions in total. Anything that you can't find in the market that isn't definitely bloat has a prompt.
Click to expand...
Click to collapse
So what if I wanna keep DLNA, photoeditor and socialmessaging?
DoubleYouPee said:
So what if I wanna keep DLNA, photoeditor and socialmessaging?
Click to expand...
Click to collapse
Then answer 'Y' to the prompts asking if you want to keep 'DLNA' or 'social messaging'. There are plenty of photo editors in the market, so there's no prompt on that (although if you were so inclined, you could just rename the .BAK's back to their original files). I feel you haven't actually looked at the script or read my post.
psouza4 said:
I've tested the scripts back and forth myself and have tested it as much as I can without finding any issues. Also, some apps are removed without asking, such as ZumoCast or VCAST or NFL Mobile.
Click to expand...
Click to collapse
I think the ultimate test is to do factory reset and see how device will go through initialization stage. It can be surprises which are not noticeable during normal use. Without this it is kind of premature to say what is safe to delete and what is not.
serg675 said:
I think the ultimate test is to do factory reset and see how device will go through initialization stage. It can be surprises which are not noticeable during normal use. Without this it is kind of premature to say what is safe to delete and what is not.
Click to expand...
Click to collapse
Ehh I agree with you to a point, because i made the very noobish mistake of uninstalling bloat that i knew would not effect daily use; however, I did a factory reset to test a theory for krazy and learned that something I uninstalled makes the setup process FC and wont let you get to the blur launcher, luckily other launchers work and I was able to batch install via adb.
Thing is though is if the phone reboots when this stuff is renamed then it will survive a factory reset, though it may do the same thing mine has done. If it does its no big deal to load up adb and rename the files back so that you can complete the setup.
You forgot the World Clock widget in your removal script; the only clock that thinks it needs a permanently-resident service, regardless of whether it's running or not.
Xenoproctologist said:
You forgot the World Clock widget in your removal script; the only clock that thinks it needs a permanently-resident service, regardless of whether it's running or not.
Click to expand...
Click to collapse
That messes with the dock though, so I don't consider it bloat.
I know its a lot to ask... but can someone either create a comprehensive list of what each one actually does... or point us in a direction to where there already is one?
Sent from my DROID3 using Tapatalk
Seirÿu said:
I know its a lot to ask... but can someone either create a comprehensive list of what each one actually does... or point us in a direction to where there already is one?
Click to expand...
Click to collapse
Open the script in a text editor and read my comments -- it gives each one a title.
@psouza4 - nice work, it's about time someone took a more organised approach to figuring out what apks are safe to remove.
I tried to get a similar effort going here :-
http://forum.xda-developers.com/showpost.php?p=17004394&postcount=11
but the way people behave on this forum, it's like trying to herd cats.
thingonaspring said:
@psouza4 - nice work, it's about time someone took a more organised approach to figuring out what apks are safe to remove.
I tried to get a similar effort going here :-
http://forum.xda-developers.com/showpost.php?p=17004394&postcount=11
but the way people behave on this forum, it's like trying to herd cats.
Click to expand...
Click to collapse
Thanks!
Couple of notes, too:
It was asked in IRC why I'm removing 'android-syncservice-app.apk'. This service is the extra backup stuff that Verizon added on (as evidenced inside the package in /assets/system.properties you'll find several references to verizon servers for sync, like sm_connection_url=http://syncba.myvzw.com/syncml). This service doesn't do anything beneficial for you unless you really have a hard-on for Verizon's sync stuff. I've had it disabled since we achieved root and it has no affect on account sync services (contacts, gmail, calendar, reader, etc.) nor SMS/MMS push notifications, etc.
Also, a fellow PM'd me saying he got errors that variable names were invalid -- turns out he had edited the script in Windows, saved it, and that broke the UNIX-style line endings. If you're going to modify the script, use Notepad++, UltraEdit, or something that will maintain the correct line endings. Or just use an editor on the phone, such as in Root Explorer.
Thanks a bunch man, works great. About to run a benchmark to see the results!
Hello Everyone,
So I unfroze all of my apps in Titanium Backup and flashed the OTA that is posted in the development forum for the Droid 3 and it seems to have worked great other than one small problem. Every time I try to use the camera or camcorder they will open for about 2-3 seconds and then they close and I end up back at my home screen. Does anyone have any ideas on what I can try to make my camera apps work again?
EDIT: Sorry, forgot to mention that I did try rebooting the phone as well as clearing the cache for the camera app, no change. Also Camera Zoom FX stays open but just has black where the camera image would normally be.
Thanks!
Maybe you... forgot to unfreeze the camera app lol.
No but id check what you do have frozen, maybe there's a service the camera app is dependent upon you might have accidentally frozen (assuming you rerooted after update)
Sent from my DROID3 using Tapatalk
I did re-root after applying the OTA update and then I froze about 15 apps that I found to be annoying/un-needed, however even after unfreezing all of them, any app involving the camera still isn't working. I also just noticed that my flashlight app that worked before the OTA is not working either.
First thing I would try is "clear data" for the Camera app and reboot.
rtbrjason said:
First thing I would try is "clear data" for the Camera app and reboot.
Click to expand...
Click to collapse
Tried that a couple of times but no change. I just also noticed that the camera app flashes a small message up at the bottom of the screen really quickly stating that the camera is unable to initialize.
Uninstall any third-party app that uses the camera (if you have any) the try again.
kishin14 said:
Uninstall any third-party app that uses the camera (if you have any) the try again.
Click to expand...
Click to collapse
Thank you for the suggestion, I hadn't thought of that. Unfortunately that did not work either. No change, still getting the same message for about a second or two and then it closes.
Try re-uploading the camera apk and odex files, might need to set permissions the same as the other system apps.
Unzip and use something like rootexplorer, delete current BlurCamera.apk and BlurCamera.odex, set write access on system/app folder then copy these.
-smc
The problem is the camera firmware, amongst other things, is first deleted and then replaced during the OTA update - if something happens, that firmware is never copied back causing the camera to fail.
The problem I had was too much stuff installed in /system and it simply ran out of space. This also caused my recovery to fail to update which then failed checksum if I tried to boot to recovery.
I had a bunch of binaries I installed in /system/xbin taking up several MB of space. I deleted them - including busybox - and reran the update. Now everything works fine.
If your recovery is hosed, I posted how to fix in the update thread.
If you need help and haven't wiped /cache yet, post /cache/recovery/last_log
limaxray said:
The problem is the camera firmware, amongst other things, is first deleted and then replaced during the OTA update - if something happens, that firmware is never copied back causing the camera to fail.
The problem I had was too much stuff installed in /system and it simply ran out of space. This also caused my recovery to fail to update which then failed checksum if I tried to boot to recovery.
I had a bunch of binaries I installed in /system/xbin taking up several MB of space. I deleted them - including busybox - and reran the update. Now everything works fine.
If your recovery is hosed, I posted how to fix in the update thread.
If you need help and haven't wiped /cache yet, post /cache/recovery/last_log
Click to expand...
Click to collapse
also, one note, i'm seeing alot of people reporting issues with the stock apps AFTER they've removed bloat (any method). the first thing people should do is put the bloat back, or in worse case scenario, do a wipe to see if there's really something wrong.
i froze an email service and it cause my text messenger to stop working. you don't know what libraries are shared with what. freeze with caution.
640k said:
also, one note, i'm seeing alot of people reporting issues with the stock apps AFTER they've removed bloat (any method). the first thing people should do is put the bloat back, or in worse case scenario, do a wipe to see if there's really something wrong.
i froze an email service and it cause my text messenger to stop working. you don't know what libraries are shared with what. freeze with caution.
Click to expand...
Click to collapse
I agree, and would suggest to anyone to use the script for removing and replacing the bloat - it makes it much easier to do (especially from adb when you foul it up) and keeps track of what you've done.
That said, I highly doubt that is the issue here. The update script first checksums everything that needs to be patched and deletes everything that is to be replaced. So if you have anything removed, it will either cause it to fail (if the file is to be patched) or not matter (if it is to be deleted or simply isn't touched). In other words, if you have anything missing that is needed, the update wouldn't touch anything.
Furthermore, I don't think any of the commonly removed bloatware serves as a dependency for the camera. At least not as far as I can tell.
I can tell you that /system is filled to the brim with all of the bloatware. The current ROM is just barely shoehorned in there. Many 'for-root-users' apps like to install stuff to /system and since the updater script doesn't check for free space, it may very well fail to extract in the middle of execution even though it already deleted a bunch of files.
So I think more importantly than restoring bloat, you should remove anything you added.
I tried your directions and re-ran the update after fixing recovery, however my camera still doesn't work because of the same basic issue, running out of space before the update completed. Upon re-rooting and going in to my system directory with root explorer I noticed that I now only have 195k free there. I checked the xbin folder and do not see busybox or anything else there that I recognize that I could delete to free up space. How can I tell what is safe to delete and what isn't so I can free up enough to fix my recovery again and hopefully get the update to work properly?
You can see a breakdown of disk usage with this command:
Code:
du -sh /system/*
Here's mine with busybox removed:
Code:
147.6M /system/app
7.5M /system/bin
11.0K /system/build.prop
5.5M /system/etc
5.1M /system/fonts
35.5M /system/framework
75.7M /system/lib
1.0K /system/lost+found
19.2M /system/media
0 /system/preinstall
304.0K /system/recovery-from-boot.p
4.6M /system/tts
8.3M /system/usr
135.0K /system/xbin
And my free space is
Code:
$ df /system
Filesystem Size Used Free Blksize
/system 320M 317M 2M 1024
Other than su, the only files you need in xbin are (don't worry about the symlinks)
Code:
backup dexdump drm1_func_test run_backup run_restore ssmgrd
I think the only extra bits I now have on /system is su.
I also found the system dump from this post to be very helpful.
Whenever I'm trying du It's saying that the command wasn't found. What are you using for your terminal access?
Hmm it seems du isn't a standard binary even though I have it in bin. I sure don't remember putting that in there...
Anyway, I use adb or Better Terminal Emulator Pro, depending what mood on in.
To use adb, you'll need to install busybox to /data somewhere (I have mine in /data/local/bin) and use
Code:
$ /data/local/bin/busybox du -sh /system/*
BTEP has a fairly complete set of CLI tools included - such as du - so you don't need busybox.
I figured out how to do the command through busybox and have come up with some interesting results...
I am over yours on...
Code:
153.8M /system/app
1.9M /system/xbin
I am under yours on...
Code:
4.7M /system/bin
4.9M /system/etc
71.8M /system/lib
And I match yours on...
Code:
11.0K /system/build.prop
5.1M /system/fonts
35.5M /system/framework
1.0K /system/lost+found
19.2M /system/media
0 /system/preinstall
304.0K /system/recovery-from-boot.p
4.6M /system/tts
8.3M /system/usr
This is with busybox installed in the xbin folder so that is probably why I am over on that one, however the app folder is quite a bit over as well but I can't figure out why. The only file that I can find in there that doesn't seem to belong is Superuser.apk but it is only 191k.
UPDATE: I finally found a large app that wasn't present in the system dump that you had mentioned before. I backed it up to my sd card and removed it, went through the update, and now my camera is working. Thank you very much to everyone who helped, especially limaxray!
Glad I was able to help!
This is a great example for why we should always wipe data/cache before any rom update.
dsw361 said:
This is a great example for why we should always wipe data/cache before any rom update.
Click to expand...
Click to collapse
That wouldn't have helped here at all. If anything, it would have made it impossible to use adb in case of a boot loop.
These are not like community ROM updates and don't need anything wiped.
limaxray said:
That wouldn't have helped here at all. If anything, it would have made it impossible to use adb in case of a boot loop.
These are not like community ROM updates and don't need anything wiped.
Click to expand...
Click to collapse
Exactly. the last thing I would do is wipe data/cache if we encountered a bootloop. Adb is so important to us right now because we don't have a custom recovery or an sbf.
Sent from my DROID3 using Tapatalk
I have a rooted Nexus 6 and wanted to edit my build.prop file in order to enable Wifi sharing. I made a backup first, and then when I saved build.prop after editing it was 0 bytes. Then I saw the backup was 0 bytes. First I crapped myself, then I copied in a N6 specific build.prop I downloaded off the net to /system, but no matter what I did, that new file was 0 bytes even though the original was 5k. 'df' showed I was not out of space in /system (had about 1.5 meg free). I even tried mounting /system RW just in case it was RO.
I finally decided after 3 hours of this that perhaps the whole thing was RO and a reboot would clear everything (based on a couple of other posts I read).
I held my breath, rebooted..... and as I feared I just get the black screen that says Google with a lock.
I can't shut off the phone (to reboot into recovery mode), the Nexus doesn't have an off button. I hold power down and it reboots. I give it a short press and it does nothing. I hold them all down and it reboots.
Can I get a pointer please to a thread that might help bail me out?
As a side note, I'm having problems connecting to my phone in debug mode with adb (even before the reboot), so if I need to use those tools, that's another hurdle I'll have to figure out.
Hold the power button + volume down to get to the bootloader. Go to recovery and reflash whatever rom you were on . A dirty flash should suffice.
Hit thanks if this solve your problem.
Getting a little further. Managed to boot into TWRP. Got into terminal, tried to copy in the build.prop file to /system that way but am being told I'm out of space.
Found a similar thread here I'm digging through.
http://forum.xda-developers.com/nexus-6/help/nexus-6-bootloops-build-prop-edit-6-0-1-t3473306
Just saw post #2, thanks. Thought I had it. I freed up some space in /system/app by deleting a couple of foreign keyboard files. Then copied in the build.prop file and this time it was the correct file size. Rebooted, but no change. I really thought that would have fixed things.
As an aside, df lies, there really was no space in /system
Looks like what I found was not a stock build.prop. I have no idea how much it differs but it contains this line:
ro.build.display.id=NexZen by VECTUS V07
Ha! Also it's for 5.1.1. Darn! I should have looked at this first.
Does anybody happen to have a pointer to a stock Nexus 6 6.0.1 build.prop? Google has failed me on this one.
Your original problem was, as you've found, that you had no space in your system partition. The reported 1.5 mb is way to little space to do any kind of system mods... I've found i need at least 50-60 mb free.
Stock build.prop is easiest found in the factory images, in system.img. If you're pushing it to your phone in recovery, don't forget to set the correct permissions (chmod 644).
Thanks, I did pull the file out of the stock ROM, but I must have gone wrong somewhere because it didn't work. I then looked at the /system directory and it was empty other than /system/bin. No idea how the heck I could have deleted the other files in there. That would have been a nice clean fix. But now I'm forced to do a flash. What a waste of a night! Thought it would be nice and simple to turn on wifi sharing. Ha!
I figured 1.5MB would be more than enough to add a single line to a file, the file system block size I'm guessing is in the 2-4K neighborhood. Regardless, it clearly wasn't enough for whatever reason.
I was on a stock ROM. Since I can't easily do a dirty flash of a stock rom, and I can't connect with adb, I need to try to find a TWRP version of a stock 6.0.1 or something really close. I'm pulling off whatever data I can save now just in case I have to wipe this.
If your /system is empty in TWRP it means you haven't mounted system. Under "Mount", make sure "system" is checked.
Sounds like the easiest thing for you would be just to fastboot flash the system.img from the factory image. That'll get you back on track.
It was a really late night but I'm back in business this morning. I used this stock ROM image with TWRP and did a dirty flash.
http://forum.xda-developers.com/nexus-6/development/rom-stock-rooted-6-0-1-mmb29k-t3279185
Now I still need to update my friggin build.prop!!!
robroth said:
It was a really late night but I'm back in business this morning. I used this stock ROM image with TWRP and did a dirty flash.
http://forum.xda-developers.com/nexus-6/development/rom-stock-rooted-6-0-1-mmb29k-t3279185
Now I still need to update my friggin build.prop!!!
Click to expand...
Click to collapse
Use adb and pull it to PC,edit it and push it back easiest way with newer Android versions
i have encountered this on my newer nexus 6. whereas my older nexus 6 seems to be void of these characteristics.(i have started to believe it is because the older one was moved through the API levels smoother....19-20-21-22-23-24-25....as my new one has gone from 18--------to 25. THAT IS TOTAL PROCESS OF ELIMINATION. no idea if thats what it is.) i was able to to push a reboot and temp. flash into twrp from adb/nrt. i dirty flashed my ROM and GApps and seemed to quick fix.
---------- Post added at 03:54 PM ---------- Previous post was at 03:47 PM ----------
there are a few key issues i have witnessed (as a whole) with a young and older sibling too..... which is not the subject of this issue but i think what i have come to learn can shed light on situational(from time to time) issue that i have to deal with when consistent flashing. the RO/RW is now a part of my routine for the newer phone(cause it will randomly drop its RW for no reason and prevent proper filing for busybox or in my case nethunter libraries)
whew. I was gritting my teeth on reboot tonight after editing build.prop again, but this time it went without a hitch. It sucks how you can find all these great articles about how to do stuff, but invariably I own the one phone where there's a gotcha that one doesn't think to look for
I'll keep an eye out for if/when it'll let persist.root. or the .....persist.dun. Will set =1 without breaking selinux.