[Guide] Shi1tROM Tutorial Firmware - The beginning - AT&T Samsung Galaxy S II SGH-I777

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.)

Related

Running a custom P500 ROM in the Emulator

This probably belongs in the developer section, but I don't have permission to post there yet)
This work is very preliminary. It isn't really anything more than a starting point right now. It DOES NOT yet provide a faithful representation of a custom ROM in the emulator.
Current status:
emulator running 2.6.29 kernel with a combination of frankenstein of the emulator and devoid-franco system image.
I've been working to get a custom ROM working in the Android SDK emulator. There are several reasons for this, but in the end, it makes it a lot easier to test out different tweaks to get the ROM working as I'd like (I need some functions provided on the P509 ROM that aren't provided on any custom ROMS, and reinstalling the APKs isn't sufficient). I spent a lot of time looking for a thread about this, but nothing I could find discusses the specifics of working with a P500 based device
Things I've learned:
a) you need a kernel specifically compiled for the emulator, and the ramdisk image needs to be built to work with an emulator. For the moment i am using the SDK kernel (2.6.29) and ramdisk image to get going
b) the p509 libraries aren't compatible with the emulator, I needed to copy the libraries from the supplied emulator image
Here are some notes I took. I'll try to flush this out more as I make further progress:
Tools you will need:
Android SDK and 2.2 platform files (android-8)
unyaffs
mkfs.yaffs2.x86
a copy of the ROM image to install (devoid.franco.v5 in my case)
before beginning you should build a stock 2.2 emulator env to ensure everything is working (from sdk/tools run):
android list targets
find the id for 2.2 (was '4' for me)
android create avd -n test-froyo -t 4
(I used all defaults, except I set the RAM to 512MB and screen to HVGA)
emulator -avd test-froyo -show-kernel
(this should eventually bring up a running froyo)
you'll need to know where the avd lives. In linux, it should be in ~/.android/avd/test-froyo
I'm working on linux, but this should work in Windows if you can find a compiled version of mkfs.yaffs2 for windows (I've seen a compiled unyaffs version out there)
1) unzip the rom image. it should create a system/ directory.
We should execute the updater-script here, but we'll take a short-cut:
chmod -R 655 system/
2) uncompress the platfrom system image:
in a new dir:
unyaffs <sdk path>/platforms/android-8/images/system.img
3) copy all files from system/ in step-2 to system/ in step-1
we should really need to do this, it is probably sufficient to run the updater-script and then copy the framework/, lib/ and a couple qemu files, but this is just to get things going.
4) make dbus.conf readable:
chmod 644 system/etc/dbus.conf
5) remove system/app/LGSetupWizard.apk
This app relies on custom classes in the firmware that aren't present in the emulator base system. I'm still trying to build a custom firmware.jar that has both.
6) build a new system.img
mkfs.yaffs2.x86 system system.img
7) copy the system image to your avd dir:
cp system.img ~/.android/avd/test-froyo
If everything has gone well, you can now startup the emulator and boot into franco's rom:
emulator -avd test-froyo -show-kernel
Because we copied too much stuff from the default system.img, we've lost his themes and mst of his tweaks, so it isn't really a faithful representation of the ROM at all, but we've cleared the 1st milestone of being able to boot up.
I also booted a stock P509 kernel this way with a few changes:
a) I used nandroid to get the system image, and then unyaffs2 to extract it)
b) I removed all odex files:
find system -name "*.odex" | xargs rm
Again, this isn't really a custom ROM, it is actually the emulator rom with additional apps and customizations. The goal is to get to as close as possible to running a true custom ROM
A few other notes:
the following framework files can be preserved from the custom ROM (no need to overwrite):
Code:
am.jari : ok
android.policy.jar : not ok
android.test.runner.jar : ok
bmgr.jar : ok
core.jar : ok
ext.jar : ok
framework.jar : not ok
framework-res.apk : not ok
framework-tests.jar : ok
ime.jar : ok
input.jar : ok
javax.obex.jar : ok
monkey.jar : ok
pm.jar : ok
services.jar : not ok
svc.jar : ok
framework.jar is the most important of the 'not-ok' ones as far as I can tell, and is missing several classes. I am currently working to build a services.jar that is a merge of the P500 and emulator classes.
Installing the p500 framework,.jar requires many files from system/lib, but once all dependencies are solved, you eventually end up with a segfault. I've been unable to debug that, and am not sure I want to. The goal is to get a running dalvik VM with all classes needed to run P500 apps.
First blood!!!

[HOW-TO][TUTORIAL][WIP]DEODEX, BUILD KERNEL, BUILD CUSTOM ROM and MORE

Hi all,
In this thread, I will try to share the knowledge I have on deodexing, making custom ROMs, modifying initramfs, building kernel and much more.
Please check the below posts for each of these tutorials.
Hope this opens doors to many new ROM and Kernel developers.
NOTE: THESE TUTORIALS ARE WRITTEN FOR GT-I9100. WILL NOT WORK ON OTHER DEVICES. I DON'T TAKE ANY RESPONSIBILITY IF YOU MESS UP AND BRICK YOUR DEVICE OR ANYTHING ELSE. USE AT YOUR OWN RISK.
Deodexing Stock Rom
For GINGERBREAD ROMS:
What you need to have:
xUltimate v2.3.3 - you can download it HERE (Thanks and Credits to Xeudoxus for this awesome app)
Rooted kernel with busybox
JDK installed on your Windows system
If adb is not available in your windows PC, in xUltimate folder open "jar" folder. You'll find adb there.
Extract stock app & framework folders and Deodex:
Connect your device to computer.
Start xUltimate (double-click on Main.exe)
Select option 1. (Pull /system/app)
Once option is done, select option 2. (Pull /system/framework)
In the same folder, now you'll see two new folders (origi_app, origi_frame)
Select option 3 in Main menu (Deodex /system/app)
Once its done, select option 4 in Main menu (Deodex /system/framework)
DONE!!
NOTE: If any apk/odex gives issues while deodexing, remove that corresponding apk and odex from origi_app folder and deodex again. (Mostly the apps which can be downloaded from play store might give errors.. ex: Maps, Voice search etc.)
Now you'll see two new folders done_app and done_frame.
Push deodexed app and framework to device:
Connect your device to PC in USB debugging mode.
Copy done_app and done_frame folders to root of sdcard (/sdcard).
Open Windows command prompt and type the below commands.
Code:
[LIST]
[*]adb shell
[*]su
[*]stop
[*]mount -o remount,rw /dev/block/mmcblk0p9 /system
[*]rm /system/app/*.odex
[*]rm /system/framework/*.odex
[*]busybox cp /sdcard/done_app/* /system/app/
[*]busybox cp /sdcard/done_frame/* /system/framework/
[*]chmod 644 /system/app/*
[*]chmod 644 /system/framework/*
[*]mount -o remount,ro /dev/block/mmcblk0p9 /system
[*]sync
[*]reboot recovery
[/LIST]
In Recovery, Wipe Cache and Wipe Data/Factory reset.
Reboot.
Now you've deodexed app and framework.
For ICS ROMS:
For ICS Roms, the process is quite easy. (Thanks and Credits to jaydvn.)
Download the attached zip file.
Extract it on your windows PC.
Copy your /system/app to _app folder
Copy your /system/framework to _framework folder.
Run AutoDEOToolMain.bat
Follow the instructions.
deodexed jars and apks will be found in deodexed_APK and deodexed_JAR.
Push deodexed app and framework to device:
Connect your device to PC in USB debugging mode.
Copy deodexed_APK and deodexed_JAR folders to root of sdcard (/sdcard).
Open Windows command prompt and type the below commands.
Code:
[LIST]
[*]adb shell
[*]su
[*]stop
[*]mount -o remount,rw /dev/block/mmcblk0p9 /system
[*]rm /system/app/*.odex
[*]rm /system/framework/*.odex
[*]busybox cp /sdcard/deodexed_APK/* /system/app/
[*]busybox cp /sdcard/deodexed_JAR/* /system/framework/
[*]chmod 644 /system/app/*
[*]chmod 644 /system/framework/*
[*]mount -o remount,ro /dev/block/mmcblk0p9 /system
[*]sync
[*]reboot recovery
[/LIST]
In Recovery, Wipe Cache and Wipe Data/Factory reset.
Reboot.
Done.
Enjoy.
Building kernel
Okay. Let's learn how to build kernel for GT-I9100. There are many ways to build. I am just presenting here the way I build and make kernel.
NOTE 1: Follow the instructions exactly.
NOTE 2: Kernel is opensource. If you make any changes to it, you're expected to share your source. (Usually people share it over github )
NOTE 3: FLASHING KERNEL IS RISKY AND DANGEROUS. BE CAREFUL. BUILD AND FLASH ON YOUR OWN RISK.
What you need to have:
Ubuntu 10.04 and above (I use 10.04 )
ARM tool chain (Download HERE. Click on IA32 GNU/Linux TAR under Advanced Packages)
Samsung's opensource kernel for GT-I9100 (Download HERE. Go to Mobile->Mobile Phone-> Select I9100 (update 3 for Gingerbread and update 4 for ICS) and download the zip)
Setting up toolchain:
Extract the tar you downloaded(Suggestion: Extract to one folder where you can have everything. In my case /home/superatmos/build_kernel).
After extracting, you'll see a folder named arm-2010q1. Inside there will be many folders (ex. bin, lib and so on.)
Folder structure will be: /home/<your_name>/build_kernel/arm-2010q1
Setting up kernel:
Extract the zip you've downloaded from samsung's opensource.
You'll find two zips.
Extract GT-I9100_Kernel.tar.gz to /home/<your_name>/build_kernel/
Folder structure: /home/<your_name>/build_kernel/GT-I9100_Kernel
Setting up initramfs:
Samsung's zImage is divided into two parts: Opensource kernel (which you downloaded from samsung's website) and initramfs (which is root file system to boot up the device).
You can extract initramfs from your zImage using the below mentioned links (Credits and Thanks to Chenglu) Original Thread: HERE
To extract initramfs from Gingerbread zImage: HERE
To extract initramfs from ICS zImage: HERE
Folder structure: /home/<your_name>/build_kernel/initramfs
Now the entire setup is ready. Let's start modifying kernel configuration.
Setting up kernel config:
For Gingerbread:
Go to /home/<your_name>/build_kernel/GT-I9100_Kernel/arch/arm/configs folder.
Copy c1_rev02_defconfig file and paste it in kernel root folder (/home/<your_name>/build_kernel/GT-I9100_Kernel/).
Rename c1_rev02_defconfig to .config in kernel root folder.
Now open Makefile which is in your kernel root folder(/home/<your_name>/build_kernel/GT-I9100_Kernel/).
Modify the below lines (I guess line 195 and 196).
For ICS:
Go to /home/<your_name>/build_kernel/GT-I9100_Kernel/arch/arm/configs folder.
Copy u1_defconfig file and paste it in kernel root folder (/home/<your_name>/build_kernel/GT-I9100_Kernel/).
Rename u1_defconfig to .config in kernel root folder.
Now open Makefile which is in your kernel root folder(/home/<your_name>/build_kernel/GT-I9100_Kernel/).
Modify the below lines (I guess line 195 and 196).
Code:
ARCH ?= arm
CROSS_COMPILE ?= /home/<your_name>/build_kernel/arm-2010q1/bin/arm-none-linux-gnueabi-
Save and close.
Modifying kernel configuration:
Now open .config file(which you renamed). If its not seen, it might be hidden. Go to View->Show hidden files and there you go.
Do the below things:
Adding local version:
Change CONFIG_LOCALVERSION=" " to anything you like. I add this way:
CONFIG_LOCALVERSION="-I9100-superatmos"
Adding initramfs path:
You need to let kernel know the path from which it needs to take initramfs.
Change CONFIG_INITRAMFS_SOURCE=" " to ../initramfs (In this tutorial it's the path. If you had copied anywhere else, give the path properly).
Enough for now. Once you get experience, you can modify many configurations as per your liking and save. This configuration can be changed by GUI too with the command make menuconfig.
The Important part: Building the kernel:
For Gingerbread:
Open terminal.
Go to path /home/<your_name>/build_kernel/GT-I9100_Kernel/
Type make.
For ICS:
Open terminal.
Go to path /home/<your_name>/build_kernel/GT-I9100_Kernel/
Type export USE_SEC_FIPS_MODE=true
Type make.
THAT'S ALL. YOUR zImage is ready and is available in /home/<your_name>/build_kernel/GT-I9100_Kernel/arch/arm/boot/zImage.
Install the zImage on the device:
Go to the path where zImage is present and type the below line in command line.
Code:
tar cvf I9100_kernel.tar zImage
Flash the tar using odin.
DONE. CONGRATULATIONS. NOW YOU'VE YOUR OWN KERNEL.
Give me your feedback so that I can improve this tutorial. And post here about how your build went. All the best.
Making custom ROM
Let's move on to make a custom ROM.
Inputs/Feedback/Suggestions are more than welcome. Lets improve this tutorial together for the betterment of the android community.
Steps involved in making a custom ROM:
Getting the system dump from the device.
Deodexing app and framework folders.
Creating various mods by modifying framework and system files.
Modifying build.prop and adding tweaks.
Making META-INF folder and writing an updater-script (edify scripting).
Signing the ROM and making a flashable zip.
Folder Structure:
Before going forward, let's follow the below structure folder to make the tutorial more understandable.
Let our ROM name be CustomROM. The folder structure will be C:\Users\<your name>\CustomROM.
Let's move step by step. Are you ready??
Getting the system dump from the device
Click to expand...
Click to collapse
Make sure USB debugging is ON and connect your device to the PC.
Open command prompt on your windows PC and go to CustomROM folder path.
Type adb devices. You should be able to see the device detected. (If not check environmental variables whether adb is in system path or not. If not present, add the adb path.)
Type the below command to get the dump of system folder.
Code:
adb pull /system system/
Now inside the folder CustomROM, you should be able to see system folder with many folders like app, etc, framework etc inside.
Done with first step.
Deodexing app and framework folders
Click to expand...
Click to collapse
Look HERE how to deodex app and framework folders. Copy the app and framework folders to xUltimate folder, rename them to origi_app and origi_frame and follow the given link to deodex.
NOTE: After deodexing, merge origi_app folder with app folder under C:\Users\<your name>\CustomROM\system\app and origi_frame with framework folder under C:\Users\<your name>\CustomROM\system\framework.
Creating various mods by modifying framework and system files
Click to expand...
Click to collapse
Okay. This the section where your hardwork, innovation and talent comes in. You can use the mods available already, create your own mods, port various mods from other devices and so on.
Below is a list of various mods which can be ported on to GT-I9100. All the credits go these respective thread owners. Thanks to them.
Lidroid 14 toggle mod
Extended power menu with/without header
CRT Off Animation & SIP Over LTE/HSPA
Swipe to remove notifications
NOTE: Let me know more mods with links so that I can add here.
Modifying build.prop and adding tweaks
Click to expand...
Click to collapse
Okay. This is one of those files where you name your ROM(to be visible in settings. ) and add many tweaks.
To name your ROM (to be visible in settings), change the below code.
Code:
ro.build.display.id=CustomROM v1.0
Check the below links for many other tweaks. All credits go to respective thread owners. Thanks to them.
build.prop tweaks by TheFrankenstain
build.prop tweaks by dhlalit11
Making META-INF folder and writing an updater-script (edify scripting)
Click to expand...
Click to collapse
Once you're done with all the modifications, mods and additions, its time to create META-INF folder and make the updater script. Once the user flashes the ROM zip, this is the script that runs and does everything written inside the script. PLEASE BE CAREFUL WITH THIS. TAKE REFERENCE FROM OTHER (SAME DEVICE) ROMS' UPDATER-SCRIPT. (In this case, take reference from other GT-I9100 roms.)
Check the below links for tutorial and how-to on writing edify script and making updater script. All credits go to respective owners of the threads. Thanks to them.
Edify Scripting, Making Flashable ZIPs, ZIP Signing & Key Creation
Edify Scripting Notes
How to Write an Updater-Script with Edify Code
Edify Installation Script Syntax's
NOTE: system folders path, boot/kernel partition path, modem partition path and so on are COMPLETELY DIFFERENT for DIFFERENT DEVICES. Check the partitions for your device properly, carefully and then work on updater-script. TAKE HELP OR REFERENCE FROM OTHER ROM DEVELOPERS FOR YOUR DEVICE.
Lets move on to last step. Making a signing and making a flashable zip.
Signing the ROM and making a flashable zip
Click to expand...
Click to collapse
Make sure, now you should be able to find two folders (META-INF and system) inside C:\Users\<your name>\CustomROM.
Check in THIS thread for test signing your ROM. It WORKS with GT-I9100.
or Check THIS thread to create your own signing key and certificate.
Now you're done with making a custom ROM. Hope to see more custom ROMs from many users.
Give me your feedback so that I can improve this tutorial. And post here about how your custom ROM making went. All the best.
last one
i don't see any tutorials just links to a diff thread and a rom that won't work on i9100
buster041284 said:
i don't see any tutorials just links to a diff thread and a rom that won't work on i9100
Click to expand...
Click to collapse
You're quite fast Updated Deodexing and Building kernel section..
Great thread Superatmos. I'll definately have a go at this.
Quick question ? Am i right in assuming that although your tutorial says to connect your device this line from xUltimate seperceeds that ?
"Alright xUltimate has been updated to v2 What this means is that you do not need your phone connect to your computer to deodex. So you can just manually place the .odex files in (\origi_frame\) and (\origi_app\) and it will deodex. You can also transfer the .odex files from your phone like the last version."
where do I get the zImage to extract the initramfs from? I can't seem to find the zImage on my phone or in the source anywhere.
Great
Very useful.. Added to my favorite.
Thank's man, i'll read that
puccini said:
Great thread Superatmos. I'll definately have a go at this.
Quick question ? Am i right in assuming that although your tutorial says to connect your device this line from xUltimate seperceeds that ?
"Alright xUltimate has been updated to v2 What this means is that you do not need your phone connect to your computer to deodex. So you can just manually place the .odex files in (\origi_frame\) and (\origi_app\) and it will deodex. You can also transfer the .odex files from your phone like the last version."
Click to expand...
Click to collapse
Connect your device to the PC and double click Main.exe inside xUltimate folder. Follow the instructions you see from then. Its quite self explanatory.
If you already have origi_app and origi_frame folders, then just double click on Main Skip.bat.
dmp450 said:
where do I get the zImage to extract the initramfs from? I can't seem to find the zImage on my phone or in the source anywhere.
Click to expand...
Click to collapse
Use ktool (available on market.. compatible with I9100) and click on Dump current kernel. You'll find it on sdcard.
One more way is when you download firmware from sammobile.com, just extract the file and you'll find zImage inside it.
Nice thread,
I m waiting from long time.
Thanks for your work.
Sent from my GT-I9100 using XDA
Making custom ROM section updated
Hi all,
Please find updated custom rom section HERE.
Feedback and suggestions welcome.
Thanks for the kernel part, will come in handy
Enviado desde mi GT-I9100 usando Tapatalk 2
Good tutorial, thanks.
How do you guys sign the rom if you are on Linux (ubuntu for me)
hi superatmos
thanks for this handy thread...may i ask your for a help here?why in my every deodexing always gives error result?
I attach the screenshots.
Many thanks in advance
tks mate will try to pack my own kernel following this method
Sent from my GT-I9100 using Tapatalk 2

[WIP]Developers only - a different way of creating flashables..

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.

few questions about making a flashable zip

Please bear with me, I'm not a dev.
The purpose of making the zip is to load an rsa key to my phone so I can authorize usb debugging mode on my computer. Long story short, broken phone, I think this is one of the last options I have to recover data from it.
Details here if you're interested: https://forum.xda-developers.com/galaxy-s4-att/general/recover-data-broken-screen-digitizer-t3788079
Its a Galaxy S4 i337 phone, i didn't find any specific instructions on how to make flashable zip for it. I have 2 zip files for my bootloader (one for flashing a modem, one of tethering setting). Both have META-INF and system folders. T
1 - update-binary files in each sample zip are different, I read somewhere that I don't really need to touch them but if thats the case I would expect them to be the same. If I just copy that update-binary file over to my zip, and write a very simply script to copy a 1 key to another location, what are the chances I brick the phone if my script fails or something is wrong with that binary file?
2 - anyone feel like helping, I'm thinking this is probably <5 minutes worth of work for someone that knows what they are doing?
Here is what I have so far, if someone could just give me some insight into whether this has any chance of working.
zip file:
META-INF/com/google/android/update-binary (not sure which one to use yet)
META-INF/com/google/android/update-script
Code:
mount("/system", "/data");
package_extract_file("system/rsa-swap.sh", "/tmp/rsa-swap.sh");
set_perm(0, 0, 0777, "/tmp/rsa-swap.sh");
package_extract_file("system/key", "/tmp/key");
run_program("/tmp/rsa-swap.sh");
unmount("/system", "/data");
system/key
system/rsa-swap.sh
Code:
#!/sbin/sh
newrsa="/tmp/key"
oldkey="/data/misc/adb/adb_keys"
if [ -f $oldkey ]; then
echo "exists"
cp $oldkey /data/misc/adb/adb_keys.bak
cat $newrsa >> $oldkey
else
echo "does not exist"
cp $newrsa $oldkey
fi
I aslo want it to reboot, not just where to add that yet but should be easy. Not signing this if its an option.
I'm I asking a stupid question?
still looking for some help

Share Your Boot Battery_scale

This is your battery view when your device is turned off and plugged in.
This thread is Made for the S5 specifically (though these images can be used if rescaled to the right size.
The file can be known as Battery_scale.PNG
The file can be Located at. /res/images/charger
The file is a Multi surface image. Basically a zip png
To extract All the ".PNG" files use. https://github.com/Aaahh/Battery-Images-Replacer
Thanks to @Aaahh for making this a lot easier
Originally posted by cunha17 @ https://forum.xda-developers.com/showthread.php?t=1609059&page=5
Battery-Images-Replacer (forums.oneplus.net/threads/battery-charging-image-replacer.186460) is a way to easily change the battery boot animation. You can use Aaahh provided images or change them and make your own flashable zip. There are 2 problems in that solution, first it is directed to a specific platform (oneplus) and second, it does not work in Marshmallow (CM13).
I figured out a way to make Battery-Images-Replacer to work in Android 6 (Marshmallow) and problably in 5 (Lollipop). Just stating that I'm using CM13 in a Galaxy S3 (i9300) phone, but the code is the same one Aaahh provided with two minor changes:
The battery_?.png and battery_charge files are deprecared in 6.0, and replaced by battery_scale.png (multi surface image) with mandatory 6 frames (hardcoded in Android). To make Battery-Images-Replacer work with previous Android versions, the deprecated files are kept; and
The block device in anykernel.sh file needs to be generalized to work in i9300 (my case) and maybe others, so it was replaced at line 9 with: block=`find /dev/block/platform -name BOOT`;
Warning: be shure to do the 2nd step above, or the flashing will not work, but also, you may brick your phone!!!
But the catch is the creation of the new battery_scale.png file. In this case, we have the 6 single surface images (battery_?.png files) and want to make a "Multi Surface Image" file compliant with Android 6.0.
I made the following script (create_multi_surface_image.sh) that convert multiple PNG to a single "Multi Surface Image", you just need to change the FILES and SCALEFILE variables if needed. This script uses ImageMagick, exiftool and pngcrush to do the job. Just run the script where the battery_?.png files are.
create_multi_surface_image.sh
Once the battery_scale.png is created, you need to copy it to the Battery-Images-Replacer-ak-opo-anykernel/charger/ directory if you didn't run the script there. Go to the base directory (Battery-Images-Replacer-ak-opo-anykernel) and run "zip -r ../Battery-Images-Replacer.zip ." and you should get the flashable zip file at the parent directory.
Now transfer the zip file to your phone (adb push, usb file transfer, etc) and make shure that the file is available to TWRP ou CWM. Boot into recovery and flash the zip file. Turn off the phone and start charging. Enjoy your new battery animation.
I will attach the battery_surface.png file if you just want the final result using the source files (battery_?.png) provided by Aaahh and available at github.com/Aaahh/Battery-Images-Replacer.
Thanks Aaahh for the great job!
And what you have waited for
(Please note this is from my device which is running RR9.0)
(Edit will upload via computer as labs doesn't let edit an add images)

Categories

Resources