Database Develop

Odex script and optimised donut build

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.

De-Bloat Script

I used psouza4's Bloatware Removal for Droid 3 script to remove the bloat from my Bionic: http://forum.xda-developers.com/showthread.php?t=1238472.
While it got most of it, it left behind a few apps due to name changes in apps between the 2 devices. After SSH-ing into my device I compared the names of the lingering apps with the ones in the script and made the proper changes.
I saw in his post that some people were looking for a more refined way of removing Motorola's widgets, so I added that to the bottow of the script for users to uncomment if they want to remove specific widgets instead of all or nothing.
Lastely, I tossed in a few other options that would have to be uncommented to run, such as removal of QuickOffice, File Browser, and Browser. The latter 2 will need replacements installed prior to removing them or problems will occur (or so I've read).
That being said, I will not post the script until I get the OK from psouza4 to repost his work with my changes. Also, if this has been done already (I couldn't find it...and yes, I looked) then please let me know and I won't bother. Stay tuned if you're interested in using it. Hopefully I can repost it for new Bionic owners like myself.

Diff Output
Attached is the diff output I ran against my edit and the original script. The first entry of each comparison is my edit to the original command in the script.

Scripts
Attached are the de-bloat and restore scripts based on psouza4's Droid 3 work.

n00b Question:
Does this just freeze all bloat or does it remove it completely?
Easy answer I'm sure... I just want to be sure I understand what this does.
-Thanks

Darca said:
n00b Question:
Does this just freeze all bloat or does it remove it completely?
Easy answer I'm sure... I just want to be sure I understand what this does.
-Thanks
Click to expand...
Click to collapse
it renames the files with a .bak extension so the OS can't see them, and therefore wont load them.
by not deleting them you can run the restore script to remove the. bak extension. i had to do this today to update my bionic (the update fails upon installation if it cant see the apps you renamed.
make sure to follow the instructions in psouzas post with regards to using a program such as script manager.

Thank you!

[BOOTSTRAP] Custom Safestrap v1.08f Released - 4-16-2012

Huge thanks to Hashcode for all his hard work thus far, what with the totally ingenious Safestrap and his latest victories with CM9. I hope this helps somebody out and that at least *someone* out there thinks this is as cool as I do.
Pushing OK+Backspace will force the console to kick you out back into the recovery, in case you get stuck. Keep in mind that the console is pretty powerful but also really dangerous if you don't know exactly what you're doing. Although, you'll never learn how to do anything awesome unless you get your hands dirty.
The Microphone button is now ESC, command history works, tab-autocompletion works via either the hardware Tab key or by pushing OK+i, and you can scroll back up through the text one line at at time with Alt+Up or Alt+Down or in chunks of 8 lines with Shift+Up and Shift+Down. Home is the home softkey, or the Search button on the keyboard, and End is the Power button. You could also push OK+A or OK+E for Home and End, respectively.
Make sure you uninstall Safestrap and then remove the application before you install this one. I just jacked Hashcode's .apk and stuffed my new binaries inside the .zips, if you don't want to bother with uninstalling and reinstalling the .apk, you can extract the recovery.zip and 2nd-init.zip from the archive and push them both to /system/etc/safestrap and reboot. Enjoy.
..............................................................
EDIT: I finally got my act together and put my modified sources on github:
http://github.com/buddyrich/android_bootable_recovery
............…………………………………………
EDIT: Just finished up my latest update to this branch of Hashcode/Koush's work. Added:
-Use numbers on the hardware keyboard to select menu entries. Got really tired of scrolling around and thought this would make things a bit quicker.
-Scrolling/repeating keys. Holding in for longer than about half a second will repeat even faster now, similar to a real terminal on a PC for instance.
-vim statically compiled to avoid the need for any external libs (ie: having /system or /systemorig mounted). Full color support and syntax is working great now; the only thing missing is background colors, which will be tricky to implement.
-a $HOME directory is now made at /emmc/safestrap/home. This is set up when the .apk is installed; it isn't necessary so it can be deleted if you want, but it is required if you want to have a persistent command history in bash as well as the ability to customize your .bashrc and .vimrc files. Most of you won't really know what this means, but if you do you'll probably appreciate it.
-Revamped all the menus and made everything look a little cooler. Let me know what you guys think! I got rid of the highlighting box that shows which menu entry is currently selected and changed it to simply highlight the text in white to distinguish from the green/yellow menus; I think it's a little easier on the eyes but some feedback would be cool. It wouldn't be very hard to allow the users to customize the menu colours themselves via external files placed on the sdcard/through a menu option.
-Fixed the issue some people were having with restoring to /systemorig; there aren't any more issues mounting/unmounting /systemorig or /system during a restore
-Probably many more things I've forgotten
-.bashrc tweaks, fixed a few aliases, nothing major
-You can flash updates from either safe or non-safe mode now, look in the advanced menu. Really though, be careful and remember to make backups of your /systemorig partitions. Don't say I didn't warn you! Guaranteed, someone out there will complain that they broke their phone so I was pretty hesitant to let that out in the wild, but I know I've found myself in the situation where I could've used it so there you have it.
Let me know if anyone finds any issues, I've done a pretty thorough job testing this over the last few weeks but there's always something to be missed. The new .apk is over the size limit to be posted in the forum due to the new bash and vim binaries and the vim runtime files, so you can download the new version from my dropbox here:
Safestrap (Tweaked) v1.08e for Droid 3
http://db.tt/CArenxr7
EDIT:
----------------------
Just finished thoroughly testing my latest release and think it's ready for human consumption! Another batch of sweet additions:
1) Proper implementation of /systemorig flashing while in non-safe mode... without any modifications needed to the updater-script present in any flashable zip. Even if the updater-script inside the. zip file you are flashing targets "/system", if you confirm it about three times in non-safe mode it will know to copy the files onto /systemorig to replace your stock system.
You can install Gingerbread-based ROMs such as MavROM 3.5 to the stock /system partition while in non-safe mode via the Advanced menu. Safestrap will backup and afterwards restore it's own files needed to ensure you can still get back in after a flash of the /systemorig partition. Note that flashing your original /system partition with an ICS ROM won't work yet because they need custom init.*.rc scripts in place during the 2nd-init process; this isn't hard to do but I was getting anxious to get something out so it'll have to wait until next time.
2) Redesign of the layout for the menus, much more organized
/* 3) Allow for rebooting directly into the recovery, either via the shell command "reboot recovery" or through the Reboot Menu */
// EDIT: Seemed to be causing some users to persistently boot straight into the recovery so on the backburner for now
4) Allow for custom colors for either safe or non-safe mode; to change the colors for now you have to execute a few little shell commands. Here's an example to change safe mode colors to a blue-grey and then non-safe mode colors to maroon:
Code:
s_rgb 139 137 137
ns_rgb 127 34 10
cc
Basically, "s_rgb" sets the colors for safe-mode and the three arguments (139 137 137 in the above example) are the codes for the red, green and blue components of the end result; you can look up rgb color codes for your own custom colors. "ns_rgb" is the command for non-safe colors. "cc" just tells the recovery to update the colors to whatever they've been changed to. If you don't like what you've done and just want to revert back to the stock ones, you can just wipe your /cache partition and they'll go back to normal.
Eventually I thought it'd be cool to be able to do this via the recovery UI but I haven't been able to envision how it would work yet.
5) Added background colors/highlighting in the console now, makes vim look a lot prettier. If there's anyone out there who cares, I preinstalled a few plugins (MiniBufExplorer, MRU (most recently used files), bash-style path completion, etc.)
Also, changed the cursor from the big ol' ugly white block to an easier-on-the-eyes one-character underline.
Yeah, it's overboard.
6) Much faster backups and somewhat quicker restores now. I clocked full backups (including /systemorig and ~350mb /data partition) at around 2 mins and full restores at around 7 minutes. Also fixed up the progress bars so they give a more accurate representation of how much longer the backup/restore will be.
7) Moved $HOME and other misc. Safestrap files to /cache instead of the /sdcard
8) Probably half a dozen other OCD details that I've already forgotten.
Test it out and let me know what you guys think!
As always, sources are posted on my github:
https://github.com/buddyrich/android_bootable_recovery
You can get the new .apk here:
Safestrap (Tweaked) 1.08f for Droid 3
http://db.tt/u4vAwv2u

i need this about 6 hrs ago lol.

Quite useful mate cheers.
=smc

Thank you so much for sharing this file. Your work is greatly appreciated.

This is a nice little(big)addition to safestrap! Thanks for adding it in!

I can't think of any better use for Christmas Eve than coding a bash console into recovery! Merry Christmas to the D3! Thank You!

Sounds good. I haven't grabbed it yet (as I need to keep my own customised Safestrap for ME863 nandroid support) but one thing I'd note is that the "OK" button (i.e. trackball click) is used for "Control" in Console+, and the console in Amon_RA's HTC Dream recovery. That saves you losing the @^ key.
Edit: Also: Source? Sounds like something that could be pushed upstream. I always found the console in Amon_RA's recovery very useful, missed it on my current device, when I didn't have a computer with ADB handy.

TBBIe,
I have an XT860, so I'm curious to see if this would work on your ME863. I remember seeing a post of yours a few months ago mentioning issues with the preinstall and data partitions (I think it seemed that the data partition was extended into the first bytes of the preinstall partition, rendering it unmountable during init) that should also have affected the XT860, but I have never experienced any issues with the partitions since Hashcode released v1.06.
I'll commit my sources to github shortly so you have take a look.

I am trying to get through the preinstall problem myself after flahing xt883 and I was wondering if I could fix it with this?
Sent from my DROID3 using xda premium

Hey there guys, Village Idiot here...I've been successfully using Hash's SafeStrap for a while now and wanted to try this one out. What's the difference here? Just by looking at it, I can't tell. It seems better from what everyone is saying, but I have no idea how to utilize it. Would you mind dumbing it down for Simple Jack over here? Thanks.

redsox985 said:
Hey there guys, Village Idiot here...I've been successfully using Hash's SafeStrap for a while now and wanted to try this one out. What's the difference here? Just by looking at it, I can't tell. It seems better from what everyone is saying, but I have no idea how to utilize it. Would you mind dumbing it down for Simple Jack over here? Thanks.
Click to expand...
Click to collapse
It has a console option included, allowing you to run shell commands, which could potentially save your butt if used right.
Otherwise it the same
Sent from my XT860 using xda premium

Endoroid said:
It has a console option included, allowing you to run shell commands, which could potentially save your butt if used right.
Otherwise it the same
Sent from my XT860 using xda premium
Click to expand...
Click to collapse
Which it just did lmao..hash really needs to include this in his release!
Once again thanks for this mod it is PERFECT!

ovelayer said:
Which it just did lmao..hash really needs to include this in his release!
Once again thanks for this mod it is PERFECT!
Click to expand...
Click to collapse
Oh I'm sure I'll be damn thankful at some point. Made a point of installinng it
Sent from my XT860 using xda premium

Rick#2 said:
I have an XT860, so I'm curious to see if this would work on your ME863. I remember seeing a post of yours a few months ago mentioning issues with the preinstall and data partitions (I think it seemed that the data partition was extended into the first bytes of the preinstall partition, rendering it unmountable during init) that should also have affected the XT860, but I have never experienced any issues with the partitions since Hashcode released v1.06.
Click to expand...
Click to collapse
The difference is the other way 'round. The /data partition is extended backwards over the end of the /preinstall partition.
It doesn't cause problems during init, it was causing nandroid to fail mounting /system, and presumably would make switching to safe-mode fail (although I never tried)
My patch to fix this for nandroid was based on 1.06. The only way this could be 'fixed completely' in safestrap was if safestrap had had repartitioning code added at some point to resize /data back down and grow /preinstall to be large enough to hold a safe system. And Hashcode'd said he didn't have time or real inclination to do that, I thought.
I'm fairly strapped for time at the moment, so I don't know when I'll have a chance to look at the source and/or try out your build. But it's definitely somewhere in my TODO list. ^_^

orry for dumb question...ok, i wanr root my friends drodi 3,i think i know how to do it using the one click software the same i used to root my bionic,now to order to go into custom recovery i need install this apk file am i right,i mean is the same as in bionics bootstrap???? sorr y for noob qustion ,just that i dont speak english very well so i need be 100% sure what am doing thanks again,,btw do u know if the last wifi tethering works on this droid 3???

@rick#2
I'm running CM9 for daily use, but it's a bit wobbly at times, so I run 7.1 as the "non-safe" system. The big limitation to this is that I can't maintain the 7.1 fallback properly as hashcode deliberately disabled installing zips in non-safe mode.
If the wife has forgiven you by now - any chance of adding the ability to install .zips when in non-safe mode?
The alternative is to keep swapping bootstraps all the time, and all it takes is one late night sleepy mistake to stop the device booting one system or both.

I'm in favor of this as well, and have even mentioned it in the main SS thread. Could you add flashing to non-safe, but say with like 3 layers of warnings saying something like "THIS IS YOUR NON-SAFE, MAIN SYSTEM. FLASHING HERE CAN BRICK YOU."
This would be really nice because it's a PITA to keep switching strappers, albeit it easy, just a burden.

This is a great hack! I was considering doing this myself but you beat me to it! BTW, is your modified source code on github or somewhere like that, or can you send it to me if not? Thanks again!

Hey guys, sorry for the lack of updates to this thread. Been buuuusy.
I made an account on github about two weeks ago, but still haven't gotten the chance to upload the sources there, for those of you who are interested. I'll do that shortly.
I've got a new version I'll put up pretty soon, just need to do some more testing. I've enabled scrolling (ie: holding a key down to repeat it as opposed to requiring you to push it each time) but have to iron a few things out, and I'd like to add another menu enabling some of the (somewhat dangerous although useful if you know what you're doing) features some of you have requested.

Rick#2 said:
Hey guys, sorry for the lack of updates to this thread. Been buuuusy.
I made an account on github about two weeks ago, but still haven't gotten the chance to upload the sources there, for those of you who are interested. I'll do that shortly.
I've got a new version I'll put up pretty soon, just need to do some more testing. I've enabled scrolling (ie: holding a key down to repeat it as opposed to requiring you to push it each time) but have to iron a few things out, and I'd like to add another menu enabling some of the (somewhat dangerous although useful if you know what you're doing) features some of you have requested.
Click to expand...
Click to collapse
Dude you rock!
Sence you introduced your mod i have used nothing else..
The scrolling feature would be a HUGE improvement i agree ..
Also it would be nice if you could flash on the non-safe system as well..
Hope you can get er done..
I allways seem to watch this thread for updated..i really hope you can continue this adventure without the wife killing you lol..stay real!
---------- Post added at 12:45 PM ---------- Previous post was at 12:41 PM ----------
denpad2010 said:
orry for dumb question...ok, i wanr root my friends drodi 3,i think i know how to do it using the one click software the same i used to root my bionic,now to order to go into custom recovery i need install this apk file am i right,i mean is the same as in bionics bootstrap???? sorr y for noob qustion ,just that i dont speak english very well so i need be 100% sure what am doing thanks again,,btw do u know if the last wifi tethering works on this droid 3???
Click to expand...
Click to collapse
Hey bro if you want wifi teather look up android-wifi-teather..it works!

[Script] Removing stupid useless apps from stock

Hi,
When I got my Droid, I couldn't believe all the stuff that came preinstalled with the phone, so I started deleting everything that seemed unnecessary. Given the fact that I already reflashed the phone 20 times in the last week, I made a little script to help me out. I thought I would share it with you in case it comes handy to someone.
BIG NOTE 0: There's a system part that Motorola uses to get stuff from your phone. It's called Data Collector. Whenever any app crashes, it makes quite a big dump, with your network carrier, signal level, applications installed, applications running and a lot of stuff that isn't opt-in. In fact, one of the scripts (/system/bin/bugtogo.sh) can take screenshots of your phone. I don't like being spied, so I tried to remove it all. Cannot be certain though, but I would recommend you to remove, if you like your privacy, at least, the DataCollector apks, and to empty the bugtogo.sh script from /system/bin
BIG NOTE 1: I don't use this phone in the US, so I don't know if I'm breaking part of the CDMA support. It still shows up in every settings and I don't have any reason to think it won't work, but since I can't test it in anything except GSM/UMTS, I can't know it for sure.
BIG NOTE 2: The script will install Apollo (Music Player), Nova Launcher (homescreen replacement), and Cyanogenmod's Gallery app. If you don't want them and want to keep Blur and the default gallery (the script doesn't remove the music player just in case it's needed by some other app), then don't use this script, or modify it as you wish.
BIG NOTE 3: I am not responsible for anything if this causes a mess. Worst case scenario you'll need to flash back the system partition (fastboot flash system system.img), and then reroot your phone. You have been warned.
This is what it removes:
Code:
/system/app/DataCollection.apk
/system/app/DataCollection.odex
/system/app/DataCollectorProvider.apk
/system/app/DataCollectorProvider.odex
/system/app/DataCollectorService.apk
/system/app/DataCollectorService.odex
/system/app/blur-services.apk
/system/app/blur-services.odex
/system/app/blur_facebook.apk
/system/app/blur_facebook.odex
/system/app/blur_flickr.apk
/system/app/blur_flickr.odex
/system/app/blur_kaixin001.apk
/system/app/blur_kaixin001.odex
/system/app/blur_lastfm.apk
/system/app/blur_lastfm.odex
/system/app/blur_orkut.apk
/system/app/blur_orkut.odex
/system/app/blur_photobucket.apk
/system/app/blur_photobucket.odex
/system/app/blur_picasa.apk
/system/app/blur_picasa.odex
/system/app/blur_youtube.apk
/system/app/blur_youtube.odex
/system/app/vzw_vnav_DROID4.apk
/system/app/vzwapnpermission.apk
/system/app/MyVerizon.apk
/system/app/VerizonSSOEngine.apk
/system/app/MotoVzwAtCmdPlugin.apk
/system/app/MotoVzwAtCmdPlugin.odex
/system/app/VzwController.apk
/system/app/VzwController.odex
/system/app/VzwDeviceSetup.apk
/system/app/VzwDeviceSetup.odex
/system/app/VzwEntitlementService.apk
/system/app/VzwEntitlementService.odex
/system/app/VzwPhoneService.apk
/system/app/VzwPhoneService.odex
/system/app/VCast.apk
/system/app/VCastStub.apk
/system/app/VCastTones.apk
/system/app/VCASTVideo.apk
/system/app/VmmGallery.apk
/system/app/com.motorola.android.server.ims.apk
/system/app/com.motorola.android.server.ims.odex
/system/app/com.motorola.android.settings.aplogd.apk
/system/app/com.motorola.android.settings.aplogd.odex
/system/app/VmmBackupManager.apk
/system/app/VmmBackupManager.odex
/system/app/VmmGallery.odex
/system/app/SmartActionFW.apk
/system/app/SmartActionFW.odex
/system/app/SmartActions.apk
/system/app/SmartCarDock.apk
/system/app/SmartDock.apk
/system/app/ZumoService.odex
/system/app/ZumoService.apk
/system/app/WelcomeWebtop.odex
/system/app/WelcomeWebtop.apk
/system/app/WeatherWidget.apk
/system/app/VZWInstaller.apk
/system/app/Vvm.odex
/system/app/Vvm.apk
/system/app/VSuiteApp.apk
/system/app/VRDClient.apk
/system/app/VMMServiceInterface.odex
/system/app/VMMServiceInterface.apk
/system/app/VideoSurf.apk
/system/app/Videos.apk
/system/app/VideoCalling.apk
/system/app/Swype.apk
/system/app/SocialShare.odex
/system/app/SlingBox.apk
/system/app/SocialShare.apk
/system/app/SlackerRadio.apk
/system/app/RichLocationVzW.apk
/system/app/Protips.odex
/system/app/Protips.apk
/system/app/PlusOne.apk
/system/app/PhotoEditor.odex
/system/app/PhotoEditor.apk
/system/app/OnlineAlbum.odex
/system/app/OnlineAlbum.apk
/system/app/NflMobile.apk
/system/app/Netflix.apk
/system/app/MusicStore.apk
/system/app/MotorolaAccountSetup.apk
/system/app/MotorolaAccountSetup.odex
/system/app/MotoEmailConfig.apk
/system/app/MotoDockHelperService.odex
/system/app/MotoDockHelperService.apk
/system/app/MotoConnect.odex
/system/app/MotoConnect.apk
/system/app/MotoCastDashboard.odex
/system/app/MotoCastDashboard.apk
/system/app/motoactv.apk
/system/app/MotMusic.apk
/system/app/MotGallery.apk
/system/app/MCDownloadManager.odex
/system/app/MCDownloadManager.apk
/system/app/Kindle.apk
/system/app/JunosPulsePlaceholder.apk
/system/app/IlsVzW.apk
/system/app/HuxVmmSetting.odex
/system/app/HuxVmmSetting.apk
/system/app/HuxSnCClient.odex
/system/app/HuxSnCClient.apk
/system/app/GuidedTours.apk
/system/app/GuidedTours.odex
/system/app/HelpCenter.apk
/system/app/FileManager.apk
/system/app/FileManager.odex
/system/app/Facebook.apk
/system/app/DockService.odex
/system/app/DockService.apk
/system/app/DlnaSystemService.odex
/system/app/DlnaSystemService.apk
/system/app/DLNA.odex
/system/app/DLNA.apk
/system/app/DemoMode.odex
/system/app/DemoMode.apk
/system/app/ContactIce.odex
/system/app/ContactIce.apk
/system/app/Cmas.odex
/system/app/Cmas.apk
/system/app/BuaContactAdapter.odex
/system/app/BuaContactAdapter.apk
/system/app/BlurUpdater_VZW.odex
/system/app/BlurUpdater_VZW.apk
/system/app/BlurChooser.odex
/system/app/BlurChooser.apk
/system/app/BackupRestoreConfirmation.odex
/system/app/BackupRestoreConfirmation.apk
/system/app/BackupAssistanceClient.odex
/system/app/BackupAssistanceClient.apk
/system/app/ArcVideoEditorLite.apk
/system/app/android-syncservice-app.apk
/system/app/OutOfBox.odex
/system/app/OutOfBox.apk
/system/app/FriendFeed.apk
/system/app/FriendFeed.odex
/system/framework/com.motorola.MCDownloadLibrary.services_lib.jar
/system/framework/com.motorola.MCDownloadLibrary.services_lib.odex
/system/framework/com.motorola.motoconnect_lib.jar
/system/framework/com.motorola.motoconnect_lib.odex
/system/framework/com.motorola.vzw.vmm.helper.jar
/system/framework/com.motorola.vzw.vmm.helper.odex
/system/framework/com.motorola.vzw.vmm.util.jar
/system/framework/com.motorola.vzw.vmm.util.odex
/system/framework/com.scalado.android.photoeditor.jar
/system/framework/com.scalado.caps.jar
/system/framework/com.verizon.phone.jar
/system/framework/com.verizon.phone.odex
/system/framework/com.vzw.android.gex.jar
/system/framework/com.vzw.android.gex.odex
/system/framework/com.vzw.android.hux.jar
/system/framework/com.vzw.android.hux.odex
/system/framework/com.vzw.android.jar
/system/framework/com.vzw.android.odex
/system/framework/com.vzw.android.smart.jar
/system/framework/com.vzw.android.smart.odex
Instructions:
1. Root your phone if you haven't already
2. Install Busybox from Google Play if you haven't already
2. Uncompress the zip into your internal sdcard. You should get this:
Code:
/sdcard/removecrap/Apollo.apk
/sdcard/removecrap/Gallery2.apk
/sdcard/removecrap/com.teslacoilsw.launcher-1.apk
/sdcard/removecrap/remover.sh
3. Run from a terminal on the phone, or from adb (always as root)
sh /sdcard/removecrap/remover.sh
4. Wait until the phone reboots
5. 200 extra Mb of system and a lot more free ram for your apps. Oh, and Motorola won't get another bug report from you
EDIT: Ooops, Reupdated the zip file, it was deleting one extra file (motosignature inside the framework folder)
EDIT2: Didn't catch Carrier IQ's qer binary on /xbin. Unfortunately we can't touch those binaries since they're in the randisk, so I updated the script so it removes the logfile qe generates and replaces it with a folder so it can never write the scan results again (thank you bofh.bug for the links!)

That's great, but you'll probably have trouble installing whatever official update comes next, since the updates generally expect certain apps to exist (with correct checksums too) so that they can be updated.
Sent from my DROID4 using Tapatalk

highlandsun said:
That's great, but you'll probably have trouble installing whatever official update comes next, since the updates generally expect certain apps to exist (with correct checksums too) so that they can be updated.
Sent from my DROID4 using Tapatalk
Click to expand...
Click to collapse
Probably OTAs will fail after running the script, but fixing it is as easy as reinstalling the system partition with fastboot and then applying the OTA
Sent from my DROID4 using xda app-developers app

This does disable all data connectivity (3G/4G) for CDMA users, you can still receive texts and calls, but will not be able to get data services.
When I have time I will make update this script to work with CDMA users.

arleslie said:
This does disable all data connectivity (3G/4G) for CDMA users, you can still receive texts and calls, but will not be able to get data services.
When I have time I will make update this script to work with CDMA users.
Click to expand...
Click to collapse
Were you able to fix the script so it works for CDMA users? Or, do you know what apps breaks it?

Very nice script, thanks. Easy way to run it by using Root Browser: open as script. But as for me QuickPick is better than ICS Galerry
Sent from my DROID4 using xda app-developers app

Hi biktor_gj , could you make a similar script for Android 4.1.2? Very grateful in advance

Tanzior said:
Hi biktor_gj , could you make a similar script for Android 4.1.2? Very grateful in advance
Click to expand...
Click to collapse
I did again the script for the jelly bean update. This time it removes less crap, since it seems Motorola left a bit less than on previous versions. This will remove the annoying "Foreign card" warning when you boot the phone with some non-verizon sim, the acoustic warning when you turn up the volume, smart actions and so on.
IT WON'T REMOVE THE APPS. It will leave them here:
Apps: /system/app/oldapps
system binaries: /system/bin/oldbin
Framework: /system/framework/oldframework
If you encounter any problem, you can simply move back the files through adb and the phone will be like before applying the script.
NOTE: Only tested on GSM. Probably won't work on CMDA since it's missing most of the Verizon stuff. If you can identify which apps are needed for CDMA to wokr again tell me and I'll update the script accordingly.
I run the script from ADB and worked like a charm. Been using it for 24hours and no problems so far, but you never know, so use at your own risk
Code:
[email protected]:~/Documents# adb push removecrap2.sh /sdcard/removecrap2.sh
[email protected]:~/Documents# adb shell
[email protected]_maserati:/ $ su
[email protected]_maserati:/ # sh /sdcard/removecrap2.sh

It works great, thank you. Good work.
Sent from my DROID4 using xda app-developers app

Hi to all, i found two app : ModemPanicReporter.apk and ModemStatsService.apk. What they are doing ? Maybe it is necessary to remove they too ? Removing these applications will improve battery life.
Sent from my DROID4 using xda app-developers app

[DEVELOPMENT] FlashCast developer support thread

This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my documentation on GitHub, which contains documentation and sample code to help you create FlashCast mods.

tchebb said:
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my flashcast-samples repository on GitHub, which contains documentation and sample code to help you create FlashCast mods.
Click to expand...
Click to collapse
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the jump drive, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.

ddggttff3 said:
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the SD card, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
Click to expand...
Click to collapse
This would definitely be a useful feature. I can see a few implementation details that would need to be worked out in a non-obvious fashion, though:
There is currently no way for a imager script to directly access the root of the user partition. This is intended to prevent multiple scripts from having access to the same filesystem and possibly overwriting each others' files. Instead, scripts are executed in a temporary directory whose contents are discarded on device shutdown. It seems like the solution to this would be to create numbered backup directories, like there are numbered logs now, for mods to place their backups in.
It wouldn't be desirable for a mod to take a backup every time it was flashed, as not everyone cares about backups and they take up lots of space. There would need to be some way for the user to decide whether or not they wanted backups. Maybe another flag file?
Finally, taking a backup of an MTD partition using nanddump (dd should not be used to image NAND partitions, since it is not bad-block aware) images the entire partition, when (in the case of squashfs) only a small part actually has a filesystem on it. This means that a single rootfs backup will take up 400MB on the USB drive. I would want to implement something which can back up only the part of a partition which squashfs is using before I release backup functionality.
Obviously, this is a prime candidate for a new helper function, because of these non-trivial complications. I'll see if I can make the necessary changes to FlashCast and release backup functionality as part of v1.1. Thanks for the suggestion!

One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?

ddggttff3 said:
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
Click to expand...
Click to collapse
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.

tchebb said:
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
Click to expand...
Click to collapse
Sounds great to me! Only other suggestion I have is to add another flag file which would allow Flashcast to continue flashing the multiple zips, even if one errors out.
So, by default if multiple zips are going to be flashed, and it errors on the first, it would stop, get a red LED, and then reboot.
with a flag file present, maybe ignore_errors, even if it errors out on the first zip, it would continue down the chain of zips until it finishes all of them.

Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.

bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.

tchebb said:
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
Click to expand...
Click to collapse
Im gonna dive into it

Have a little bug report.
If a person has more then 85~MB in their eureka_image folder, and then they start a SquashFS File system edit, flashcast will report an error saying out of space. Now, here is the error part. Even though it failed to mount with an error, the imager.sh file will continue to run, and will then attempt to flash back a corrupt file, causing a non-bootable chromecast until the system partition is re-flashed.

bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
The first script on THIS SITE will unpack the .PAK files, although it unpacks everything as a .png as it was made for a different Chromium device. So you would have to manually go rename all the files to their correct extension for the files, but because it expects everything to be a .png it won't pack back properly. The second script, technically should unpack/pack as proper file extensions, but I never got it to work right as I have little to no knowledge of Python.

The chromium source has a script,data_pack.py (which I can't link to since I'm a new user ATM) which can be used to pack and unpack .PAK files. The script posted above seems to be lifted from this source and modified to detect a few filetypes and write the unpacked files. But if you want to modify or add images and need to repack them, this script will help you figure it out. I'll work on adding and making some changes to the theme and give some instructions.

how to mount usb drive
Haven't used linux in years. Thanks!

Hey, want to do some poking around in the flashcast .bin file...how do I go about doing that? What is the file format, and is the image mountable in linux? Even better might be to extract files/folders from the image...what tool can I use to do that?

Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand

tomg09 said:
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
Click to expand...
Click to collapse
Buildroot does not let us build a bootloader, it lets us build a custom linux distribution that runs on the chromecast. The reason it is unable to do anything "graphical" minus the static image is due to licensing of the marvell GPU driver the chromecast uses. It is currently closed source, so it is unable to be compiled. We can use the blob from the stock OS, but ATM there is no need, and this can cause licensing issues.
Also, you can still access /dev and such on the stock OS. The big thing is the stock OS has usb input disabled at a kernel level, so it doesn't mount or detect any devices plugged in when the OS is running. This is circumvented though if you build and use your own custom kernel. For the features Eureka-ROM adds to the stock OS, we add those by using googles open source cross compiler for the device to build supported binaries.

Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I havent found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.

tomg09 said:
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I haven't found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
Click to expand...
Click to collapse
If we had a fully working open source graphics driver, lots could be accomplished. Full custom linux distributions could run x11 shells, we could have xbmc working with hardware decoding, and yes android would technically be possible if enough people wanted to put the time and effort into it. You can take the blob from the rom to do some of this, but things like hardware accelerated decoding will still not be possible due to the fact there is no documentation on how to use the blobs properly for things like that. (this is my understanding so I may be off on some small details, @tchebb can probably explain it more in depth.)
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.

ddggttff3 said:
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
Click to expand...
Click to collapse
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?

tomg09 said:
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
Click to expand...
Click to collapse
One more question...I've looked through the toolchain...the way it's set up is somewhat confusing. In the root directory of the toolchain: bin=gcc, g++, everything else I need to compile. What are the two folders entitled "arm-unknown-linux-gnueabi" and "target-arm-unknown-linux-gnueabi"? They seem to have relevant stuff (one has gcc, g++, etc except without the arm-unk... prefix, and other binaries which seem important). How do I use these/should I use these/why are they kept separate?
Thanks for the help.