Related
Well, I was seeing that some times people just don't like to manually make scripts, so I had the iniciative to make this software, and after weeks of no sleep, here you go.. I hope you guys like it!
Features:
Installable, now you can choose any folder on PC for building zip! Removed since 1.2
Easily build update scripts for Edify script (Used by most of ClockWorkMod Recovery's)
Configuration for compression
MD5 Calculation for Created Zips
Read from file
Hotkeys
Smart functions (like automatic placeholders for empty system folders only)
Non-repeatable options prompt (for example, formatting data twice)
Device selection (we'll need devices plugins )
Manual edition
Default symlinks for toolbox and busybox
Easy use for starting users
More!...
Simple instructions
Please report bugs, and remember that you need to have java installed for run this, and if you're on windows vista/7, run as administrator
This is a little video when I was building last options, now it's more complete and fast
Cheers,
D4.
10.03.2012 - 1.2r1
Fixed a LOT of bugs
Non installable again
Added EVO 3D prebuilt
Revamped logo, and Customizable themes on options
15.08.2011 - 1.01r2
Fixed this bug, thanks to darkstep for reporting
Improved zip method
13.08.2011 - 1.01r1
Now installable!
Output folder now it's on installation folder
Selection of external folder
Read script from zip
Added more hotkeys
Custom zip comment
Fixed bugs
08.08.2011 - 1.0r2
Implemented location of working directory (now you can work out of update folder)
Fixed bugs
07.08.2011 - 1.0r1
Initial Release.
sweet tool thanks
Excellent job!!!. This app is excellent, now evertbody can make custom zips.
Simple instructions for everybody to build zips:
Our work Folder will be called /update by default, and Update zip maker will create this folder on startup (you can change working folder). Also Update Zip Maker zip this folder when you press "Build package". *NEW* Now you can change working folder!
Copy files to be modded on selected place (for example, if I want to mod /system/build.prop, I'd put build.prop inside /update/system/ folder, which will create Update Zip Maker software) //also something interesting, If you press "Extract system" button, Update Zip Maker will create /system folder, inside /update, and the same for data
Mount our filesystem (for build.prop case, then we need to mount system)
OPTIONAL: Add some notification to user, like "installing build.prop"
Extract files (for build.prop case pressing Extract system)
Set permissions(for build.prop case 0 0 0 644)
Push zip to phone, install and enjoy!
This program is the bestI think this will be usefull for all devices who use ClockWorkMod Recovery so it will be greate to have teseter's with difrend device
btw D4 you are rocking exelent work
EDIT: hey is there any option that you add permissions for framework, bin, xbin, system?
i think when you press Set permissions it pups up like it is but there would be extra space that you just chose perms like for framework
Code:
(0, 0, 0755, 0644, "/system/framework");
this is just my proposal
Eyama said:
This program is the bestI think this will be usefull for all devices who use ClockWorkMod Recovery so it will be greate to have teseter's with difrend device
btw D4 you are rocking exelent work
EDIT: hey is there any option that you add permissions for framework, bin, xbin, system?
i think when you press Set permissions it pups up like it is but there would be extra space that you just chose perms like for framework
Code:
(0, 0, 0755, 0644, "/system/framework");
this is just my proposal
Click to expand...
Click to collapse
for folders like framework you can use "set permissions recursively"
btw, guys, could you press "sumbit to portal", on the top of first post, so everybody can see this please?
Edit, new version it's up, enjoy!
This program like a charm ^^ ,very simple and useful
thanks alot D4 )
This program doesn't create "update-binary", it is a bug or it is volontary ?
EDIT : My mistake ! I didn't use this software correctly... Sorry It work like a charm
Very good job ! Great app
New version it's up!, now installable!, enjoy new features!.
excellent job D4
you're the man this is wery good
First Thanks for Great tool.It's small and easy.
I make an update.zip to install an application.Here is the script:
mount("yaffs2", "MTD", "userdata", "/data");
ui_print("Coping app");
package_extract_dir("data", "/data");
set_perm_recursive(0, 0, 0755, 0644, "/data/app");
Problem is when i open the application it Force close.
Please Help me.
nishan432 said:
First Thanks for Great tool.It's small and easy.
I make an update.zip to install an application.Here is the script:
mount("yaffs2", "MTD", "userdata", "/data");
ui_print("Coping app");
package_extract_dir("data", "/data");
set_perm_recursive(0, 0, 0755, 0644, "/data/app");
Problem is when i open the application it Force close.
Please Help me.
Click to expand...
Click to collapse
Are you sure problem isnt with the app?
also try
set_perm(0, 0 , 755, 644, "/data/app/yourapp.apk")
set_perm_recursive it's for whole folders!
why do i keep getting this message
i set my working folder inside the folder is system/etc/init.d/ and the script i wanna run,i have tryid everything
darkstep said:
why do i keep getting this message
i set my working folder inside the folder is system/etc/init.d/ and the script i wanna run,i have tryid everything
Click to expand...
Click to collapse
Working folder it's main folder, that means /somefolder, you're trying to use /somefolder/system/etc/init.d, then you just need to use main folder, that means, working folder it's where you can see "META-INF", "system", "data", etc...
omg not working for me im not that big of a newbie
darkstep said:
omg not working for me im not that big of a newbie
Click to expand...
Click to collapse
I don't understand you, can you tell me all steps you followed?, also did you run as admin?
edit: and btw, we still don't have your device prebuilt (htc wildfire), can you test with u20?.
i will make a video and post it on youtube later
here is the video,not that great quality,i was in a hurry
Do I need net framework to run this? I'm on XP SP3 and when I try to run nothing happens. Tried opening as admin, no dice.
Hello, Developers.
I'm 15-year-old Korean junior Android Developer. Then, please understand my bad English... :-(
In the world except for Korea, there are many Galaxy Ace users and developers. But in Korea, there are only few users, and no developers... :-( So I've begun to develop because I use Galaxy Ace now. A few days ago, I've made Galaxy Ace Deodex Rom because there is no Rom or Kernel in Korea... :-( I applied the Rom what I've made, but it was no change. If I made it wrongly, it wouldn't be installed in Recovery. I think updater-script file is correct. Please check updater-script command in my Rom! Here is updater-script command.
delete_recursive("/system/app");
delete_recursive("/system/framework");
package_extract_dir("system", "/system");
set_perm_recursive(0, 0, 0755, 0644, "/system/app");
set_perm_recursive(0, 0, 0755, 0644, "/system/framework");
↑ I wrote on Ubuntu(So, There is no Unicode Problem). In both app and framework folders, there are deodexed apk or jar files.
Please notice me what incorrect. And please advise me what shoule I do. I believe that foreigners are kinder than Korean and better(?) at Android Development than Korean!
I'll wait you guys' replying. I am very expecting your replyings now^^ I wish it is solved!
Thank you for reading my bad English!
Happy New Year~~ and Good Luck!! ^^
Perhaps a better place to ask is in the Android Development forum:
http://forum.xda-developers.com/forumdisplay.php?f=1167
Did you mount /system before doing this ?
Btw annyeong (is that how you Koreans greet ? I learnt them from Girls' Generation)
Herpderp Adreno + Tegra.
A little tip to debug CWM operations:
Before applying anything, login the phone (adb shell) after CWM is started and type:
Code:
tail -f /tmp/recovery.log
Then try to apply your zip and see what the terminal prints.
As EmoBoiix3 already suggested, you should also type
Code:
mount
to see, if everything is mounted correctly.
^^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
shibumi77 said:
Perhaps a better place to ask is in the Android Development forum:
http://forum.xda-developers.com/forumdisplay.php?f=1167
Click to expand...
Click to collapse
no it isnt
general forums are for questions
Long ago, I said I'd start working on a high-level guide to creating firmware for one's own use (or possibly even eventually releasing to the wild). The idea was to make a high-level guide suitable for those who are comfortable with a Linux commandline but who might not be familiar with Android userland and tools available for working with firmwares.
So with this - I'm going to go through the steps I went through to create the deodexed XWKL1 firmware I've been using for the past two weeks, documenting it with notes as I go along about unusual "gotchas" that aren't necessarily in the documentation for the tools used.
Once I've gotten to the point where I have created a usable firmware, I'll post it here for consumption. Then I'll figure out what to do next - I've been lazy and happy with just using JKay mods lately.
Up next (after I reserve some posts): Deodexing
Obtaining firmware and deodexing
The best place to find I9100 stock firmware images for deodexing is, in my opinion, Intratech's thread in the I9100 Original Android Development forum. This thread is at:
http://forum.xda-developers.com/showthread.php?t=1075278
For the purposes of this guide, I'm originally going to use the XWKL1 download.
The next thing you need (in addition to a Linux box and the knowledge of how to use it...) is dsixda's Android Kitchen. While kitchens are generally frowned upon by firmware maintainers, deodexing manually is a massive pain in the ass and usually using dsixda's kitchen for this purposes is considered OK. To paraphrase gtg465x: "Deodexing with it is OK, but anything more and the ROM gods will frown upon you". Some of the other features of the kitchen like preintegrating busybox and rooting have issues - namely that they often inject old versions of busybox/su.
While the kitchen officially is supported on Windows, I cannot help you with any Windows-specific issues - you're on your own.
To get dsixda's kitchen, start with his GS2 thread at:
http://forum.xda-developers.com/showthread.php?t=1227549
I am going to use the latest version as of the time of this writing, which is 0.188
Extract the kitchen somewhere in your filesystem - I will refer to the directory unzipping the kitchen creates as $KITCHEN_ROOT
Extract factoryfs.img from the stock firmware TAR you downloaded earlier - you don't need anything else. You may need to fix its permissions by making it readable:
Code:
chmod a+r factoryfs.img
Place factoryfs.img in:
Code:
$KITCHEN_ROOT/original_update/
Start the kitchen by going to $KITCHEN_ROOT and running the menu:
Code:
./menu
Choose 1) Setup working folder from ROM
Accepting all of the defaults should work. It'll complain about not finding any kernel or cache - but this is OK. Neither of these are really needed as Hellraiser will take care of these later. The kitchen will ask for root permissions (sudo password) to extract the firmware contents. Say yes when it asks about a fake boot.img
Next, we deodex. Choose 0) Advanced Options
Choose 11) Deodex
Choose b) to deodex both /system/app and /system/framework
This will take a while. Go do something else. For example, I'm going to take a shower. (You don't need that much time - but I need a shower. )
Take a careful look at the last few lines of results here. If the deodex job worked perfectly, you should see no failure reports and 0 odex files in /system/framework or /system/app. However, for I9100 XWKL1, three .odex files will remain in /system/app, and you will see the following error:
Code:
Could not deodex the following (you can try to deodex these files again):
Maps.odex Phonesky.odex VoiceSearch.odex
Sometimes a second deodex pass will fix these, but not for these three files for XWKL1. You need to find a different way to fix them. Now I've heard that some advanced options like API Level mangling can fix these errors, but we're going to go with a simpler and easier approach for now.
We are now going to enter our last steps of the kitchen before we switch to manual maintenance of the firmware:
Return back to the main menu of the kitchen.
Choose option 99) Build ROM from working folder
Go ahead and use the defaults EXCEPT when it asks you to sign the firmware - note that this will zipalign all files (this is why zipalign scripts in init.d are rarely useful - on any decent firmware everything should already be zipaligned.)
Say no when it says to sign the firmware - since you're going to be making manual changes to the results, the signature will be broken.
You will now have a ZIP file in the following location:
Code:
$KITCHEN_ROOT/OUTPUT_ZIP/
DO NOT FLASH THIS FILE. IT STILL HAS SERIOUS ISSUES THAT REQUIRE REPAIR.
On to the next step... We take this firmware that is high in fiber and digest it a bit ourselfs, preparing to plop it out.
Fixing failed deodexes and debloating
If you were lucky, the firmware fully deodexed properly. However, often, it won't. For example, as covered in the previous post, with XWKL1, three files won't deodex. We will go through the process of manually dealing with these files in this post.
First, take the ZIP you obtained from the previous step, and unzip it to its own working directory somewhere. I will refer to it from now on as $FIRMWARE_ROOT .
You will find three APKs with .odex files in the following location for XWKL1:
Code:
$FIRMWARE_ROOT/system/app
Remove all three APKs and associated .odex files - these files are not useful to us. We now have to deal with the removed files.
Phonesky.odex
When I first saw this, I thought "WTF? I've never seen that before." - Time to Google it. It turns out that at some point, Google renamed the Market APK. It used to be Vending.apk, now it's Phonesky.apk - if we don't do something about this, the firmware will have no Market! So it must be fixed.
The good news is - The Market gets auto-updated frequently. As a result, we can obtain a replacement, AND that replacement is likely to be newer! What we need here is a device that is already running with a functioning Market.
Connect to your phone with ADB, and start navigating through directories. Downloaded apps are in the following location:
Code:
/data/app
Look for a Market APK there. (I need to take a few minutes to nandroid back to a different firmware - as mine currently has the latest market in /system, I don't have one in /data/app to pull.) OK, I'm on my UCKK6 Nandroid now, so, the Market is at the following location for me:
Code:
/data/app/com.android.vending-1.apk
Let's pull that into the right location in our firmware:
Code:
cd $FIRMWARE_ROOT/system/app
adb pull /data/app/com.android.vending-1.apk Phonesky.apk
OK, we've fixed the Market AND integrated the latest update!
Next up, VoiceSearch.apk:
While it is less critical than the Market, most users won't like a firmware without Google Voice Search. As this never gets auto updated and is not Market-downloadable, it's harder to find a working copy. Try deodexing other firmware bases (such as XXKI3) to get this file, or pull it from a firmware that has it properly deodexed. I grabbed mine from VillainROM 3.0 (Thanks Pulser!) initially, I'm going to try a different candidate before posting up my firmware this time around. This time, I'm gonna grab it from XWLA4. (Yes, after I finish with this guide based on XWKL1, I will be moving to XWLA4 to play with it. Also, yes - this file does deodex properly on LA4.)
Last, Maps.apk:
This is downloadable from the Market, so the safest thing to do is just remove it. However, you can use the same trick as with Phonesky.apk to grab the latest and greatest from an updated running system.
Code:
cd $FIRMWARE_ROOT/system/app
adb pull /data/app/com.google.android.apps.maps-1.apk Maps.apk
Note: If you outright remove Maps, you should also remove Street.apk - however if you are replacing Maps, you can leave Street.apk - it is often not in /data/app since it's updated far less frequently.
Removing Bloat:
Next, let's remove bloat. pulser_g2 has a great reference for what is safe to remove from I9100 firmwares at http://forum.xda-developers.com/showthread.php?t=1069924
First, disable OTA updates by removing:
Code:
rm wssyncmlnps.apk
rm syncmldm.apk
rm syncmlds.apk
rm fotaclient.apk
FM Radio is NFG on the I777, so kill it:
Code:
rm FmRadio.apk
SNS (Samsung's own social media integration) is a battery hog. Kill it, remove it all:
Code:
rm Sns*
rm SevenEngine.apk
Nuke the Hubs:
Code:
rm GameHub.apk MusicHub_10.apk ReadersHub.apk SocialHub.apk
Per ryude's post at http://forum.xda-developers.com/showpost.php?p=22719913&postcount=22, you can also:
Code:
rm $FIRMWARE_ROOT/system/lib/libnggame.so
Nuke the extra clocks - plenty of good ones on the Market:
Code:
rm DualClock.apk AnalogClock.apk DigitalClock.apk
Nuke Samsung's annoying panning tutorial:
Code:
rm PanningTryActually.apk
Nuke some other apps I never use, including all Samsung apps and widgets:
Code:
rm Kobo.apk Zinio.apk BuddiesNow.apk GenieWidget.apk PressReader.apk Samsung*
Live wallpapers are evil device-slowing battery eaters:
Code:
rm LiveWallpapers*
rm Microbesgl.apk
Some weird wifi file transfer stuff that is useless and starts a background service:
Code:
rm FTM.apk FTS.apk
Flashplayer can be installed from the Market:
Code:
rm install_flash_player.apk
Swype is 28 ****ing megabytes, I don't use it, and as I understand it, it sometimes conflicts with trying to update to newer versions. I was going to leave this in until I saw its size:
Code:
rm Swype.apk
rm $FIRMWARE_ROOT/system/lib/libSwypeCore.so
Some people will remove some of the DRM stuff such as SisoDrmProvider.apk - however the last time I tried to debloat DRM, I had some issues with even non-DRM videos. (Video player would hang on exit.)
At this point, we've fixed all of our failed deodexes and debloated. Now that we've digested that high-fiber kitchen product a bit, we can plop out our first flashable firmware image.
Code:
cd $FIRMWARE_ROOT
zip -r -9 ../PowerDump_XWKL1.zip *
This ZIP is actually flashable - if you wipe, flash this, then flash Hellraiser, you should have a working firmware. (going to test this now...) Note that with Hellraiser 0.3.1, you'll need to update to a newer Daily Driver (1/30/2012 or later) to get working Bluetooth HID. I'm going to put up 0.4.0 with DD 2/15-C later today. Note: If you want to flash one of JKay's themes, you must boot the firmware without the theme/mod at least once before flashing JKay. You may also want to flash one of ChainsDD's superuser packages - the firmware is not yet rooted.
Tested and uploaded - at this point in the process, this PowerDump will be your result - http://dev-host.org/I6C
Remember, it'll be a little rough, since you were digesting a high-fiber source and your system probably wasn't used to it, but it's still a good PowerDump.
Integrating Hellraiser and Flashing a Kernel
Integrating Hellraiser:
Actually, this one is fairly easy. We'll cover integrating the system aspects of it here, the remaining functions of Hellraiser (flashing kernel and modem) will be covered separately (kernel) or are irrelevant (modem - Hellraiser only flashes a modem because many I9100 firmwares include it - many people including myself believe modems should always be separate.)
Take either a Hellraiser ZIP file, or clone my github repo for Hellraiser at https://github.com/Entropy512/hellraiser_i777 - I strongly recommend looking through the commit history there to see what various changes were done and why. Some of them are just bringing in kernel updates, so you'll need to look through the kernel commit history around the data of kernel release to figure out important changes (like wifi tethering fixes in DD 12/21/2011 and BTHID fixes in 1/30/2012)
The root of this ZIP or the repo will be referred to as $HELLRAISER_ROOT - $FIRMWARE_ROOT is the same as in the previous post.
Copy all files from system/ in Hellraiser over the ones already in your deodexed firmware from the previous post.
Code:
cd $HELLRAISER_ROOT/system/
cp -aR * $FIRMWARE_ROOT/system/
The -a after the cp command means to "archive" (preserve as much file permissions and metadata as possible - although this probably doesn't really matter as the updater-script handles permissions), -R means to copy recursively (copy all directory contents, including subdirectories).
That's it - the system portion of Hellraiser 0.3.1 is complete. Hellraiser 0.4.0 will be a bit more complex when released, we'll get into this in a later post.
Adding a Kernel:
Flashing a kernel isn't too hard. Let's look at the updater-script that my Daily Driver releases use:
Code:
ui_print("Entropy's Daily Driver");
ui_print("2/18/2012 Standard Release - Part B");
show_progress(0.100000, 0);
ui_print("Flashing Kernel");
show_progress(1.000000,5);
assert(package_extract_file("zImage", "/tmp/zImage"),
write_raw_image("/tmp/zImage", "/dev/block/mmcblk0p5"),
delete("/tmp/zImage"));
ui_print("Thank designgears of Cognition X2 for the CWM kernel flashing example for I777");
ui_print("No more redbend_ua makes Entropy happy.");
Most of this is just user interface stuff - my show_progress lines are probably not quite right, but the worst case is they'll make the bar in CWM do funny things, no real damage.
Same for ui_print lines - they just print stuff in CWM. The real meat is this:
Code:
assert(package_extract_file("zImage", "/tmp/zImage"),
write_raw_image("/tmp/zImage", "/dev/block/mmcblk0p5"),
delete("/tmp/zImage"));
Place the zImage of the kernel you want to include in $FIRMWARE_ROOT/ and then add the above lines to your updater-script. Boom - your firmware will now flash a kernel. Maybe add some lines saying that you are flashing a kernel when you start - it's up to you.
Naming your firmware:
You can rename what your firmware displays in Settings->About Phone
Edit $FIRMWARE_ROOT/system/build.prop and change ro.build.display.id to what you want your firmware's name to be.
Fixing wifi region issues
Most I9100 firmware bases have the wifi region codes set for Europe. This can be overridden in Settings for 2.4 GHz wireless networks, but not 5 GHz wireless networks. The end result is that without modifications, I9100 firmware bases can only see 1-2 United States 5 GHz channels. Hellraiser does not handle this at the moment - I'm working on making Hellraiser 0.4.0 handle this issue.
Edit $FIRMWARE_ROOT/system/etc/wifi/nvram_net.txt and change the ccode from GB to ALL.
Change the ccode from GB to US in $FIRMWARE_ROOT/system/etc/wifi/nvram_net.txt_murata
At this point, 5 GHz wifi should work in the USA.
Adding Superuser (rooting your firmware)
This one is also simple. We're going to integrate the contents of ChainsDD's latest Superuser packages from his site: http://androidsu.com/superuser/
Grab the latest package, and unzip it.
Take system/app/Superuser.apk and put it in $FIRMWARE_ROOT/system/app/Superuser.apk
Take system/bin/su and put it at $FIRMWARE_ROOT/system/bin/su
Now edit your updater-script, first locate the following in your existing script:
Code:
set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
Now, after this, take the following lines from ChainsDD's Superuser ZIP and add them:
Code:
set_perm(0, 0, 06755, "/system/bin/su");
symlink("/system/bin/su", "/system/xbin/su");
This sets the su binary to suid root, and symlinks it to /system/xbin
Everything else needed is already handled by our updater-script, since Superuser.apk needs no special permissions.
Integrating busybox and bash
This is going to be fairly basic right now - When you integrated Hellraiser earlier, it included bash and busybox, however, busybox isn't installed by the updater-script.
This will change that, it's straight out of the Hellraiser package, add it to your updater-script just before unmounting /system:
Code:
set_perm(0, 0, 0755, "/system/xbin/busybox");
ui_print("Installing busybox update...");
run_program("/system/xbin/busybox", "--install", "-s", "/system/xbin");
Note that this busybox binary was not compiled properly, and as a result has DNS issues. Later on I'll include info on compiling it properly - but for 95%+ of functions it works as it is.
The end result is at: http://dev-host.org/XCB
Wanted to be the first to say I can't wait as I've been following you since I got here! Your my inspiration
Sent from my SGH-I777
....rubs hands together!
Sent from my GT-I9100 using XDA App
I am soooo looking forward to this!!!
Keeping my eye on this.
Sigh... wish people would start moving their uploads since multiupload doesn't work!
c0ldburn3r said:
Sigh... wish people would start moving their uploads since multiupload doesn't work!
Click to expand...
Click to collapse
Yea I was just noticed that one to.
For glory!!!!!
I've used Ubuntu in a VM to create a Webos Doctor back when I had a Palm Pre, this looks... Fun.
Can't wait, this should be awesome.
Miget be looking to cook something up in a few weeks.
I already got a name too, Jersey Shore Rom. That's the area of NJ Im from.
Stay tuned!
Thanks for the tutorial, Entropy.
Am I the only person who thought the title said **** Rom? Lol
Sent from my GT-I9100 using Tapatalk
Good stuff Entropy! I'll be the first to admit I am a linux noob.. but I installed Ubuntu a few weeks ago and have been playing around.. learning a little here and there. Looking forward to this and learning more about android and linux! Thanks
MysticKing32 said:
Am I the only person who thought the title said **** Rom? Lol
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
It does say it
I'm so stoked for this!
Sent from my SAMSUNG-SGH-I777 using Tapatalk
but Entropy... why do all this when you could just take someone elses rom from the i9100 forums, hellraise it, then post it here in our forums just like everyone else has been doing lately???
task650 said:
but Entropy... why do all this when you could just take someone elses rom from the i9100 forums, hellraise it, then post it here in our forums just like everyone else has been doing lately???
Click to expand...
Click to collapse
LOL. Well, I usually just ran VillainROM, but I found a nasty bug in XXKI3. Actually, my experimentation with KL1 or LA4 may lead to VillainROM 3.1 (I eval the raw base, Pulser perfects it.)
This is NOT going to contain anything for users to flash - this is for developers(or those who aspire and want to learn). This is a work in progress.
I want to make it clear that XDA nor the mods endorse or approve of this thread(well, they are allowing me to post it), but this is a concept that may be helpful for multiple reasons.
Please go easy on me, constructive criticism is welcomed, flaming is not. Do not post if you are not adding to the discussion or a developer asking a question. This is something I have been working on for a "rom" I will be putting out in a few days.. I just decided I would share the process, maybe others can help refine it.
Benefits:
If you build for multiple devices you can use this SAME flashable on those other devices and only need to edit the updater-script, prop edits that are device specific, and any system or apk's that are device specific! This could take 5 minutes or less to change AND upload!
It will work on ANY rom(for the same device) as long as you aren't modifying the things that rom specifically needs - and with this method it would be very rare that you would somehow break a rom.
You can still add files/apks, delete files you don't want, modify(rather than replace) the build.prop - technically you could create a flashable that turns stock into CM9 if you wanted to, but only then is a full ROM really needed.
Users can choose the rom they want and add your customizations(the entire community can use your flashable, rather than just a portion!)
It reduces the flashable filesize - rather than 100-400mb your flashable could be 4-20(depending how much you are changing).
It takes MUCH less time to flash, the recovery log will be shorter/easier to read, and it reduces the chance of errors(you are changing less).
Easier to track the changes since the flashable has been reduced to what is NEEDED.
This is an open source community - other devs and even users could look at your flashable and clearly see what you've done, how you've done it, so everyone benefits.
Easier to support - to make changes is EASY, faster zipping, signing, updating, uploading, etc.
You can choose to make it CONFIGURABLE - add #comments in the updater-script, the included build.prop script, or add a readme in the flashable that tells them what they can remove if they don't want it!
I'm quite sure there are MANY more reasons this is beneficial, but I'll leave it to you to decide..
Post 1 - Benefits, explanation, reasoning
Post 2 - Instructions and a soon a flashable example that I will publish
Post 3 = profit?!
First, there are totally different systems out there we can try to get running, CM9, MIUI, etc- this is when the very framework is absolutely different-- otherwise every rom we have RIGHT NOW is just a series of tweaks to the stock(like the leaked ICS) rom. We can argue that people just tweak what is there, or "develop" something new, but nearly everything is building on the concepts of something before- so let's do it right.
What makes a rom unique:
It is easier to keep track of changes(the /system will only have the changes you make, your updater-script will show you other changes, and any scripts you create will show the last changes) - so there shouldn't be "and other stuff I don't remember" in your changelog. This will also assure that there are less potential issues- you are ONLY changing specific things- troubleshooting these things are easier when you aren't including the entire modified flashable.
What you are trying to accomplish:
The main thing that makes a "rom" stand out from any other is the changes to the build.prop - you totally replaced it with something that is your own(or an adapted version hopefully giving proper credit to whoever's tweaks you are using): but they are using your "rom" if they have your build.prop and not someone else's. Everything else is deleting, copying, setting permissions, etc.
The goal: making it more open source
Until you build something totally new(Cm9, miui, etc), you are working with an open source platform, modifying, adding, deleting, scripting. Period. Admit that you are giving the base platform some tweaks, or a "flavor" that others will hopefully prefer.
If you are already developing, you know that with the correct updater-script you can add apks, delete what you don't want, over-write the things you want to replace- this includes theming and everything else you could want.. and usually you would include this in the full base rom, totally pre-configured. With a build.prop that is yours alone.
Conclusion:
Unless you are building an OS from scratch, or modifying it so heavily that it is more yours than it is not, giving the end users these options without wiping is the way to go. If they can flash your mods and then mine and end up with a better final product, how can this go wrong? This is open source, this is android, this is evolution.
Instructions:
First, keep track of all the changes you want to make - the better organized you are, the easier this will be. If you aren't even sure what all you did..
How to do it:
One of the main things you are changing by creating a total prepacked rom is the build.prop- perhaps you have tweak A, and I have tweak B, and those tweaks are different enough to change the users experience.. but why not combine them if possible? It IS possible.
Decide on the build.prop edits that you want to add/modify(you will NOT replace their build.prop) and modify the propEditor script as needed - if you build for multiple devices I would recommend you add the device specific ones at the end(with #comments) for easy modification/removal from script. You really only need to MODIFY the RO.whatever lines(because they are read only), everything else can be added to a local.prop in the /data folder
Create your updater-script as you normally would, as you know this does the main work - this will likely remain mostly the same, with just a few lines added for the scripts you need to modify the build.prop. Just make sure you delete what you would from the rom itself with the script
Rather than copy your /system /data or any other files into the rom you would normally be modifying, those are the only files you will include in the flashable - if this is done right it will make all of the changes you want without breaking anything.
If you want others to be able to understand/build upon your work you can add #comments or a readme in the above steps, then all users would have to do is remove the lines you instructed, re-zip(no need to sign if they use 7-zip or winrar) and then flash.
As said in the previous area, outside the build.prop you can make a small flashable that will change everything, but if you can MODIFY tweaks already in the build.prop, or add lines if they don't exist-- we would be creating a continual evolution of a better and better performing rom.. with feedback bad tweaks would get tossed, each developer adds their flavor, but users can flash what they want to get the performance they desire without the headache and confusion that comes with wiping everything of the developer they used before that. This will enable them to learn more about how and what we are doing with their devices, and they can provide feedback that makes it better for everyone.
The code(that may need work) to modify or add lines in the default build.prop is here:
(This may require testing, big thanks to tommytomatoe for all the help, original thread is here.)
Code:
#!/sbin/sh
# Build.prop editor script with basic sed commands
# tommytomatoe
# May 12, 2012
# mounting system as rw
busybox mount -o remount,rw /system
if [ $? != 0 ] ; then exit
fi
FILE=/system/build.prop
TMPFILE=$FILE.tmp
line1=ro.product.version
line2=ro.HOME_APP_ADJ
line3=ro.media.enc.jpeg.quality
#Add more line# formatted as above as needed to identify each prop
line1Arg=Classicv0.1.0
line2Arg=1
line3Arg=100
#Add more line$Arg formatted as above as needed for each prop change
lineNum=
#to add additional prop changes copy the lines between here
prop=$line1
arg=$line1Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
#and here and paste to the end, changing the $line# and $line#Arg to match what you've added
# to iterate over all the prop values you want to change,
# just copy and paste the code chunk or create a for loop.
# I will leave it to you to create a for loop
prop=$line2
arg=$line2Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
prop=$line3
arg=$line3Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
It may require some work, feel free to offer advice if you can help make it better), but you can make a few changes to that, and rather than replacing the entire system on a users phone, you are making YOUR modifications to make their device work better! Read the #comments above to see the different tweaks you are trying to make, and it will automatically either change the value, or it will add the line if it doesn't already exist in the build.prop
Profit?!
I understand many developers may think this would make it easier to "steal" your work, but as I said before, everything android is open source. Besides, with enough changes this makes it a TRUE rom, and it will be NEARLY as complex as the much larger file he would be uploading.
It could actually be profitable time/effort wise, ANY rom could be done with this as long as you tell them what base to work with.
Example of "profit"
Mike 1986.'s ARHD is on 10 devices, if you check, most of the features in one are in the rest of them. He has enough experience where porting everything over all of his changes to a new rom probably isn't that difficult for him(I'll bet he is VERY organized), but this would enable him to make a few changes to a propEditor script, the updater-script, remove or change out a few files.. re-zip and sign, upload, done.
This also takes out much of the opportunity for developer error or errors during flashing..
Doubt I'll need it.. but we'll see.
[Disclamer: Use the following at your own risk, I take no responsibility for the unrecoverable loss of any data as a direct consequence of using anything attached]
The following patcher(s) will modify the nand ramdisk for various functions, primarily enabling NativeSD support:--------------------------------------------------------------------
#1 NativeSD SD ramdisk to NativeSD nand ramdisk patch
#2 NAND (Non NativeSD) to NativeSD patch
#3 Boot.img (/also clk) patcher
#4 other devices ???
#5 FAQ
---------------------------------------------------------------------
NativeSD SD ramdisk to NativeSD NAND ramdisk
Things resolved by using nand ramdisk over sd ramdisk
Bluetooth issues
Changing rom name to whatever you want prior to install i.e for testing purposes (just need to change rom_name in install.sh and the one in the ramdisk will mirror it)
...
...
Instructions.
Removed the old zips, have attached just one, should run on linux, on device and during installation, needs a install.sh file with at least ROM_NAME=rom_name in it, and a copy of the nand ramdisk to be added into NativeSD folder or copied to /tmp (i.e during ROM _installation ) and to execute nativesd.sh (a copy of which is currently attached as well as being in the zip). Should work with nilfs2 and ext4 and should allow for easy adjustments and modifications to be made to the mount commands carried out in init.rc and/or mountfs.sh
Add a copy of nativesd.sh.txt saved as nativesd.sh to the downloaded and unzipped NativeSD folder and add to rom zip.
During ROM installation the NativeSD folder needs to be emptied to /tmp along with a nand ramdisk and /tmp/nativesd.sh needs to be run.
package_extract_dir("NativeSD", "/tmp");
set_perm(0, 0, 0777, "/tmp/nativesd.sh");
run_program("/tmp/nativesd.sh");and either send nand ramdisk to /tmp/ or add a copy to the NativeSD folder before installation.
The set up at the moment will leave the default NativeSD in tact and add two others, just rename them (or edit nativesd.sh to do so).
If using nilfs2 again two addition ramdisks will be added, the two created ones which will boot to nilfs2 and the original which won't boot as it's set to ext4, you may also need to edit install.sh (or mount_NativeSD.sh) so that it reads "mount auto" or "mount nilfs2" rather than "mount ext4".
Legacy Instructions:
Code:
NANDtoNativeSD.zip (will add another version)
[INDENT]This is a CWM(/recovery) zip, instructions are similar to Combi:
need to change install.sh to have the right rom_name at the top, and add the nand ramdisk to the NativeSD folder and install via recovery[/INDENT]
Combi
[INDENT]The zips marked ext4 and nilfs2 should make both sc and v versions and should work during installation and from running build (although that may need one line change). They should create initrd-nilfs-sc.gz and initrd-nilfs-v.gz or initrd-ext4-sc.gz and initrd-ext4-v.gz accordingly and thus can't be booted from until you rename them to initrd.gz.
[B]During ROM installation:[/B]
[INDENT]Copy the nand ramdisk (it should be ~200kb) into the NativeSD folder and copy NativeSD into the ROM zip
Edit the updater script by adding:
[B]package_extract_dir("NativeSD", "/tmp");
set_perm(0, 0, 0777, "/tmp/nativesd.sh");
run_program("/tmp/nativesd.sh");[/B][/INDENT]
before [B]package_extract_dir("system", "/system");[/B]
no other change needed so this should be universal
[B]During running ROM:[/B]
[INDENT]Copy NativeSD folder to sdcard, copy in nand ramdisk and create a text file called [B]install.sh[/B] with the words [B]ROM_NAME=writeROMname[/B] writing the rom name after =.
Open terminal cd into NativeSD folder and run script:
[B]su
chmod 777 nativesd.sh
./nativesd.sh[/B][/INDENT]
Let me know if there is a problem as I might need to change a few lines to get it to run on device - This is completely untested
(will also run on linux after a few minor changes i.e changing sbin to bin on first line and removing/changing the [B]cp initrd*.gz /boot*[/B] lines, will properly comment this in next version if/when the current ones need fixing
[/INDENT]
Modifying during Installation
[INDENT]1. Download the attached NativeSD.zip or NativeSD-sc.zip and have original NativeSD-ROM.zip to be modified
2. Unzip it and open nativesd.sh
3. Add the romname to the start of the script (the same romname that's in install.sh)
3. Add the NativeSD folder to a current NativeSD-ROM.zip
4. Edit the updater-script, by changing the following:
[B]ui_print("@ Installing System");
package_extract_dir("kernel/bootsd", "/boot");
package_extract_dir("kernel/kernel", "/boot");
package_extract_dir("kernel/bootsd", "/boot_dir");
package_extract_dir("kernel/kernel", "/boot_dir");
package_extract_dir("sdcard", "/sdcard");
package_extract_dir("system", "/system");[/B]
to
[B]ui_print("@ Installing System");
package_extract_dir("kernel/boot", "/boot");
package_extract_dir("kernel/kernel", "/boot");
package_extract_dir("kernel/kernel", "/boot_dir");
package_extract_dir("NativeSD", "/tmp");
set_perm(0, 0, 0777, "/tmp/nativesd.sh");
run_program("/tmp/nativesd.sh");
package_extract_dir("sdcard", "/sdcard");
package_extract_dir("system", "/system");[/B]
[I][SIZE="1"](this will vary slightly by rom)[/SIZE][/I]
5. Copy rom to sdcard and install via recovery[/INDENT]
Modifying during running NativeSD ROM
[INDENT]1. Download nativesd.sh.txt and nativeSDv1.1 attached
2. Obtain nand ramdisk from the NativeSD-ROM.zip (kernel/boot/initrd.gz for example)
3. Unzip NativeSDv1.1.zip
4. Rename nativesd.sh.txt to nativesd.sh and copy over the one in the NativeSD folder
5. Copy the nand ramdisk (initrd.gz) into the NativeSD folder
6. Copy NativeSD folder to device for example to /sdcard/Downloads/
7. Open terminal and run the following
[B]su
cd /sdcard/Downloads/NativeSD
ROM_NAME=AddRomNameHere
chmod 777 nativesd.sh
./nativesd.sh
exit
exit[/B]
This should modify the ramdisk and copy it to /sdcard/NativeSD and will leave the one in the romfolder as is, if it works great if not, replace the initrd.gz in /sdcard/NativeSD with the one in /sdcard/NativeSD/ROMNAME/
[/INDENT]
(If using nilfs2, you will also need to look in install.sh and change ext4 to auto)
Details
Confirmed working:
Booting to ext4
Booting to nilfs2 (using nilfs2 zips)
Untested:
Modifying from running build
Tested Working ROMs:
NexusHD2-ICS
PACman
MIUIJB
PA-HD2
sundawg
CM9ite 1.1 (QMA version won't work)
Versions
Releases with v will be based on marco.palumbi's method - adding mounts to init.rc
Releases with sc will be based on securecrt's method - using an additional script
Changelog -beta 1
nilfs2 and ext4 tested with same rom, nativesd.sh file removed from zip (as the other files with remain unchanged for the time being)
-------------------------------------
-nilfs-ext4-sc-v
Stripped down andcombined to the one zip
-------------------------------------
-ext4(4) and -nilfs2(4)
sc fixed
-------------------------------------
-ext4(3) and -nilfs2(3)
Bug fixes
-------------------------------------
-ext4(2) and -nilfs2(2)
Fix initrd.gz names with ext4 version,
tmp file copied into NativeSD (hopefully) for debugging purposes
------------------------------------
-ext4 and -nilfs2 versions
Seperate zips for the two file systems for now
Hopefully removed the need to have to manually change the rom_name by reading from install.sh (confirmed)
Completely untested
-------------------------------------
sc1.2
Should now be fixed and work with ext4 (and nilfs2 after removing some lines)
--------------------------------------
sc1.1
Tidy up and fixing issue reported here
--------------------------------------
v1.1
Tidy up
--------------------------------------
sc1 (NativeSD-sc1) :
Based on securecrt's code
EXT4 support
--------------------------------------
v1 (NativeSD.zip) :
Based on marco.palumbi's code
EXT4 and (untested) basic NILFS2 support
Credits: securecrt, Xylograph, marco.palumbi, ph03n!x, Kokotas,
Testers: Robbie P and jerrysue (for testing the alpha builds)
NAND (Non NativeSD) to NativeSD patch
Have attempted with BBCM7 (as I thought the updater script would be simple) but to no avail.
Also attempted with (the now pulled) SlimICS
Theoretically should just require: adding:
package_extract_file("kernel/install.sh", "/tmp/install.sh");
set_perm(0,0, 0777, "/tmp/install.sh");
run_program("/tmp/install.sh");
if file_getprop("/tmp/nfo.prop","NativeSD") == "true"
then
ui_print("@ Installing System");
package_extract_dir("kernel/bootsd", "/boot");
package_extract_dir("kernel/kernel", "/boot");
package_extract_dir("kernel/bootsd", "/boot_dir");
package_extract_dir("kernel/kernel", "/boot_dir");
package_extract_dir("NativeSD", "/tmp");
set_perm(0, 0, 0777, "/tmp/nativesd.sh");
run_program("/tmp/nativesd.sh");
package_extract_dir("sdcard", "/sdcard");
package_extract_dir("system", "/system");
to the start and adding the below to the end
endif;
delete("/tmp");
unmount("/ext4p");
unmount("/system");
unmount("/data");
modifying according to ROM, removing any yaffs/format references, and adding in a NativeSD folder (#1) and an install.sh
Boot.img (/also clk) patcher
Once NAND is done should be able to integrate mkbootimg scripts and allow flash boot and sboot
Other devices ???
Anyone willing to try let me know.
FAQ
Fixes Required:
NILFS2
NILFS2 support is currently attempted to be implemented by the following code:
Mount_Type=`mount | grep "nilfs2" | cut -d ' ' -f 5`
if [ "$Mount_Type" == "nilfs2" ]
then
sed -i 's/auto/nilfs2/1
/(NativeSD)/a \mkdir /nilfs\
mount nilfs2 /dev/block/mmcblk0p2 /nilfs' ns/init.rc
else
sed -i 's/auto/ext4/1' ns/init.rc (or ns/mountfs.sh with sc)
Have tried various combinations and added in other lines, to no avail.
Running mount | grep "nilfs2" | cut -d ' ' -f 3 on a running nilfs2 rom will return:
nilfs2
nilfs2
nilfs2
(there might be a fourth (can't recall), due to system, data and NativeSD being mounted as nilfs2)
Is there something I've overlooked? (Have tried with busybox mount | busybox grep | busybox cut)
Or can anyone see the mistake, it runs fine but $Mount_Type wont be reported as nilfs2.
I will post a workaround for nilfs2 but would rather have it integrated.
Edit not the workaround I was thinking of but if using nilfs2 changing == to != should make it work. doesn't seem to runon android
Current workaround is to remove the lines posted above leaving just:
sed -i 's/auto/nilfs2/1
/(NativeSD)/a \mkdir /nilfs\
mount nilfs2 /dev/block/mmcblk0p2 /nilfs' ns/init.rc (or ns/mountfs.sh if using sc)
Remove the need for changing ROM_NAME in nativesd.sh
I must be doing something wrong here.
Tried securecrt's zip on mokee and nilfs, reboot after htc screen.
Tred v zip on qsea v2 and ext4, reboot after htc screen.
Tried v zip on nexusHD2 ics and ext4 and it worked.
Tried v zip on pacman and ext4 and reboot.
It seems i am having trouble editing updater script when the rom has separate folders for initrd.gz and zImage. Each time the nand ramdisk appears in folders but is not edited.
Can you post your working edited updater script for pacman rom so that i can see where i have gone wrong.
Robbie P said:
I must be doing something wrong here.
Tried securecrt's zip on mokee and nilfs, reboot after htc screen.
Tred v zip on qsea v2 and ext4, reboot after htc screen.
Tried v zip on nexusHD2 ics and ext4 and it worked.
Tried v zip on pacman and ext4 and reboot.
It seems i am having trouble editing updater script when the rom has separate folders for initrd.gz and zImage. Each time the nand ramdisk appears in folders but is not edited.
Can you post your working edited updater script for pacman rom so that i can see where i have gone wrong.
Click to expand...
Click to collapse
PAC changes with full script attached:
ui_print("@ Installing System");
package_extract_dir("kernel/boot", "/boot");
package_extract_dir("kernel/kernel", "/boot");
package_extract_dir("kernel/kernel", "/boot_dir");
package_extract_dir("NativeSD", "/tmp");
set_perm(0, 0, 0777, "/tmp/nativesd.sh");
run_program("/tmp/nativesd.sh");
package_extract_dir("sdcard", "/sdcard");
package_extract_dir("system", "/system");
as far as I recall I used the attached v1 so should be no problems there, just make sure to change rom_name.
Have tried modifying nand updater-scripts (BBCM7 and SlimICS) but not working at the moment.
Will also post modified scripts to change the ramdisk from a running build (which datagr shouldn't have any problems incoporating into his app).
In terms of nilfs2, have you tried that with v1? Will have a look through sc to see if it's running correctly
In your instructions first post, the code is inserted after "package_extract_dir("system","/system");"
But the working script has it before this. That seems to be where it went wrong for me, because now pacman 1.1 on v with ext4 boots Edit; track forwards/backwards now working too.
The instructions worked for NexusHD2 ics 2.7 though, with the initrd.gz and zImage in the same folder.
Tried nativesdsc1.1 on nilfs with != on pac1.1 -stuck on magldr gogogo. Native sd folder initrd.gz 915.1Mb, NativeSD/PAC folder initrd.gz 168.3Mb
BTW i didn't see a nilfs2 file in sc1.1, does this matter.
BTW2 i have got a working rom on nilfs, but installed it via diff files on post3 fs superthread
Robbie P said:
Tried nativesdsc1.1 on nilfs with != on pac1.1 -stuck on magldr gogogo. Native sd folder initrd.gz 915.1Mb, NativeSD/PAC folder initrd.gz 168.3Mb
BTW i didn't see a nilfs2 file in sc1.1, does this matter.
BTW2 i have got a working rom on nilfs, but installed it via diff files on post3 fs superthread
Click to expand...
Click to collapse
No I incorporated nilfs2 into the nativesd script as it's only two lines. It seems != doesn't work on android, another workaround then that should work is to remove the lines
Mount_Type=`mount | grep "nilfs2" | cut -d ' ' -f 5`
if [ "$Mount_Type" == "nilfs2" ]
then
else
sed -i 's/auto/ext4/1' ns/init.rc altogether
And haven't tested sc at all yet, have been trying to made a text driven script for the on device one.
If your getting that with sc then the script isn't running at all, there'll be a mistake somewhere
Edit. fixed now (sc1 was more right than 1.1)
Just tried sc1.2 on pac1.1 nilfs changed ROM_NAME in install.sh and nativesd.sh and auto in install.sh-hangs on white htc screen
tried deleting everything in between # changing auto to ext4 or nilfs2 and # fixing permissions (and auto to nilfs2 in install.sh), and it hangs on black htc screen.
Edit; just found out i had wrong kernel in my zip.....
Did these two tests again-both times hangs on black htc screen. have attached DMESGs. (i had edited updater-script for these, did not mention this above).
tried pacman 1.1te with v1.1 on ext4 -working
will post initrd.gz on pacman thread
Robbie P said:
Just tried sc1.2 on pac1.1 nilfs changed ROM_NAME in install.sh and nativesd.sh and auto in install.sh-hangs on white htc screen
tried deleting everything in between # changing auto to ext4 or nilfs2 and # fixing permissions (and auto to nilfs2 in install.sh), and it hangs on black htc screen.
Edit; just found out i had wrong kernel in my zip.....
Did these two tests again-both times hangs on black htc screen. have attached DMESGs. (i had edited updater-script for these, did not mention this above).
Click to expand...
Click to collapse
Between # changing auto to ext4 or nilfs2 and # fixing permissions in v you need to leave
sed -i 's/auto/nilfs2/1
/(NativeSD)/a \mkdir /nilfs\
mount nilfs2 /dev/block/mmcblk0p2 /nilfs' ns/init.rc (or ns/mountfs.sh with sc).
Still hanging on htc screen m8.
Will give v1.1 a go.
Edit; Tried v1.1 on pac1.1te on nilfs using working ext4 build as it seemed like it might work-hangs on boot.
Edited as post above (already auto in install.sh), aroma says installed ok, but it took a few seconds. no initrd.gz created.
Just tried cmtight beta v1.0 with nativesd-ext4(2) and it boots with normal initrd.gz
it also boots with v initrd.gz
But with sc initrd.gz it just hangs on htc screen
tmp folder created in NativeSD/CMTight folder, but is empty (on pc)
There seems to be a problem with bt on this ROM, doesn't want to send sound, but skipping tracks works (on v). Saw a post in the nand thread about bt not working.
Will try again with sundawg's cm7 but no luck so far.
Robbie P said:
Just tried cmtight beta v1.0 with nativesd-ext4(2) and it boots with normal initrd.gz
it also boots with v initrd.gz
But with sc initrd.gz it just hangs on htc screen
tmp folder created in NativeSD/CMTight folder, but is empty (on pc)
There seems to be a problem with bt on this ROM, doesn't want to send sound, but skipping tracks works (on v). Saw a post in the nand thread about bt not working.
Will try again with sundawg's cm7 but no luck so far.
Click to expand...
Click to collapse
Thanks, again for testing these, have pulled and readded those zips, the tmp folder should copy now and have changed the sc side based on marco's suggestions (thought I'd already done that).
Should have my phone at the very least in a condition where I can install zips, so will get some testing done myself soon enough.
(Have posted ramdisk for Sundawg-CM7 in the other thead if you haven't seen it, will add another in a few mins)
tried latest on miuijb
tmp folder is full
normal initrd boots
v initrd reboots almost immediately
sc initrd reboots almost immediately
Do you need me to post anything as i am off to bed soon.
Robbie P said:
tried latest on miuijb
tmp folder is full
normal initrd boots
v initrd reboots almost immediately
sc initrd reboots almost immediately
Do you need me to post anything as i am off to bed soon.
Click to expand...
Click to collapse
The init.rc's if you wouldn't mind (off soon myself) and is there a rom_name.txt?
Edit: The init.rc's should be in NativeSD/tmp/ns2 (and ns3) if the folders copied correctly, I take it that there are no folders in tmp then.
Edit. Opened those ramdisks and they just have bin folders (and mountfs.sh with sc); did you remember to add the nand ramdisk to the NativeSD folder in the zip?
That explains why you can't find any init.rc files
couldn't find init.rc, found initrcmod, renamed it to .txt
Edit; doh! they are in these, sorry. Night
ooh, just tried to DL from market using cmtight and initrd-ext4-v.gz from before, and can't DL (error 101). It works ok using normal initrd.gz. No bootloop though, as gtbluesky got in nativesd thread.
Also perhaps miuijb was not best choice for last test, as got the same results as gtbluesky.
---------- Post added at 02:27 PM ---------- Previous post was at 02:12 PM ----------
HypoTurtle said:
did you remember to add the nand ramdisk to the NativeSD folder in the zip?
That explains why you can't find any init.rc files
Click to expand...
Click to collapse
Sorry m8, just checked and no ramdisk.