Related
I am trying to build a flashable zip that i compile from the stock system.img and boot.img files from 2.00.405.3 using dsixda's HTC Android Kitchen...
When i go to flash the rom that it creates (even if i dont mod anything else ...) i get a status 0 error..
I edited the update script so that every line could be identified so i could find the last error...
and the last print was "package_extract_dir"...
script follows:
Code:
...
ui_print("format");
format("MTD", "system");
ui_print("mount");
mount("MTD", "system", "/system");
ui_print("package_extract_dir");
package_extract_dir("system", "/system");
ui_print("symlinks");
....
The really interesting thing is that a few lines above this (as can be seen) i format the system partition and upon re-boot the stuff from the old device rom (before my flash attempt) is still on there! ...
What the heck is going on?
Thanks
Kris
Because the flyer/view doesn't use mtd partitions...it uses emmc.
The dsixda kitchen does some conversions on the updater-script that requires some device specific information about mounts. He created a definition folder where you drop device specific definitions for the common mount points.
Go into the kitchen folder > tools/edify_defs
Inside of that folder there are various device definitions. Create one for the flyer. There's also a template in there, but I didn't have much luck editing the template. I just looked at some of the newer defs and plugged in the View mount points.
Here's the one I used for the View, but I'm not sure if the mount points are the same on the Flyer. Also, I'm not sure what the boot mount point for the View is, but writing the boot doesn't seem to require the specific mount.
Code:
change_mnt=yes
param1=ext4
param2=EMMC
param1_sdcard=vfat
param2_sdcard=MTD
sys_mnt=\/dev\/block\/mmcblk0p26
cache_mnt=\/dev\/block\/mmcblk0p31
boot_mnt=???
data_mnt=\/dev\/block\/mmcblk0p30
sdcard_mnt=\/dev\/block\/mmcblk1p1
Ahh that explains it ... i looked through my procs/mounts and found the info
sys_mnt=\/dev\/block\/mmcblk0p25
cache_mnt=\/dev\/block\/mmcblk0p30
boot_mnt=???
data_mnt=\/dev\/block\/mmcblk0p29
Kris
I put in:
Code:
format("ext3", "EMMC", "/dev/block/mcblk0p25");
mount("ext3", "EMMC", "/dev/block/mcblk0p25", "/system");
This causes the status 0 error still when i copy over the files tho with package_extract_dir
Also tried ext4 ... this produces the same issue as above (status 0)
Thanks
Kris
I tried using what was listed about for the View but it doesn't work on the wifi Flyer. How do you find out what they should be? I get a Status 1 error when trying to flash.
Try cat /proc/emmc. Boot is mmcblk0p22 on the view. Thanks to IEF for the pointer
Sent from my SPH-D700 using XDA App
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.
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.
Hey Ace Users,
I am going to provide you all the guide to create your own CWM Flashable zip file.
The Best Part of this guide is that you wont need your computer to create the CWM Flashable zip file as this guide will teach you all how to create the CWM Flashable Zip file with the help of the Root Explorer App.
The things you will need for this guide are:-
1.Root Explorer App.
2.Your Ace.
3.A little patience.
So without much ado,Lets start the guide.
STEPS:-
1.Download and install the Root Explorer App.
2.Open the Root Explorer App and Navigate to the Root of your SD Card.
3.Create a Folder and name it whatever you like or whatever name you want to give to your Zip File(I will be reffering to the folder as "Main Folder" throughout this guide)
4.In the Main Folder,you will need to have Two Sub-Folders which are as "META-INF" And "system".
5.The META-INF Folder consists of various files and they should be untouched(The only file in the META-INF folder which we are going to edit is the updater-script).
6.The system folder which you put in the Main Folder contains the apps or various other mods which you want to apply to your ace.
Steps on How to Edit the updater-script:-
1.Go to the META-INF Sub-Folder in the Main Folder.
2.open the com folder which you will find in the META-INF Sub-Folder.
3.Then you will see google folder as soon as you enter "com" folder,enter the google folder,now you will see "android" folder,open it.
4.In the android folder,you wll see two files named as update-binary and updater-script.
5.Open the updater-script file by selecting it.
6.You will see various options.
7.Select the Text Editor option and then the updater-script will open in the text editor.
8.Now we need to type some code so as to have the following functions.
Editing the updater-script:-
So once the updater-script is opened in the text editor,you will need to type some code so as to have the following functions.
CODE:-
Case 1:-
To Display the information of the particular Mod when you select to flash it in CWM Recovery(It is the display you see when you flash a particular Flashable zip file. For Example:- if you are flashing beats mod then when you select to flash the zip file and when the flashing starts you see some infomation like "Beats For Ace" and when the flashing is over you can see that the display shows flashing is done and it tells to reboot phone and stuff)
CODE:-
ui_print("The Text you want to display");
For Example if you want to display "beats Mod for Ace" then you must enter the code as ui_print("Beats Mod for Ace");
NOTE:-
semi-colon and the double quotes in the above code are to be put as they are compulsary to execute the code.
Case 2:-
If You want the updater-script to mount the /system partition,then the code is:-
CODE:-
run_program("/sbin/busybox", "mount", "/system");
NOTE:-
semi-colon and double quotes are compulsary.
Case 3:-
Now we need to put the apps in the /system partition and for that we need to type the code as:-
CODE:-
package_extract_dir("system", "/system");
NOTE:-
semi-colon and double quotes are compulsary.
Case 4:-
After typing the mount /system code you will also need to unmount the /system partition and to unmount the /system partition the code is:-
CODE:-
run_program("/sbin/busybox", "unmount", "/system");
NOTE:-
Semi-colon and double quotes are compulsary.
Special Case:-
After each case we need to have a special code.
At the start of updating the updater-script,we mostly write the introduction of the mod/script etc. in the ui_print.
so before you add the name & info of the mod in the ui_print you need to write show_progress(0.500000, 0);
and after writing the name/info of the mod,you will be mostly writing the code to mount the system partition,so after writing the code to mount the system partition,you need to write show_progress(0.500000, 20)
Now once you are done writing the code to mount the system partition the next thing you will be doing is extracting the package from the system partition by writing the code for extracting the system partition contents,so after you are done writing the code for extracting the system partition contents,you need to write show_progress(0.500000, 40)
Now after this,you will be writing the code to unmount the system partition so after writing that code you need to write show_progress(0.500000, 60)
After finishing writing the code to unmount the system partition,
you will add some more lines in the ui_print as for example Done flashing mod,so after writing that lines in the ui_print you will need to write show_progress(0.500000, 80)
After that you will probably write some more lines in the ui_print to notify the user to reboot his/her phone so after you write that code you will need to write show_progress(1.000000, 0)
Basically the show_progress command indicates the progress of the installation of the mod.
Sample of the whole updater-script codes in short:-
ui_print("Battery Mod For SGA");
ui_print("|-----by XYZ-----|");
ui_print("10% starting installation");
show_progress(0.500000, 0);
ui_print("20% mounting /system");
run_program("/sbin/busybox", "mount", "/system");
show_progress(0.500000, 20);
ui_print("40% Extracting Files");
package_extract_dir("system", "/system");
show_progress(0.500000, 40);
ui_print("60% unmounting /system");
run_program("/sbin/busybox", "unmount", "/system");
show_progress(0.500000, 60);
ui_print("|---Mod Flashed Successfully---|");
show_progress(0.500000, 80);
show_progress(1.000000, 0);
ui_print("Please Reboot Your Phone");
If you don't understand the show_progress procedure then check this link:-
http://rootzwiki.com/topic/6761-show...me-flashables/
NOTE FOR CM7 USERS:-
IF THE ABOVE CODE FOR MOUNTING AND UNMOUNTING THE /SYSTEM PARTITION DOESNT WORK FOR YOU,THEN YOU CAN MANUALLY MOUNT /SYSTEM BEFORE FLASHING AND THEN MANUALLY UMMOUNT IT(IF YOU WANT TO) AFTER FLASHIMG.
NOTE:-
AFTER SAVING THE CHANGES DONE TO THE updater-script,A FILE WILL BE CREATED AS "updater-script.bak".DELETE "updater-script.bak" file.
Okay so we are almost done.
Now some information about the system Sub-folder in the Main Folder.
The system Sub-folder contains another Sub-folder(s) like:-
For example if you want to add an app's apk file then the system sub-folder will contain "app" sub-folder and that app folder contains the apk file(s) that you want to put in the system partition of the ROM.
If you want to Put Framework Mods then the system sub-folder will contain "framework" sub-folder and the "framework" sub-folder wil contain the framework Mod(mostly the Framework mods are in Framework-res.apk file.)
If you want to put libs then the subfolder in the system subfolder will be "lib" and it will contain the libs.
If you want to put bin files then the subfolder in the system subfolder will be "bin" and it will contain the bin files.
If you want to add scripts then the subfolder in the system subfolder will be "etc" subfolder and in that "etc" subfolder there will be another subfolder as "init.d" and in the init.d subfolder there you can put the scripts.
After doing all that(i.e editing the updater-script and putting the files in the subfolders in the system subfolder) go back to the directory where you created the Main Folder and in Root explorer long press the Main Folder and you will get various options.
scroll down and select "zip this folder" and after the folder is zipped you can go to /SD Card/speed software/zip and find the flashable zip there.
Here ends my guide
Download Links:-
Sample file dl link
Screenshots of guide
Good..!!Helpful for lot of people:thumbup:
side_effect said:
Good..!!Helpful for lot of people:thumbup:
Click to expand...
Click to collapse
Helpful. Thanks
Sent from my GT-P6200 using Tapatalk 2
great guide :good::good::good:
but AFAIK guides are supposed to b in general...EET will move this soon
-RDR- said:
great guide :good::good::good:
but AFAIK guides are supposed to b in general...EET will move this soon
Click to expand...
Click to collapse
No they are meant to be in Development section.
I have seen many guides in development section of many phones.
Nope. Guides should be in General Section. Guides are not developing project.
This was sent from my impulses, not my Galaxy Ace.
Moving to General
Well we will have to remember alot of things before making a zip..
It will not be so easy
Really great guide....................
Sent from my GT-S6102 using Tapatalk 2
thanks for sharing
helpful
for
newbies
.......
i will try this when i get time.
thanks for this man!!
Sent from my GT-S5830 using xda premium
Thx!!!!!
Thx a lot man !!
Depuis mon Galaxy Ace GT-S5830-SGSII v9 modifié !!!
@Ace King 34
Hahaha...i think that you have forgot of put some things in this guide, and then about the command show_progress i think that you not have understood really how works.
Sent with my Evil GT-S5570 from Hell
EVIL THOR said:
@Ace King 34
Hahaha...i think that you have forgot of put some things in this guide, and then about the command show_progress i think that you not have understood really how works.
Sent with my Evil GT-S5570 from Hell
Click to expand...
Click to collapse
You Surely don't know how to read.
Read the Special Case in the OP Carefully.
It has got the show_progress.
and btw read the OP carefully next time before posting such replies.
Ace King 34 said:
You Surely don't know how to read.
Read the Special Case in the OP Carefully.
It has got the show_progress.
and btw read the OP carefully next time before posting such replies.
Click to expand...
Click to collapse
Surely you don't know read because i know read better than you Ace Chick, at least you know what do the value 40 in the command show_progress? your guide has only some commands copied from others updater-scripts but you don't know not even what they do...pfff...
Sent with my Evil GT-S5570 from Hell
@ EVIL THOR Thanks for Reporting me the issue mate.
I have changed the OP a bit.
Have a Look.
Ace King 34 said:
@ EVIL THOR Thanks for Reporting me the issue mate.
I have changed the OP a bit.
Have a Look.
Click to expand...
Click to collapse
Yes ok but the last show_progress should be 100 not 0 if not the bar of progress show only 80% and then go back to 0%.
Sent with my Evil GT-S5570 from Hell
EVIL THOR said:
Yes ok but the last show_progress should be 100 not 0 if not the bar of progress show only 80% and then go back to 0%.
Sent with my Evil GT-S5570 from Hell
Click to expand...
Click to collapse
mate I have changed the 0.500000 to 1.00000 and then I have written 0 so it changes the progress from 0.500000 to 1.000000 and I have tested it mate
it worked flawlessly.