Database Info

JFv1.31 Released! (updated 01-03-09)

Update (01-03-09)
v1.31 is out! This is a minor bugfix release to fix a few issues that had cropped up in v1.3.
The changes from v1.3 include:
Fixed the nandroid backup so that it works on sdcards with a raw fat32 filesystem (with no partition)
Added the telnetd binary from RC28
Fixed an issue with SuperUser where it was displaying the wrong processes in the su request popup
SuperUser should allow root to use su without displaying the popup (though there's not much point.. )
Added /system/modules and /system/xbin to fstab in normal and recovery mode
Minor fix for the update-script, so the progress bar acts more sanely
I have the usual RC30 and RC8 versions, and new for v1.3 is an ADP1 version.
ADP1: (md5: 96b2abd9a1da2852bc33b2052ea51b2a)
http://android-dls.com/forum/index.php?f=24&t=223&rb_v=viewtopic
http://www.gotontheinter.net/content/new-images-jf (at bottom of page)
RC30: (md5: 0f2e6a4244410e00028db55b4fbf808c)
http://android-dls.com/forum/index.php?f=24&t=223&rb_v=viewtopic
http://www.gotontheinter.net/content/new-images-jf (at bottom of page)
RC8: (md5: e008bbe1d93abd0c2e5e6218f012f20d)
http://android-dls.com/forum/index.php?f=24&t=223&rb_v=viewtopic
http://www.gotontheinter.net/content/new-images-jf (at bottom of page)
These updates are installed the normal way. Save them to your sdcard named update.zip, boot into recovery mode (home + power), and then press alt+l and alt+s. If you are switch between versions, e.g. from RC30 to ADP1, then it's usually a good idea to perform a wipe. You can try booting up without a wipe, but if it doesn't boot, or you get strange errors once it boots up, go back into recovery and perform a wipe (alt+w)
Note: To install these updates, you need to have a recovery image that uses test keys. If any of the following are true, you most likely have a recovery image that uses test keys
- you have installed my modified recovery image in the past
- you have an ADP1
- you currently have one of my modified firmwares installed
What's new?
The coolest new functionality in v1.3 is a new backup utility that allows you to perform a backup directly from recovery mode with alt+B. This is done using infernix's and brainaid's nandroid script, which they kindly modified to work in recovery mode. Let them know what you think . The backups are stored in a subfolder in the nandroid folder on your sdcard. To restore them, you have to copy them to your computer, and then flash them with the fastboot tool (sorry, no integrated restore yet).
If you get errors when making a backup, first make sure you have enough free space on the sdcard. it needs around 85-90mb. If you have enough space, then try reformatting the sdcard (fat32 is your best bet).
Other changes of note include
This version includes a new busybox binary that I compiled against uclibc, making it much smaller (1.8mb vs 700kb).
All busybox applets are linked at /system/xbin/bb, which is also in the path. So there are many more standard unix commands available in the terminal.
Many more modules and binaries are included in /system/xbin and /system/modules. They were also optimized for size, so even though there are more modules and binaries, they actually take up much less space than they did on v1.2
I added the terminal emulator application to /system/app. (don't worry, it won't, or at least shouldn't , cause any problems if you already have it installed)
got rid of the normal su binary, in favor of koush's su and SuperUser application. See details here
when you boot up into recovery, it will automatically show the text. You can press alt+L to turn off the text and ogle the background. (did I mention there's a new background? shhh. it's a secret )
fixed the annoying uptime bug, where the uptime is shown incorrectly in the settings
added /data/local/bin to the path. Feel free to add your own binaries/scripts here.
includes the /dev/mtd/mtd6 and /dev/mtd/mtd6ro devices, which allow access to the entire flash chip (other than certain restricted areas used by the radio)
new "ro.modversion" property, that is set to "JFv1.3". The intent of this property is so you can know you are running a modified version, as well as identify which version
added a modified /system/etc/security/cacerts.bks file, which contains additional certificates for cacert.org (courtesy of Disconnect)
added a /system/etc/resolv.conf file with the 4.2.2 family of DNS servers, to allow busybox's ping, wget, etc. to resolve host names
See the attached change logs for a complete list of changes with respect to the corresponding "official" firmware.
---------------
Update (01-03-09): Updated the links to point to the v1.31 versions
In addition to the updates themselves, I am also releasing a build environment that can use to build each update from scratch. You can use these to easily make your own custom updates. It includes some utilities that were built from git source. The binaries are for 32bit x86 linux. If you want to run it on a different platform, you're on your own.
NOTE: You don't need these to use my update. Just download one of the updates from above and install it. The build environments are only if you want to make your own customized update.
The general idea of the build environment is that it extracts the original files from the official update (or from my original ADP1 update), and then copies over anything from the various ModifiedFiles folders, then packages it all back up into a ready-to-be-applied update.zip. It does this for the boot image, recovery image and system folder. You can also specify files to delete in the various OriginalFilesToDelete.mk files.
Consider anything new that I created for the build environments (the makefiles, etc.) to be in the public domain. Everything else retains its original license of course.
Instructions:
- extract the build environment into a folder
- download the official update that the update is based on, and put it in the root of the build environment. (note: use my original ADP1 update for the ADP1 build environment. available on this page)
- run make as root. yes, it has to be with root, because the binaries in the 2 cramfs images should be owned by root. (note: I plan on using fakeroot in the future, to workaround the need to be root)
- after make finishes, assuming there are no errors, the update should be in Workspace/update.zip.
Download the build environments here:
ADP1: (md5: 2d116b334515d4d702776b9d74d2e658)
http://android-dls.com/forum/index.php?f=24&t=223&rb_v=viewtopic
http://www.gotontheinter.net/content/new-images-jf (at bottom of page)
RC30: (md5: 29ced6e7601bac47252e51e5ac4f0ca4)
http://android-dls.com/forum/index.php?f=24&t=223&rb_v=viewtopic
http://www.gotontheinter.net/content/new-images-jf (at bottom of page)
RC8: (md5: b26f3cd244da9b8662766db69734000e)
http://android-dls.com/forum/index.php?f=24&t=223&rb_v=viewtopic
http://www.gotontheinter.net/content/new-images-jf (at bottom of page)

Sweet! great timing JF works like a dream!
Btw, love the new recovery background...I feel seizures coming on...
Stericson

Fantastic! Been waiting for your update, looking forward to it. THanks JF and others who made this possible!

Thanks for the great work!!!

Awesome, thanks!
So what would we need to do to replace the browser with Koush's auto-rotating version and how about replacing the alarm clock with Klaxon?

This is awesome! a little pre 2009 present! thanks JF for all that you do !!!

Just posting to say this update worked a-ok for me. Thanks JF for changing busybox and for the new su.

s0niqu3 said:
Awesome, thanks!
So what would we need to do to replace the browser with Koush's auto-rotating version and how about replacing the alarm clock with Klaxon?
Click to expand...
Click to collapse
Download the build environment for the version you want, extract it, put the klaxon and browser apk into system/ModifiedFiles/system/app, put in a delete entry into system/ModifiedFiles/OriginalFilesToDelete.mk for the alarm apk and odex, then run make as root.

JesusFreke said:
Download the build environment for the version you want, extract it, put the klaxon and browser apk into system/ModifiedFiles/system/app, put in a delete entry into system/ModifiedFiles/OriginalFilesToDelete.mk for the alarm apk and odex, then run make as root.
Click to expand...
Click to collapse
Will this work on windows vista with cygwin as opposed to a full linux VM?
Are there any specific binaries I need to install?
thanks again!

one last comment... love the Alt+B i know B is supposed to be for backup, but in my mind it stands for BADASS!!!!!!

s0niqu3 said:
Will this work on windows vista with cygwin as opposed to a full linux VM?
Are there any specific binaries I need to install?
thanks again!
Click to expand...
Click to collapse
JesusFreke said:
The binaries are for 32bit x86 linux. If you want to run it on a different platform, you're on your own.
Click to expand...
Click to collapse
You might be able to get it to work. You'll need to replace the linux binaries in the tools folder with windows equivalents.
But tbh, you're best bet is to install vmware and get an ubuntu VM running.

Did a quick search and could not find what ADP1 is. Is this the developer version?

JesusFreke said:
In addition to the updates themselves, I am also releasing a build environment that can use to build each update from scratch. You can use these to easily make your own custom updates. It includes some utilities that were built from git source. The binaries are for 32bit x86 linux. If you want to run it on a different platform, you're on your own.
The general idea of the build environment is that it extracts the original files from the official update (or from my original ADP1 update), and then copies over anything from the various ModifiedFiles folders, then packages it all back up into a ready-to-be-applied update.zip. It does this for the boot image, recovery image and system folder. You can also specify files to delete in the various OriginalFilesToDelete.mk files.
Consider anything new that I created for the build environments (the makefiles, etc.) to be in the public domain. Everything else retains its original license of course.
Click to expand...
Click to collapse
I applaud you, sir.

momentarylapseofreason said:
Did a quick search and could not find what ADP1 is. Is this the developer version?
Click to expand...
Click to collapse
ADP1 stands for Android Dev Phone 1.

jashsu said:
ADP1 stands for Android Dev Phone 1.
Click to expand...
Click to collapse
What I figured.... thanks!

JesusFreke said:
You might be able to get it to work. You'll need to replace the linux binaries in the tools folder with windows equivalents.
But tbh, you're best bet is to install vmware and get an ubuntu VM running.
Click to expand...
Click to collapse
Ah, thanks for the confirmation.
Is there anyone out there that can tackle this for me? I'm visiting family through the 5th, and don't feel right installing a linux VM on their computer.
If so, PM me, and I can give you the specifics, but really all I'd like is for the alarm clock to be removed and replaced with Klaxon, and for the browser to be replaced with koush's build that auto-rotates.
This would be for a G1 RC30 build.
Cheers, and thanks in advance!

jashsu said:
I applaud you, sir.
Click to expand...
Click to collapse
I stand.. applauded?

Thanks!
Thanks JF, I just flashed the ADP1 version and it is working great so far.
Have you attempted to add in the MyFaves app to the ADP build? I had tried a couple of things previously, but I was running into some errors. I may try it with your new build environment later if it is something you haven't attempted.
BTW - for those looking for a virtualized Linux environment, I also recommend Sun's Virtualbox (http://www.virtualbox.org/). It is free for personal use and provides a lot of the functionality that you get from the paid versions of VMWare. In fact, some things seem to run smoother when running Linux virtualized on Vista 64bit; i.e. I can get copy/paste between OSes and auto-resizing guest screens without a lot of extra hassle. Just make sure that you read up on how to use the USB virtualization so you can create the filter for the phone as a USB device.
Great work once again JesusFreke!
-Brint

s0niqu3 said:
Ah, thanks for the confirmation.
Is there anyone out there that can tackle this for me? I'm visiting family through the 5th, and don't feel right installing a linux VM on their computer.
If so, PM me, and I can give you the specifics, but really all I'd like is for the alarm clock to be removed and replaced with Klaxon, and for the browser to be replaced with koush's build that auto-rotates.
This would be for a G1 RC30 build.
Cheers, and thanks in advance!
Click to expand...
Click to collapse
You can always do it manually of course. Install the update, then remount the system as rw, then delete the alarm apk and odex and the browser apk and odex from /system/app, and copy the klaxon and modified browser apk to /system/app

JF!!! You... are a scholar and a gentleman... A happy new year to you...
s0niqu3 said:
Is there anyone out there that can tackle this for me? I'm visiting family through the 5th, and don't feel right installing a linux VM on their computer.
Click to expand...
Click to collapse
Couldn't you also use an Ubuntu LiveCD just as easily? That would allow temporary access to a 'nix environment without touching the existing drive, mount one of the partitions temporarily for your make environments. Just a thought...

Android without Google applications

About the time when further existence of Cyanogenmod was endangered because of Google's legal claims, there happened to be a post from the author of Cyanogenmod:
Since I don't work with any of these closed source applications directly, what I intend to do is simply ship the next version of CyanogenMod as a "bare bones" ROM. You'll be able to make calls, MMS, take photos, etc. In order to get our beloved Google sync and applications back, you'll need to make a backup first. I'm working on an application that will do this for you.
Click to expand...
Click to collapse
The current state is that (supposedly) Cyanogenmod build does not contain any Google apps, BUT in fact to install Cyanogen you should first flash a development image from HTC (DRC83 or so) that contains them, and atop of this Cyanogenmod.
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
If anyone knowledgeable in the affairs of "update.zip" format reads this, I would also like to know if the Cyanogenmod's update.zip does only write some files to existing filesystems, or does it first erase/create new filesystems in some areas of flash memory? And what does the update.zip from HTC do (this one is certainly supposed to erase the root filesystem of the device!)? Would applying just the Cyanogenmod's update.zip leave the HTC files in place if they are already there, and how can I clean the root filesystem?

Not sure if that's how it works. Why don't you just remove the apps after?

If you really want Android without Google Apps, you can also compile from the source Android. That will give you basic functionality (phone, contacts, email) without Google Apps on it. You just need to checkout donut branch, instead of eclair's, since eclair is still on development.
Check: source.android.com and follow the documentation to checkout and compile for dream and sapphire

xaueious said:
Why don't you just remove the apps after?
Click to expand...
Click to collapse
The Google's libraries seem to be hiding in every corner, so that's not really clean.
@dferreira
Right, but it is probably some hassle (and I would duplicate some work of the people who publish their images here), also the download would take a long time with my internet connection. Why do it, if it's already done? A stock Android build from AOSP must be hanging somewhere around... but I haven't seen it yet. All the donut images I've seen on this forum had some silly modifications and were prepared to work with Google packages.
(Or is the source prepared nicely enough to work right if it compiles successfully and is put on the device? How do you put the build in an update.zip to allow flashing to a consumer device with a custom recovery image, but without engineering SPL?)

Donut branch should compile and work without a hitch. Even eclair works out-of-the-box, without camera working and 3D acceleration.
The compiled result will be recovery.img, boot.img, system.img, userdata.img... I've flashed them using fastboot Unless you know how to make a update.zip out of these, you should be all set. The update.zip only works if signed with the right certificates for non-engineering SPL devices.

The update.zip only works if signed with the right certificates for non-engineering SPL devices.
Click to expand...
Click to collapse
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?

kguciek said:
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
Click to expand...
Click to collapse
Yes, the kernel is in boot.img, and it is the AOSP kernel that comes with the source code There is no radio firmware on AOSP.

update.zip is made by issuing make otapackage.

Hi buddy i thought about something like that few weeks ago and i think MarsDroid has already made some version of Android(Very lite MarsDroid SPL 7) fully without Google apps, so try it..

OK, I've built an image from donut source, coupled it with a kernel from a CyanogenMod port, and it works flawlessly on my phone!
I've uploaded the images to RapidShare, should anyone need them Links are at my website (guciek.net/en/stuff/android_builds).

kguciek said:
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
Click to expand...
Click to collapse
Yes, it works fine if you don't flash the 'defanged' update image first.

unfnknblvbl said:
Yes, it works fine if you don't flash the 'defanged' update image first.
Click to expand...
Click to collapse
But it wouldn't erase the whole system partition, so there could still be some files left.
Now that I realised I can flash images from recovery even without engineering SPL, it seems a safer and cleaner way.
Also, I like to have a second ext2 partition on SD card that is only accessible from a computer, and I wasn't able to do this with CyanogenMod, which instantly filled it with apps2sd data, swap files etc...

kguciek said:
But it wouldn't erase the whole system partition, so there could still be some files left.
Click to expand...
Click to collapse
No, that's why you wipe from recovery before installing.

unfnknblvbl said:
No, that's why you wipe from recovery before installing.
Click to expand...
Click to collapse
Actually wiping only erases the data partition, not the system one.

fastboot erase system -w

carz12 said:
fastboot erase system -w
Click to expand...
Click to collapse
Right, but it isn't possible for users with unmodified SPLs.
Actually, you can just flash a image of an empty yaffs filesystem to system partition (it's just a few blocks at most).

Interactive updates?

Just throwing an idea out there, and since it's for developers (specifically people who make their own recovery images) I assume this is the right section.
Since we have 'control' over the recovery image on our phones, would it not be possible to add a little script to an update.zip that a suitably modified recovery image could extract and run to interactively prompt the user for various Rom options? I'm thinking specifically of kernel choices, but it could be extended to almost anything that needs to be done prior to booting the installed image.
Imagine installing a rom, and during the install you got a little menu like this:
1: RamHack, BFS Kernel
2: RamHack, CFS Kernel
3: No-RamHack, BFS....
etc...

inefficient, it adds extra baggage to rom, and more things can go wrong. what would you rather downlaod a 90mb file or a 110 mb file.

Which would you rather download, one 110MB ROM or 2 90MB ROMS?
I'm pretty sure there's more than a few people who'll download different variations of the same ROM so they can see which is faster, how much easier would it be to just download one thing and then choose which options you want in there without downloading anything else.

I believe it is entirely possible. As a matter of fact, I was working on a ROM project that would have an interactive installer from the update.zip that would selectively install different features, apps, customization, themes, etc., based on the recovery menu application. It would use a lot of the /cache for temp space, though, as the installer application and its resources and configuration file, and later, the necessary parts of the ROM itself, would need to be unzipped before the install can run, if I recall correctly.
Does anyone have a good link to a reference for the command syntax for the /META-INF/com/google/android/update-script file? I'll go search for it in a few moments myself. I could probably make a simple ROM installer that chooses between ROM X and ROM Y based on a key input, as a proof of concept. I'll test it myself, I don't really mind half-bricking my device for science. (As long as I don't need to touch the SPL/Radio, that is.)
Update: Some creative searching finds me this:
JesusFreke said:
Assuming you mean update-script in an update.zip update, you will need to either look at existing update-script files for an example of the syntax, or look at the source of the recovery program in the android source
Click to expand...
Click to collapse
There's also a "make-update-script.c" file I'm seeing here and there, I'm trying to find the file in the Android source.
Update 2: From install.c at donut from cyanogen's android_bootable_recovery:
Code:
#define ASSUMED_UPDATE_SCRIPT_NAME "META-INF/com/google/android/update-script"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
and in commands.c, toward the bottom at register_update_commands is all the commands defined, and above that are all the functions they carry out.

sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.

markolo25 said:
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
Click to expand...
Click to collapse
Well, on the 32B platform with the Death SPL (my phone) we have the following partitions of the internal NAND memory (mtdblock*) from the df and mount command:
NAND 3: /system 92160kb - OS partition, static and read-only
NAND 5: /data 91904kb - User, system config, app config, and apps (without a2sd)
NAND 4: /cache 30720kb - OTA cache, Recovery/update config and temp
And I'd assume NAND 1 and 2 are the kernel, ramdisk, and bootloader config.
So the ROM wouldn't exceed 92MB installed (most leave some room in /system for hacks and updates). And the update process doesn't ever really "flash", per se; it just formats, copies files, and sets permissions and initialization configs, like Windows or Mac.
So the files that are common to the different ROMs being packaged don't need to be duplicated, only the ones that are changed (like a boot.img, or 32A/B compatibility, or different apps). The update script and chooser menu will decide which files to copy. Meaning the ROM package in and of itself shouldn't really need to exceed 128MB, even if choosing from a wide variety of platforms. And upon installation, the system might take less than 32 MB.

yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.

Deicist said:
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Click to expand...
Click to collapse
I could download them all, and find the differences of each. It would be cool if a ROM like this were available in a single download, from which you would choose the content from the device before flashing.
Also, inspired by talking about this, I wrote up a guide on the update-script in the package file. It's still not finished, but it'll be the only guide available for that syntax yet (trust me, I couldn't find one myself ). Link's in my sig.

I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/

how big of a ROM are you thinking about?

There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?

jmhalder said:
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
Click to expand...
Click to collapse
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
domenukk said:
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
Click to expand...
Click to collapse
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.

TylTru said:
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
Click to expand...
Click to collapse
You could just have flashed the original rom without wipe.
Would be a step forward if you could simply put roms and additional files in folders... maybe even whole zip files containing some updates and an xml like file to describe them. This would guarantee compatibility with earlier boot images (just unpack the updates in the zip). Tar might work better than zip as it is not compressed thus faster afaik.

http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.

TylTru said:
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
Click to expand...
Click to collapse
This is pretty awesome. I was going to say, we could easily run bash scripts but this is so much better.
This needs to be merged with both Amon_ra's recovery and the new 2.x based recovery...

[ROM][1.6][1.0.0]DreamServer (2013-02-02)

Introduction
The DreamServer ROM makes the T-Mobile G1 (HTC Dream) a low-powered headless Linux server. The DreamServer ROM provides only the essential services and libraries required in order to start ADB and Wi-Fi. There is no Dalvik (and thus no Android user interface), which maximizes the resources available for server use.
WARNING
The DreamServer ROM is only intended for use by those comfortable with Linux. Once the DreamServer ROM is installed you will no longer have an Android GUI or user interface of any kind, and you will not be able to run standard Android applications or even USB-mount the SD card. The only device interaction you'll get is via ADB (and of course your custom recovery image).
Download
dreamserver-1.0.0-build.tar.gz (11.6 MB)
Revision History
1.0.0, 2013-02-02, dreamserver-1.0.0-build.tar.gz (11.6 MB), http://kidsquid.com/files/dream/dreamserver-1.0.0-build.tar.gz
Initial release
Prerequisites
Rooted T-Mobile G1 (HTC Dream) with custom recovery image that has the ability to restore nandroid backups.
Verified working adb connection via USB cable.
SD with a FAT file system (not ext2). The DreamServer ROM uses fsck_msdos to check the SD card before mounting it.
Wi-Fi access point.
Familiarity with Linux and shell scripts.
Installation
Meet all the prerequisites in the previous section.
Perform a nandroid backup and make sure you also have an update.zip on the SD card for whatever boot ROM you are currently using. Due to the extremely limited nature of the DreamServer ROM (see the WARNING above), you'll want to formulate your escape route now.
Under your existing rom, go to the Wi-Fi settings and forget any networks that you will not be using. Verify that Wi-Fi connects to your desired network.
Copy /data/misc/wifi/wpa_supplicant.conf from the phone to the root of the SD card as wpa_supplicant.conf. You'll need this in order to connect to Wi-Fi.
Copy the dreamserver-x.x.x.zip to an SD card, and install the ROM via your custom recovery as normal. No wiping of the internal DATA or CACHE partitions are necessary, as these are not mounted by the DreamServer ROM.
Reboot the phone.
When the device boots, it will turn off the backlight during init so you know that it did not hang. Wait for a while (around 30 seconds) and access the device with adb shell.
Customize the installation by adding init.sh and cleanup.sh scripts to the root of the SD card. See the "Run-time Configuration Files" section in the README file.
When you want to reboot, use the reboot command. Note that /system/bin/reboot is a shell script that runs cleanup tasks prior to rebooting. If fifosh is running, you can also reboot cleanly from within a chroot jail: killall -USR1 fifosh
Please see the README included in the tarball for additional information (key locations and files, how-to's, rebuilding the ROM, etc).
The tarball also contains example configuration files for a Debian chroot environment that sets the time with NTP and starts sshd and lighttpd.
Credits and Copyright
DreamServer was created by Jeffry Johnston, 2012.
This ROM was originally based on a 1.6 (Donut) ROM by dwang that I found to be reliable. My filesystem modifications are extensive, but the
kernel and busybox from that ROM are used unmodified. Source:
Thread: http://forum.xda-developers.com/showthread.php?t=567023
Title: [ROM][32B/Dream][Dec23][Dwang][Donut][Speed and Stability][v1.17.1]
Filename: dwang-v1.17.1.zip
Download: http://files.androidspin.com/downloads.php?dir=dwang/ROM/
Existing programs and files are copyright their respective owners. Any customizations that I have made are released to the public domain, except for the tools programs I wrote, which are released under GPLv2.

Hey cool! I doubt I wold use this, just currently don't have a reason, but its awesome to know its here! I'll test it out though as I'm curious what all could be done here, thanks!
Sent from my Nexus 7 using xda premium

demkantor said:
Hey cool! I doubt I wold use this, just currently don't have a reason, but its awesome to know its here! I'll test it out though as I'm curious what all could be done here, thanks!
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Thanks for trying it out! I expected the audience might be pretty small for this, but it gave my old phone a new lease on life, and I decided it was worth sharing. I often do a lot of small-time serving of web pages, IRC bots, and such. Nothing that requires a powerful machine or much bandwidth, so I didn't want to leave my main system on all the time. With this I have a completely silent server that uses a minimum of power. And of course it was fun learning more about my favorite Android device.

Thank! I was looking for something like your rom for my little log-what-and-where-my-car-does-with-obd2-and-gps-project Downloading right now You've just made my day

How was this done?
This is a very interesting project, how would one go about making this? like what files to mess with to remove JIT and other things?
Good Job @calamari

Wow. I just have to tear this thing apart and examine its innards.
I've used a HTC mytouch as a server before, but didn't take the time to rip dalvik out. Seemed like too much work that would lead to replacing a lot of functionality with shell scripts, and saying my coding skills are sub-par is an extreme understatement
Sent from my Evo V 4G using Tapatalk 2

Wow this sounds pretty awesome. Would you by chance be able to make a guide so I can do this with my heroc?
Sent from my HTC One V using xda app-developers app

Really great thing!
Just one questions:
Is it possible to access the camera?
I think about setting up a little wireless ip cam.
dadoc

KShion619 said:
This is a very interesting project, how would one go about making this? like what files to mess with to remove JIT and other things?
Good Job @calamari
Click to expand...
Click to collapse
whoshotjr2006 said:
Wow this sounds pretty awesome. Would you by chance be able to make a guide so I can do this with my heroc?
Sent from my HTC One V using xda app-developers app
Click to expand...
Click to collapse
I don't remember the full process (lots of trial and error and learning). However, you can download dwang's original ROM and compare his files against mine to determine the changes made. Full sources are included for any of my custom additions.
dadoc said:
Really great thing!
Just one questions:
Is it possible to access the camera?
I think about setting up a little wireless ip cam.
dadoc
Click to expand...
Click to collapse
I would assume so, but I haven't attempted it. There are several files in /dev that seem camera related: /dev/pmem_camera and /dev/msm_camera/*. Under Dalvik, you could try writing a program that replaces those and saves the I/O to files for analysis.

Blob utility for AOSP-based ROMs

https://github.com/JackpotClavin/Android-Blob-Utility
The purpose of this program is to help AOSP-based ROM developers quickly and easily find out which proprietary blobs need to be copied into the ROM's build, or built using source. How the program works is you do a /system dump into a folder on a Linux computer. Then you make the program using the 'make' command; then you can run it.
First off, the program will ask you what the sdk version of the /system dump you pulled happens to be. For example, if your /system dump is Android 4.3, and intend port a 4.3-based ROM, then enter 18 and press enter.
When it prompts you for location of the /system dump you pulled, if the location of the build.prop of the /system dump is under:
Code:
/home/user/backup/dump/system/build.prop
then just use:
Code:
/home/user/backup/dump/system
The program will now ask you for your device's manufacturer's name, and the device's name. For my Verizon LG G2, I entered "lge" and "vs980" respectively.
The utility then will ask you how many files you wish to run through the program. In the case of my LG G2, the KitKat build requires two main proprietary camera-related libraries to run (/system/bin/mm-qcamera-daemon and
/system/lib/hw/camera.msm8974.so).
So I typed in 2 and pressed enter (because I'm running two proprietary files through the program)
Then simply typed in:
Code:
/home/user/backup/dump/system/bin/mm-qcamera-daemon
and pressed enter and it printed out *every* file needed to get /system/bin/mm-qcamera-daemon running (the file might be proprietary, or it can be built from source).
Then it asked for the final proprietary file, so I simply typed in:
Code:
/home/user/backup/dump/system/lib/hw/camera.msm8974.so
and pressed enter and it printed out *every* file needed to get /system/lib/hw/camera.msm8974.so running (the file might be proprietary, or it can be built from source).
An example usage of this program can be found here: https://raw.githubusercontent.com/JackpotClavin/Android-Blob-Utility/master/Example_Usage.txt
That's 106 proprietary blobs done in a flash!
The beauty of this program is that it's recursive, so if proprietary file 'A' needs proprietary file 'B' to run, but proprietary file 'B' needs proprietary file 'C' to run, which in turn needs 'D' to run, then simply entering proprietary file A to run will print out all A, B, C, and D nicely formatted so that you can simply copy the output and place it in a file under vendor/manufacturer/codename/codename-vendor-blobs.mk file in your AOSP build source tree's root.
Another great thing about this program is that it doesn't just catch the libraries needed to satisfy the linker, but rather, it will also print out those libraries that are called within the actual code of the library itself, like:
Code:
dlopen("libfoo.so", RTLD_NOW);
libfoo.so is not marked as a shared library, so the linker won't complain that libfoo.so is missing, and there might be no sign that libfoo.so missing and needed, but when it's time for the daemon or library to run, it won't show any sign that something is wrong, until you see that it doesn't work. This program will catch and display that libfoo.so is needed.
So basically:
1. Extract /system dump image
2. Tell program the SDK version of your /system dump
3. Tell program the location of your /system dump
4. Tell the program your device's manufacturer's name
5. Tell the program your device's codename
6. Tell program how many files you wish to run through the utility
7. Tell program the location of the file(s) you wish to run through the program.
8. Copy the output of the utility to a text file under vendor/manufacturer/codename/codename-vendor-blobs.mk

reserve

Hi,
I'm a noob and don't worry about my silly question.
I'm trying to build my first cm-rom and tested your tool. Thanks a lot for your work, it worked for me.
I'm a little bit curios about your point 5. Where can I find all the files I need for my own source-tree/device?
It would be nice if you can give me a hint.
Thanks a lot and greetings from germany

Greetings from the US
Do you mean the device folder the ROM? You can look at similar devices to your device and see what they did and make the changes to build Android.
This is the device folder for the Nexus 5 -> https://android.googlesource.com/device/lge/hammerhead

This tool is under-recognized. I think it's a really great way to find which blobs are dependencies!

Codename13 said:
This tool is under-recognized. I think it's a really great way to find which blobs are dependencies!
Click to expand...
Click to collapse
Thanks! Are you developing a ROM? Let me know if it helps!
Sent from my LG-VS980 using XDA Free mobile app

Could this be updated to Lolipop?

2GigayteSD said:
Could this be updated to Lolipop?
Click to expand...
Click to collapse
What do you mean? I added support for SDK version 20 if that's what you're asking.
Sent from my LG-VS980 using XDA Free mobile app

Does that mean I can port AOSP to any device just by getting all the necessary blobs? I'm not sure but I'm trying to port Lollipop to my device but I don't really have a clue how to do it/what's needed to do it. Will this be useful for me? Thanks.

cikoleko said:
Does that mean I can port AOSP to any device just by getting all the necessary blobs? I'm not sure but I'm trying to port Lollipop to my device but I don't really have a clue how to do it/what's needed to do it. Will this be useful for me? Thanks.
Click to expand...
Click to collapse
It helps with making ROMs for devices that don't have support (either the model is brand new or the device never gained AOSP ROM support for whatever reason)
Basically, in the early stages of porting ROMs, certain things won't work (graphics, camera, radio) and this is mostly due to not having the correct proprietary files needed for the OS to interact with the hardware. The proprietary files have dependencies (they rely on other libraries, which in turn may rely on other libraries, and so on and so forth until all proprietary libraries are satisfied).
In the case of my LG G2, there were a total of 92 proprietary files that needed to be pushed to the device in order to get just camera working. Instead of pushing one library at a time and getting a logcat or strace dump of what the daemons are calling or depend on, I wrote this program to recursively search for all proprietary libraries needed to satisfy a proprietary library (or in the case of the camera for my G2, there were two proprietary libraries needed that required those said 90 other proprietary blobs).
So rather than pushing libraries, (then gathering logs and stracing) and hoping that the one you just pushed is the one that will get your camera, radio, etc to work, you run your known proprietary daemons or libraries through this program and it will print out the necessary libraries to get it working, in a fraction of a second

Can you go through the actual "porting" process because from what I understand you have done it? If I'm correct to port a ROM you need to have working ROM from other device? If yes, does that device have to be same manufacturer? Lets say I do have working AOSPA kitkat for my device so I need to get AOSPA lollipop and exchange the certain files and then I'll able to run it? Once again if it's like that then I use your tool and get necessary blobs? I don't have a clue about this stuff, I only build ROMs but now time has come that my device is unsupported so can you give me some tips, thanks.

This is interesting. Going to have to try this out tomorrow.

cikoleko said:
Can you go through the actual "porting" process because from what I understand you have done it? If I'm correct to port a ROM you need to have working ROM from other device? If yes, does that device have to be same manufacturer? Lets say I do have working AOSPA kitkat for my device so I need to get AOSPA lollipop and exchange the certain files and then I'll able to run it? Once again if it's like that then I use your tool and get necessary blobs? I don't have a clue about this stuff, I only build ROMs but now time has come that my device is unsupported so can you give me some tips, thanks.
Click to expand...
Click to collapse
If you don't have a clue then dont do it, please! Work your way up. First step in this hypothetical is to wait for aospa 5.0

Thanks a lot for this tool
just one thing.. i cant get the blobs for my wireless (wl12xx)
Rest all done

andynoob said:
Thanks a lot for this tool
just one thing.. i cant get the blobs for my wireless (wl12xx)
Rest all done
Click to expand...
Click to collapse
Is it possible that each wl12xx library only relies on AOSP libraries (has no dependencies?)
See if they can be built from source!
Sent from my LG-VS980 using XDA Free mobile app

JackpotClavin said:
Is it possible that each wl12xx library only relies on AOSP libraries (has no dependencies?)
See if they can be built from source!
Sent from my LG-VS980 using XDA Free mobile app
Click to expand...
Click to collapse
Manufacturer hasnt provided the source code(Kernel) . Anyways thanks a lot for this tool :good: :good:

how to use it?

by reading the detailed instructions?
Sent from my LG-VS980 using XDA Free mobile app

JackpotClavin said:
by reading the detailed instructions?
Sent from my LG-VS980 using XDA Free mobile app
Click to expand...
Click to collapse
should we adb pull /system first?
*edit
I did it! but where is the directory out?

J,
You are a life saver ! Subscribed. Will add link of thread to my signature. Will dance happily for some hours! :good:
Will seek therapy. :silly:
m