Does theses porting steps still work for cwm - Samsung Galaxy J7 Questions & Answers

Im just curious if theses steps still would work the thing is theres no twrp recovery to port off yet.. also would it be possible to make this recovery using windows linux bash shell...
At this stage make sure that you have synced the source, updated it and setup the build environment. Now lets proceed to the actual compiling part.
Step 1 : Open the terminal and change the directory to the top of your source. Then run the command
1
make -j4 otatools
This command will create all the necessary tools and files for the recovery compilation. Here -j# signifies the number of processes to start. It is generally based on the number of processors in your computer. This process generally requires 5-7 minutes on a reasonably fast desktop computer.
Step 2 : Now that the otatools are ready, we need to get a dump of our current boot.img. To do this, use ‘adb shell’ and launch this command
1
dump_image boot /sdcard/boot.img
This command will dump the boot partition as a image file named boot.img to your sdcard. Now pull this image to your local directory using adb pull or any other method.
Step 3 : Now we need to set up the makefiles for this device. Generally this is a long and tedious process. But since we are only compiling a recovery, it will be a lot easier.
From the root of your source directory, run the command
1
. build/envsetup.sh # or # source /build/envsetup.sh
This command will prepare all the necessary files required for compiling (initialize the build environment).
Once it is done, run the command,
1
build/tools/device/mkvendor.sh device_manufacturer_name device_name /your/path/to/the/boot.img
This will open the boot image and extract all the necessary files in the device/manufacturer/device_name path.
Step 4 : Now that we have extracted the files from the boot.img, we need to edit them to suit our device. Generally this shouldn’t be necessary, but we need to be sure about that or else we can brick our devices. The only files which are to be edited are ‘BoardConfig.mk’ and ‘recovery.fstab’. The main things that you will need to add is custom partitions (if your device doesn’t support named partitions).
If you change the contents of the BoardConfig.mk file, you will have to run ‘make clobber’ or the changes won’t get picked.
As the name suggests, BoardConfig.mk contains the config about the board used in your device. This is a very important file and a single error or incorrect value can result in a brick. So be cautious while editing this file
Next file is the recovery.fstab. This file lists all the partitions of a device and its paths. If you see any incorrect partition in this file, please change it. You don’t want your boot.img flashed on the bootloader partition, do you ?
I cannot help you with the actual editing as each device has different partitions and different formats.
Step 5 : Once the files are ready, we start the compiling. Run the following command to prepare the system for a compile.
1
. build/envsetup.sh
Step 6 : Once the system is ready, lets move on to the compile process.
Run the command,
1
lunch full_’device_name’-eng
For e.g : if you have a device names cooper, the command will be,
1
lunch full_cooper-eng
This will prepare the files of cooper for compiling.
Step 7 : Now that we have all files setup, run the command
1
make -j4 recoveryimage
This command builds the recovery in the form of an image file. If you want a fakeflash for testing purpose, then run,
1
make -j4 recoveryzip
The entire building process takes around 15 minutes.
Once complete, you will get the resulting recovery.img in the ‘out/target/product/device’ path. You can flash the recovery using a flashable zip or from adb using flash_image.

And if youre not sure what windows linux bash shell is its in the new anniversary update for windows 10. You can download and install it manually on on youre windows 10 device and check it out. Linux on windows..
https://support.microsoft.com/en-us/help/12387/windows-10-update-history

Related

Nandroid v2.0 - Full NAND backup and restore tool (tried and tested!)

* What is Nandroid Backup v2.0?
Nandroid Backup is a set of tools and a script that will enable anyone who has root on their G1 and has the engineering/dev spl bootloader [1] (or has a dev phone) + a recovery image with busybox and adbd running as root [2] to make full system backups. These can then be restored using the fastboot [3] commandline tool and your phone in SPL/bootloader mode (hold camera + power). This allows you to create regular backups of your entire phones NAND flash so that you can restore a backup when something breaks. Its backup method works on a level that allows you to completely break, wipe or corrupt any or all partitions and still restore the phone to a working state within a few minutes. This works great for those who use their G1 for normal activities but also want to test their ideas which might break the phone, or when not having an extra G1 to keep purely as a development phone.
* Requirements for use
- Android G1 phone in recovery mode with busybox installed, including appropriate symlinks to at least tar and md5sum, as well as 'adb shell' support running as root. I recommend using JesusFreke US RC30 or UK RC8 v1.2 recovery image. You can flash the RC30 v1.2 recovery.img on your G1 if you don't want to bother constructing your own image. Of course you are free to use your own recovery image and it will work if you set it up correctly.
- dump_image-arm and mkyaffs2image|mkyaffs2image-$ARCH compiled in the current dir, as well as root on a linux/mac (POSIX) machine for constructing system and data images. root is required because the uid, gid and file permissions need to be preserved while extracting and creating the yaffs2 images. You are free to run the script as a normal user and then run the appropriate commands yourself as root; the commands are printed when you run the script as a regular user.
If you don't trust the provided binaries, you are free to compile them yourself. The source for the tools are included. For dump_image, edit nandtools/android-imagetools/Makefile so that you use the proper cross compiling gcc. For mkyaffs2img, just running make in tartools/yaffs2/utils/ should give you a binary. You are on your own in getting stuff compiled, but it should be easy to figure out from the Makefile.
* How to use this (the easy part)
Just boot your phone in recovery mode with the correct recovery.img (one that has adb shell as root + busybox installed with symlinks to tar, md5sum etc) and connect it to your pc/laptop/server. Then run the nandroid.sh script. If something is wrong or missing, it will tell you.
* What about restore?
If you have the dev phone or have root on the G1 and flashed the engineering/dev bootloader, then you can power on your phone while holding camera to get into the bootloader/SPL. It should then show some androids on skateboards (if not, you don't have the engineering/dev bootloader). Plug in your USB cable and push back until it says FASTBOOT instead of Serial0. Now you can fire up fastboot flash {partition} {file.img}.
Fastboot itself is part of the android SDK. If you download and compile your own mydroid build, it should sit in mydroid/out/host/linux-x86/bin/fastboot Perhaps in a future version I'll include a restore script, but for now I don't see the need.
One tip, if you are in fastboot mode on your phone and 'fastboot devices' doesn't show anything, try as root. You might need to edit your udev setup to allow your user to access the phone's usb device (which is different from the one you're in when in recovery or normal boot).
* Where's the source?
Sources are included. They are copies of the Android sources with various changes mostly made by Brainaid.
Everything in the zip is also also available through subversion:
svn co http://svn.infernix.net/nandroid/
Note that I DO NOT recommend checking out the latest revision unless you know damn well what you are doing. No guarantees if you play with fire. At the very least do diff against the latest released version.
* Credits
Bash script hacked together by infernix.
dump_image adapted from flash_image and extended by Brainaid.
Original mtdutils source and mkyaffs2image source by Google.
[1] http://forum.xda-developers.com/showthread.php?t=455860
[2] http://forum.xda-developers.com/showthread.php?t=443713
[3] http://www.gotontheinter.net/fastboot
DOWNLOAD HERE or:
wget http://dx.infernix.net/nandroid-2.0.zip
Originally Posted by trmacdonal
How to Restore your phone on a Windows PC using a Nandroid backup
I am going to assume you already have a Nandroid backup created on your SD card using JF 1.31's recovery Alt-B feature. The backup will create a folder called nandroid on your SD.
What you need:
The Android SDK:
Fastboot Windows Binary in this post:http://forum.xda-developers.com/showpost.php?p=3083753&postcount=1
From your Nandroid backup you need three files:
data.img
system.img
boot.img
Steps to restore your phone
1) Put the files Adb and AdbWinApi.dll from the tools folder in the Android SDK into C:\WINDOWS\System32 folder on your PC. Substitute the correct drive letter if windows is not installed on you C: drive
2) Put the Windows Fastboot.exe into the C:\WINDOWS\System32 folder on your PC
3) Create a folder on the C: drive of your PC called android. The path should be C:\Android.
4) Copy the Nandroid backup files data.img, system.img, and boot.img from your SD card to the folder called Android you created by mounting your SD card as removable disk.
5) Unplug the USB cord and power off your phone
6) Power up your phone by holding CAMERA+POWER, you should see three androids on skateboards. If you don't see this go install the Engineering boot loader
7) Plug the USB cord back into your phone and press back. The screen on your phone should say fastboot.
8) Make sure your pc is using the correct driver. Open the device manager on your pc. It is helpfull to have all other USB storage devices besides your phone unplugged for this part. Look for a USB Mass Storage device in the list of the USB devices. Right click on it and update the driver. Pick the option to browse for a driver on your pc. The driver is located in the Android SDK your downloaded in the folder called usb_driver. If this is done right you will now see a device called HTC Dream
9) Press start, go to run and type cmd (If you are on Vista just type cmd in the search box and hit enter). The command prompt will pop up.
10) Type cd C:\android
then enter the following commands:
fastboot flash system system.img
it will say Sending, then writing and say OKAY if it was successful
then type
fastboot flash userdata data.img
wait for the second OKAY and type
fastboot flash boot boot.img
wait for the second OKAY and type
fastboot reboot
Your phone should now be restored exactly as you had it when it was backed up.
This sounds great! I just recently used the other script to make a backup, but this sounds like it's been a bit more polished
I attempted to compile the yaffs2 utils under OS X 10.5 and I encountered a problem during linking:
ln -s ../yaffs_ecc.c yaffs_ecc.c
gcc -c -I/usr/include -I.. -O2 -Wall -DCONFIG_YAFFS_UTIL -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wnested-externs -Winline -static yaffs_ecc.c -o yaffs_ecc.o
gcc -c -I/usr/include -I.. -O2 -Wall -DCONFIG_YAFFS_UTIL -Wshadow -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wnested-externs -Winline -static mkyaffsimage.c -o mkyaffsimage.o
mkyaffsimage.c:120: warning: ‘yaffs_CalcNameSum’ defined but not used
gcc -o mkyaffsimage yaffs_ecc.o mkyaffsimage.o
ld: absolute addressing (perhaps -mdynamic-no-pic) used in _process_directory from mkyaffsimage.o not allowed in slidable image
collect2: ld returned 1 exit status
make: *** [mkyaffsimage] Error 1
Any thoughts? I'm heading off to google to figure out what a 'slidable image' is.
-jwb
No idea, and I don't have access to a mac. You could change the makefile and skip compiling of mkyaffsimage, you only need mkyaffs2image, but you'll probably get similar errors.
infernix said:
No idea, and I don't have access to a mac. You could change the makefile and skip compiling of mkyaffsimage, you only need mkyaffs2image, but you'll probably get similar errors.
Click to expand...
Click to collapse
Google seems to imply its a common issue, possibly solved in a later XCode rev.. We'll see how that pans out.
mkyaffs2image on mac
It built just fine for me when I did the whole mydroid build. It's in out/host/darwin-x86/bin.
Is there some way to mount the yaffs2 image, though? Does one need to do the kernel patch etc on a linux box and then use loop?
Wow this a awesome. Thanks for all the hard work everyone.
you are are ridiculous.....ly good!
so you telling me if we have root and jf's modified rc30 v1.2 and be brick our phone, there's another quarter in your pocket after you die (game over) and you can start a whole new game?
hbguy
hbguy said:
so you telling me if we have root and jf's modified rc30 v1.2 and be brick our phone, there's another quarter in your pocket after you die (game over) and you can start a whole new game?
Click to expand...
Click to collapse
If you have flashed the engineering bootloader (the androids on skateboards appear when powering on your phone while holding camera button), yes.
haha very nice ::borat voice::
P.S. For the borat fans out there, he is making a new movie, insider info baby
hbguy!
Error messages but still makes backups?
I got the following when I ran nandroid.sh on my mac. Are the error messages safe to disregard -- it seems like it worked:
Code:
nandroid v2.0
mounting system and data read-only on device
error: device not found
error: device not found
start adb portforward on port 4531
error: device not found
checking free space on cache
error: device not found
./nandroid.sh: line 152: [: -le: unary operator expected
pushing tools to /cache: dump_image-arm... error: device not found
done
Getting md5sum on device for boot...error: device not found
done ()
Dumping boot from device over tcp to backup_2008-12-19//boot.img...
error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for boot.img
Getting md5sum on device for recovery...error: device not found
done ()
Dumping recovery from device over tcp to backup_2008-12-19//recovery.img...
error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for recovery.img
Getting md5sum on device for misc...error: device not found
done ()
Dumping misc from device over tcp to backup_2008-12-19//misc.img...
error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for misc.img
Getting md5sum on device for tar for system...error: device not found
done ()
Dumping tar file for system backup_2008-12-19//system.tar...error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for system.tar
To convert system.tar to system.img, run the following commands as root:
mkdir /tmp/-system-tmp
tar x -C /tmp/-system-tmp -f backup_2008-12-19//system.tar
/Users/brock/Inbox/nandroid-2.0/mkyaffs2image /tmp/-system-tmp/system backup_2008-12-19//system.img
Make sure that /tmp/-system-tmp doesn't exist befor you extract, or use different paths.
Remember to remove the tmp dirs when you are done.
Getting md5sum on device for tar for data...error: device not found
done ()
Dumping tar file for data backup_2008-12-19//data.tar...error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for data.tar
To convert data.tar to data.img, run the following commands as root:
mkdir /tmp/-data-tmp
tar x -C /tmp/-data-tmp -f backup_2008-12-19//data.tar
/Users/brock/Inbox/nandroid-2.0/mkyaffs2image /tmp/-data-tmp/data backup_2008-12-19//data.img
Make sure that /tmp/-data-tmp doesn't exist befor you extract, or use different paths.
Remember to remove the tmp dirs when you are done.
Getting md5sum on device for tar for cache...error: device not found
done ()
Dumping tar file for cache backup_2008-12-19//cache.tar...error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for cache.tar
To convert cache.tar to cache.img, run the following commands as root:
mkdir /tmp/-cache-tmp
tar x -C /tmp/-cache-tmp -f backup_2008-12-19//cache.tar
/Users/brock/Inbox/nandroid-2.0/mkyaffs2image /tmp/-cache-tmp/cache backup_2008-12-19//cache.img
Make sure that /tmp/-cache-tmp doesn't exist befor you extract, or use different paths.
Remember to remove the tmp dirs when you are done.
removing tools from /cache: dump_image-arm... error: device not found
done
unmounting system and data on device
error: device not found
error: device not found
Backup successful.
brocktice said:
I got the following when I ran nandroid.sh on my mac. Are the error messages safe to disregard -- it seems like it worked:
Code:
nandroid v2.0
mounting system and data read-only on device
error: device not found
[/QUOTE]
This didn't work at all.
What I don't really get is that it continues at all, if the device isn't connected it should not even start.
It's a bit hard to tell because I don't have a mac here. Please run the following commands on your mac and post them:
[code]which adb
adb devices
BLAH=foo
echo "without $BLAH"
echo "with ${BLAH}"
I'll look at this soon, should have access to a mac sometime in the next few weeks
Click to expand...
Click to collapse
brocktice said:
I got the following when I ran nandroid.sh on my mac. Are the error messages safe to disregard -- it seems like it worked:
Code:
nandroid v2.0
mounting system and data read-only on device
error: device not found
error: device not found
start adb portforward on port 4531
error: device not found
checking free space on cache
error: device not found
./nandroid.sh: line 152: [: -le: unary operator expected
pushing tools to /cache: dump_image-arm... error: device not found
done
Getting md5sum on device for boot...error: device not found
done ()
Dumping boot from device over tcp to backup_2008-12-19//boot.img...
error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for boot.img
Getting md5sum on device for recovery...error: device not found
done ()
Dumping recovery from device over tcp to backup_2008-12-19//recovery.img...
error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for recovery.img
Getting md5sum on device for misc...error: device not found
done ()
Dumping misc from device over tcp to backup_2008-12-19//misc.img...
error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for misc.img
Getting md5sum on device for tar for system...error: device not found
done ()
Dumping tar file for system backup_2008-12-19//system.tar...error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for system.tar
To convert system.tar to system.img, run the following commands as root:
mkdir /tmp/-system-tmp
tar x -C /tmp/-system-tmp -f backup_2008-12-19//system.tar
/Users/brock/Inbox/nandroid-2.0/mkyaffs2image /tmp/-system-tmp/system backup_2008-12-19//system.img
Make sure that /tmp/-system-tmp doesn't exist befor you extract, or use different paths.
Remember to remove the tmp dirs when you are done.
Getting md5sum on device for tar for data...error: device not found
done ()
Dumping tar file for data backup_2008-12-19//data.tar...error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for data.tar
To convert data.tar to data.img, run the following commands as root:
mkdir /tmp/-data-tmp
tar x -C /tmp/-data-tmp -f backup_2008-12-19//data.tar
/Users/brock/Inbox/nandroid-2.0/mkyaffs2image /tmp/-data-tmp/data backup_2008-12-19//data.img
Make sure that /tmp/-data-tmp doesn't exist befor you extract, or use different paths.
Remember to remove the tmp dirs when you are done.
Getting md5sum on device for tar for cache...error: device not found
done ()
Dumping tar file for cache backup_2008-12-19//cache.tar...error: device not found
done
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
md5sum verified for cache.tar
To convert cache.tar to cache.img, run the following commands as root:
mkdir /tmp/-cache-tmp
tar x -C /tmp/-cache-tmp -f backup_2008-12-19//cache.tar
/Users/brock/Inbox/nandroid-2.0/mkyaffs2image /tmp/-cache-tmp/cache backup_2008-12-19//cache.img
Make sure that /tmp/-cache-tmp doesn't exist befor you extract, or use different paths.
Remember to remove the tmp dirs when you are done.
removing tools from /cache: dump_image-arm... error: device not found
done
unmounting system and data on device
error: device not found
error: device not found
Backup successful.
Click to expand...
Click to collapse
I had this problem too but disconnecting and reconnecting the usb cable fixed it.
SplasPood said:
I had this problem too but disconnecting and reconnecting the usb cable fixed it.
Click to expand...
Click to collapse
Well the script is supposed to check for a device and stop when theres a problem.
also if this can happen at all then other things might go wrong on mac too. I think mac requires bash variables to be called like #{VAR} and doesn't handle $VAR for some reason.
update on mac issues
OK, it seems it was all a problem on my end -- didn't have the correct set-up. I now have the appropriate recovery image (thought I did, but I guess I didn't) and it seems to work, except for this:
Code:
Comparing md5sum...parseopts.c:76: setup_check: fopen '--status': No such file or directory
The images and such now have non-zero filesize, though. That's an improvement over before.
yeah i've gotten some more reports. will make it mac OS X compatible soonish
I can't seem to figure out how to get this to work. If someone who knows linux can IM me, that'd be great. (or is there a way to do this on XP?)
AIM:adventninja
Thanks in advance
Does this also back up radio and htc secure nand partitions?
tranks
backed up successfully.
for those who get errors in the script.
i assume you have installed modiffied recovery image + jesusfreke's rc30v2 and
before running the script check this.
this steps involves having linux i dont know how its done in windows maybe its the same i dont know.
1: disconnect usb cable
2: check that you have adb program in your path, eg: /usr/bin/adb
if you dont know what adb is, adb is a program to comunicate with phone via usb (its not the same as transfering files between pc and g1),
adb program is found in android-sdk-linux_x86-1.0_r2, unpack it, and copy adb to your path, just google and find latest android sdk.
once you downloaded sdk unpacked it and copied the executable file adb to /usr/bin go to next step.
3: boot the phone into recovery mode ( power up the phone and holding "power + home" keys and a triangle will appear on its screen.
4: in your pc open konsole, su root, and plug your USB G1
5: type adb devices
if the response to this command is "HTC G1 bla bla.. found.", then you are ready to execute the script, it will no give errors and you will backup its contents.
if you dont see HTC G1 words, then its likely your phone was detected as "USB MASS STORAGE", and we dont want that. we need that its detected as a "HTC DIRECT ACCESS DEVICE".
a: control +c
b: killall adb (this is important)
c: unplug USB, plug it in another port,
d: go to step 5
hope it helps.
infernix said:
* What is Nandroid Backup v2.0?
Nandroid Backup is a set of tools and a script that will enable anyone who has root on their G1 and has the engineering/dev spl bootloader [1] (or has a dev phone) + a recovery image with busybox and adbd running as root [2] to make full system backups. These can then be restored using the fastboot [3] commandline tool and your phone in SPL/bootloader mode (hold camera + power). This allows you to create regular backups of your entire phones NAND flash so that you can restore a backup when something breaks. Its backup method works on a level that allows you to completely break, wipe or corrupt any or all partitions and still restore the phone to a working state within a few minutes. This works great for those who use their G1 for normal activities but also want to test their ideas which might break the phone, or when not having an extra G1 to keep purely as a development phone.
* Requirements for use
- Android G1 phone in recovery mode with busybox installed, including appropriate symlinks to at least tar and md5sum, as well as 'adb shell' support running as root. I recommend using JesusFreke US RC30 or UK RC8 v1.2 recovery image. You can flash the RC30 v1.2 recovery.img on your G1 if you don't want to bother constructing your own image. Of course you are free to use your own recovery image and it will work if you set it up correctly.
- dump_image-arm and mkyaffs2image|mkyaffs2image-$ARCH compiled in the current dir, as well as root on a linux/mac (POSIX) machine for constructing system and data images. root is required because the uid, gid and file permissions need to be preserved while extracting and creating the yaffs2 images. You are free to run the script as a normal user and then run the appropriate commands yourself as root; the commands are printed when you run the script as a regular user.
If you don't trust the provided binaries, you are free to compile them yourself. The source for the tools are included. For dump_image, edit nandtools/android-imagetools/Makefile so that you use the proper cross compiling gcc. For mkyaffs2img, just running make in tartools/yaffs2/utils/ should give you a binary. You are on your own in getting stuff compiled, but it should be easy to figure out from the Makefile.
* How to use this (the easy part)
Just boot your phone in recovery mode with the correct recovery.img (one that has adb shell as root + busybox installed with symlinks to tar, md5sum etc) and connect it to your pc/laptop/server. Then run the nandroid.sh script. If something is wrong or missing, it will tell you.
* What about restore?
If you have the dev phone or have root on the G1 and flashed the engineering/dev bootloader, then you can power on your phone while holding camera to get into the bootloader/SPL. It should then show some androids on skateboards (if not, you don't have the engineering/dev bootloader). Plug in your USB cable and push back until it says FASTBOOT instead of Serial0. Now you can fire up fastboot flash {partition} {file.img}.
Fastboot itself is part of the android SDK. If you download and compile your own mydroid build, it should sit in mydroid/out/host/linux-x86/bin/fastboot Perhaps in a future version I'll include a restore script, but for now I don't see the need.
One tip, if you are in fastboot mode on your phone and 'fastboot devices' doesn't show anything, try as root. You might need to edit your udev setup to allow your user to access the phone's usb device (which is different from the one you're in when in recovery or normal boot).
* Where's the source?
Sources are included. They are copies of the Android sources with various changes mostly made by Brainaid.
Everything in the zip is also also available through subversion:
svn co http://svn.infernix.net/nandroid/
Note that I DO NOT recommend checking out the latest revision unless you know damn well what you are doing. No guarantees if you play with fire. At the very least do diff against the latest released version.
* Credits
Bash script hacked together by infernix.
dump_image adapted from flash_image and extended by Brainaid.
Original mtdutils source and mkyaffs2image source by Google.
[1] http://forum.xda-developers.com/showthread.php?t=455860
[2] http://forum.xda-developers.com/showthread.php?t=443713
[3] http://www.gotontheinter.net/fastboot
DOWNLOAD HERE or:
wget http://dx.infernix.net/nandroid-2.0.zip
Click to expand...
Click to collapse
hey infernix, did you happen to get a mac version of this together? thanks!

Testing ROM Images in the SDK Emulator!

I started looking at Android Development and got the whole Dev kit and the Eclipse enrionment setup and working fine.
The question I have is that I would try different apps I develop on the different ROMs available.
How do I get any of the new ROMs, like the HERO ROM ZIP files I can download to run in the emulator or is it even possible?
Im assuming that the system.img file in the SDK id the file I need to replace or re-create, but how is this done?
I am a noob to the develop stuff so step by step instructions would be much appreciated.
I also think this would be great for other developers and ROM makers to be able to test in this way.
Thanks
Simon
Hopefully THIS one dont get closed, it IS asking a development question...anyway,
I would like to know this as well. I would like to test things myself (getting better at manipulating them), and would like to know what he is asking as well.
Thanks.
I don't think this would work, as the ROMs are hardware depending, me thinks. Or at the least the kernel and drivers are.
maybe this will help, maybe not, just an emulator primer, so maybe people can jump on board with this
under <sdk path>/tools
to list out your AVD(android virtual device)
android list targets
will return:
Available Android targets:
id:1
Name: Android 1.1
Type: platform
API level: 2
Skins: HVGA (default), HVGA-L, HVGA-P, QVGA-L, QVGA-P
id:2
Name: Android 1.5
Type: platform
API level: 3
Skins: HVGA (default), HVGA-L, HVGA-P, QVGA-L, QVGA-P
id:3
Name: Google APIs
Type: add-on
Vendor: Google Inc.
Description: Android + Google APIs
Based on Android 1.5 (API level 3)
Libraries:
* com.google.android.maps (maps.jar)
API for Google Maps
Skins: HVGA (default), HVGA-L, QVGA-P, HVGA-P, QVGA-L
from here we choose our integer target, lets say 2
creating an AVD:
android create avd -n your_chosen_name_here -t 2
When you create an AVD, the android tool creates a dedicated directory for it on your development computer. The directory contains the AVD configuration file, the user data image and SD card image (if available), and any other files associated with the device. Note that the directory does not contain a system image — instead, the AVD configuration file contains a mapping to the system image, which it loads when the AVD is launched.
By default, the android tool creates the AVD directory inside ~/.android/avd/ (on Linux/Mac), C:\Documents and Settings\<user>\.android\ on Windows XP, and C:\Users\<user>\.android\ on Windows Vista
Click to expand...
Click to collapse
to run your newly created AVD:
emulator -avd your_chosen_name_here
maybe this will help, but I'm guessing everyone here already knows all of this.
references:
http://developer.android.com/guide/developing/tools/emulator.html#starting
Yeah, I understand that you can specify the AVD.
The only thing now is to edit the AVD to point to a different image. This is easy!
The system image file is a *.img file.
So how do we get our ROM images compiled into the IMG file format?
There must be a tool, but I cant find anything.
And what hardware does the emulator, emulate? Maybe it ignores the hardware specific calls throu an API so the ROM image target hardware shouldn't matter.
I just started messing around with rom's and after I build one I put system.img userdata.img and ramdisk.img from my /mydroid/out folder into the sdk's image folder and start the and it uses the new rom when I start the emulator
thats the easy part
do a nandroid backup
copy the sdk/platforms/android-1.5
to something like sdk/platforms/MINE
go to your AVD directory AVD/whateveryoucalledit
open up the config.ini
edit:
skin.name=HVGA
skin.path=platforms\MINE\skins\HVGA
image.sysdir.1=platforms\MINE\images\
go to your nandroid backup on your sdcard
copy system.img
go to sdk/platforms/MINE/images/
and paste the nandroid system.img
now run your AVD and it will boot that system.img
im running CyanogenMod rom right now in the emulator
hint* number pad 7 with numlock off in the emulator is how to open up the hardware keyboard
Awesome. I'll be giving this a try later.
One question: The apps are in the system.img file on the SDK images as far as I can tell. What do you do with all the apps in the new ROMs?
whatever you want to do with them, they're all there, even android market works perfectly
And where are you guys getting the system.img file from?
The ROM zip files dont have them.
Sorry....Im noob to this. LOL
ggolemg said:
whatever you want to do with them, they're all there, even android market works perfectly
Click to expand...
Click to collapse
OK, Im confused. Can you just unzip the ROM files and place in the folder that you point using the same folder structure?
OR
Do you have to have a system.img ?
Another thought:
I dont want to have to install all the ROMs just to create a Nandroid backup to get the images. There must be a way to create the images from the raw files in the ZIP files.
Any ideas?
UPDATE: The same technology used by Nandroid itself!
The google android emulator included in the google android sdk is limited. Although you can use 'adb push' to upload more tools, but one has to do it again next time. Follow the steps to create a enhanced system.img:
1. system.img is yaffs2 flash file system, so firstly you need the mkfs.yaffs2 tool, download it in the following link: Release Android Yaffs2 Tool (Both X86 And ARM). One has to be a registered user to download the tools.
2. use the 'adb push' to upload tools to android emulator, executables in /system/bin/, libraries in /system/lib, one can also create folder. One need change the file mode necessary.
3. upload the ARM mkfs.yaffs2 tool, use the following command to create system.img: # mkfs.yaffs2 /system /system.img
4. download the system.img to local with command 'adb pull', replace the system.img in your emulator folder/tools/lib/images/
Click to expand...
Click to collapse
so it seems like it would be just as much fun doing a nandroid backup
*edit*
so now the real question is, how do we go about ripping out the nandroid functionality to be able to do this locally?
*edit 2*
it is the mkfs.yaffs2 tool
Usage:
mkfs.yaffs2 yourdir yourimage
Ohsaka said:
NANDROID - CYGWIN DIRECTIONS (not not not, I repeat, not fully tested and verified yet)
Changes so far if you are using cygwin:
1) Make sure you have the 'netcat' and 'gcc' packages, else just run cygwin.exe again and get them.
You can test if you have them by running 'which nc' and 'which gcc', both commands should return /usr/bin/<command>
2) Compile the mkyaffs2image executable.
Inside the extracted nandroid archive directory, goto the tartools\yaffs2\utils\ directory (inside a cygwin prompt) and type 'make'.
This should generate a file named "mkyaffs2image.exe" which you need to place somewhere on your path.
(Hint: If you haven't downloaded the Android SDK, abort now. Wait for more explicit directions... Else, place the .exe where adb is, since it should be on your path already)
3) Edit the nandroid.sh script. (else you get a permission denied error when the script tries to run the dump_image-arm file)
Find the line:
adb push ./$tool /cache/$tool
Add the following line after it:
adb shell chmod 777 /cache/$tool
4) Make a managed mount named /tmp (else windows will puke on the long unix filenames with colons, etc)
mkdir /tmp
mount -o managed c:/cygwin/tmp /tmp (Note: change c:/cygwin to be the directory cygwin was installed to, you can find it by typing 'cd /' and then 'explorer .')
5) Follow the standard "tar + mkyaffs2image" directions to generate the last three .img files. They refer to the /tmp directory which you created in the previous step.
Viola! Looks like I have a complete backup image now...
$ ls -l
total 117504
-rw-r--r-- 1 Osaka None 2621440 Jun 12 21:31 boot.img
-rw------- 1 Osaka None 737088 Jun 12 22:07 cache.img
-rw------- 1 Osaka None 53570880 Jun 12 22:06 data.img
-rw-r--r-- 1 Osaka None 262144 Jun 12 21:31 misc.img
-rw-r--r-- 1 Osaka None 5242880 Jun 12 21:31 recovery.img
-rw------- 1 Osaka None 57885696 Jun 12 22:06 system.img
Now I just need to drink up the courage to test it on my phone!
Click to expand...
Click to collapse
ggolemg said:
so it seems like it would be just as much fun doing a nandroid backup
*edit*
so now the real question is, how do we go about ripping out the nandroid functionality to be able to do this locally?
*edit 2*
it is the mkfs.yaffs2 tool
Usage:
mkfs.yaffs2 yourdir yourimage
Click to expand...
Click to collapse
Is this for Linux (which I don't have) and if so, is there a Windows version?
short answer: yes its only for linux
long answer is a plea for help i posted in the nandroid thread about it:
I was wondering if there was a method to use the yaffs3 command to make a system.img from an unzipped rom placed on the sdcard through ADB, from what I've seen nandroid is almost exactly what I'm after.
The issue of why I can not just do this through linux, i can. I just want to be able to do it through windows some way without loading the entire rom on the phone and nandroiding the system.img out.
Either the aforementioned method, or the ability to mount a portion of my computers hard drive as a recognizable mountable partition within android running on the usb connected phone, loading the rom on that partition, unzipping it there, running ADB and making the system.img. But this way seems to bring up more problems than it's worth.
Or.. running the make yaffs3 command through ADB running the emulator with the rom unzipped on the virtual sdcard. This would actually be the best option as it would not require an actual phone.
I hope someone can help. Thank you very much.
Click to expand...
Click to collapse
hopefully someone knows the answer, I'm still trying though.
so on windows we would adb push the update.zip to the sdcard on the emulator
unzip it on the sdcard, there are apps for that
adb shell mkfs.yaffs2 sdcard/<extractedzipfilename>/system/ sdcard/system.img
adb pull the newly created system.img and proceed to load it in the emulator
i know im missing a ton here, please someone correct me
I'd love to be able to run these images in the emulator on windows!
ggolemg said:
thats the easy part
do a nandroid backup
copy the sdk/platforms/android-1.5
to something like sdk/platforms/MINE
go to your AVD directory AVD/whateveryoucalledit
open up the config.ini
edit:
skin.name=HVGA
skin.path=platforms\MINE\skins\HVGA
image.sysdir.1=platforms\MINE\images\
go to your nandroid backup on your sdcard
copy system.img
go to sdk/platforms/MINE/images/
and paste the nandroid system.img
now run your AVD and it will boot that system.img
im running CyanogenMod rom right now in the emulator
hint* number pad 7 with numlock off in the emulator is how to open up the hardware keyboard
Click to expand...
Click to collapse
Hm, the emulator just hangs on the ANDROID.. message, similar to when the standard system.img was in.
anyone figure out how to do this on a mac?
thanks if anyone can.
johnnylicious said:
anyone figure out how to do this on a mac?
thanks if anyone can.
Click to expand...
Click to collapse
I found this somewhere else and take no credit for it. I did shorten the steps.
Of course this is once you have the sdk installed on your mac
1. Run Terminal, and change to the 'tools' directory of the SDK (or add the tools directory to the path settings in ~/.profile).
2. Type './android list target'
3. Note the 'id' number of the '1.5' target (in my case it's '2')
4. Type './android create avd -n enhanced -t 2' (substitute 2 with the target number determined above if required)
5. You will be prompted to create a hardware profile. {You can leave as default no}
6. Use nandroid to create a backup then copy system.img
7. Copy file to ~/.android/avd/enhanced.avd/system.img
8. You're ready! Type './emulator -avd enhanced' to run! Note: inital boot may take a few minutes!
Can anyone post up the
Android Yaffs2 Tool (Both X86 And ARM)
for download? The above link doesn't work. I did a google search and all the D/L links are referring to the same location.
thanks!

[GUIDE] Make your android device True Root! - by Napalm

[GUIDE] Make your android device True Root! - by Napalm​
I did this on my Nexus 7 but it should all still apply to most devices. You might need to follow different driver advice for other devices.
Pre-requirements:
Installation of the SDK platform-tools.
Have platform-tools directory of the SDK in your PATH environment variable (Google this if your unsure).
This was all done a Windows installation, but access to Linux will be required later on. Mac users might be able to get away with doing the Linux portions directly on there computer. Please let me know if your a Mac user and have had success with this and I will update the guide with details.
Step 1: Driver Installation (READ THIS, do not skip)
First I needed to update to the usb_driver from SDK and then modify the installation inf with the IDs for Nexus 7.
Browse to your SDK directory and futher into <SDK>\extras\google\usb_driver
Open android_winusb.inf in your favorite text editor.
Find the appropriate section Google.NTx86 if your on 32bit or Google.NTamd64 if your on 64bit (doesnt matter that your using intel chip). Now find the ";Google Nexus 7" line inside that section and you'll see a series of settings below. Add the following lines at the end of that block.
Code:
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E44&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_D001
These are the identifiers for the Nexus 7 recovery and bootloader usb connections.
Step 2: Standard Root
Next you'll need access to the bootloader and recovery mode so follow this guide to unlock and "root" your device. http://forum.xda-developers.com/showthread.php?t=1741395
Here I've laid out the steps I did instead of the above. Remember this wipes your device and its internal memory completely, so backup your data.
All local work is done from the desktop, so when you first open a command prompt or if you close it and reopen it enter the following.
Code:
cd Desktop
Download CWM recovery image to Desktop. http://goo.im/devs/birdman/CWM-grouper-recovery.img
Download SuperSU CWM update zip to Desktop. http://forum.xda-developers.com/showthread.php?t=1538053
Go to Start or Start>Run and type in: cmd
Code:
cd Desktop
fastboot oem unlock
fastboot flash recovery CWM-grouper-recovery.img
adb reboot recovery
Now the device will reboot into recovery mode. If windows asks for drivers for the "new" usb connection direct the wizard to your <SDK>\extras\google\usb_driver. And the earlier modifications made in Step 1 should mean it installs the device and adb link.
Once drivers are installed and every is good go back to the command prompt, and type
Code:
adb devices
It should list your device with the word "recovery" next to it. If it doesn't then your device is not in recovery mode. Now enter in the following commands into the command prompt and it will make your devices CWM installation permanent.
Code:
adb shell
mount /system
cd /system
mv recovery-from-boot.p recovery-from-boot.bak
umount /system
exit
Now to install SuperSU. Tap "reboot system now" on the screen (if you dont see CWM, press the power button to show/hide it). Wait for the reboot. And then enter the following into the command prompt.
Code:
adb push CWM-SuperSU-v0.94.zip /sdcard
adb reboot recovery
Wait for reboot. You should see an image in the center of the screen. You might have to press the power button to toggle the visibility of the CWM menu. If you miss-tap on the screen, the power button acts like a back button and will return you to the previous menu screen.
Tap "install zip from sdcard" and then "choose zip from sdcard". Then select the CWM-SuperSU-v0.94.zip file (You may have to use the vol-up/down keys to highlight this if the file is listed off the bottom of the screen)
Let that install and then go back on the menus and choose "reboot system now".
Now if all is well after the reboot, if you run the following commands in command prompt.
Code:
adb shell
su
SuperSU might now prompt you on your devices screen to accept the root access, and then hopefully your command prompt should end in a # (this means you are root user 0). Now type exit twice to get back to the windows command prompt.
Now if you were to type "adb root" you will notice it tells you adbd is not able to go "full root". This will be solved in the next step. This is going to get complicated. You have been warned.
Step 3: True Rooting!
Now your device is "rooted". This is true, you now have a "su" binary installed and a visible app in the OS to manage super user privileges, but as a developer I want to be able to use things like "hierarchy viewer" on my live device. And have the room to do what I need to debug complex situations. So this is where True Root comes in. This essentially turns the device into a debug device that you would get direct from the manufacturer.
You may be able to get away with doing the following in a different way and you may not need to compile anything since fastboot has a boot flash option, but since I've never used this I've done it this way. If you prefer you can explore things in that direction, but be warned I've not tried it and so I have no idea if it would work.
Now for this step you will need access to a Linux installation. If you've never used Linux before don't be too afraid. But I am going to have to gloss over a few things. If you need further help on this step you will need to post in the topic and allow the community to advise on best pratices.
If you dont have access to a Linux installation or your newb to Linux then go here and follow the steps. It will add Linux to your PCs boot options and then you can go in and out of Linux when you need it. http://www.ubuntu.com/download/help/install-ubuntu-with-windows
Remember if your working on this step from a fresh Linux install like the above then you will probably want to install the android sdk for linux, at least enough to use adb from linux. This topic might help with this: http://forum.xda-developers.com/showthread.php?t=537508
Ok now from Linux follow along. You'll need git installed for this "apt-get install git".
We now need to compile the apps needed to modify our boot image. Details can be found here https://gist.github.com/1087757 but you might just want to follow my specific instructions.
Open a console window and type.
Code:
git clone https://android.googlesource.com/platform/system/core
cd core/libmincrypt
gcc -c *.c -I../include
ar rcs libmincrypt.a *.o
cd ../mkbootimg
gcc mkbootimg.c -o mkbootimg -I../include ../libmincrypt/libmincrypt.a
cd ../cpio
gcc mkbootfs.c -o mkbootfs -I../include
cd ../..
git clone https://github.com/beide/Bootimg-scripts.git
cd Bootimg-scripts
cp ../core/mkbootimg/mkbootimg ./
cp ../core/cpio/mkbootfs ./
Ok that has prapared the a Bootimg-scripts directory with the perl scripts we need and compiled binaries they use. Now make sure you have perl installed "apt-get install perl".
This is where things are going to split and it becomes your best guess as to how to proceed. I will show you the method I used from Windows. But if you have a installation of the SDK in Linux then you should be able to just open a new console and continue from here and ignore the bits I used to transfer files between Linux and Windows.
Back to the command console on Windows. We use adb to identify our boot partition and extract it.
Code:
adb shell cat /proc/partitions
You will now be presented with a list of paritions on your Nexus 7. Each block here for my device is 1K. So I'm looking down the list and I see one thats 8192 blocks, called "mmcblk0p2". Thats 8MB and I'm taking a educated guess that this is the boot partition, and for my Nexus 7 it is. (Note: if anyone has a better way of determining the boot parition please let me know).
Now we need to take a image of the partition. From here on out replace my partition device name in the commands below with yours if it differs.
Code:
adb shell
cat /dev/block/mmcblk0p2 > /sdcard/boot.img
exit
adb pull /sdcard/boot.img
Now if you want to confirm that this is the boot partition you will need to open the image file in your favorite hex editor and confirm the first bytes of the file are "ANDROID!" in ascii.
Now I FTP'd this image file over to my Linux box and into the Bootimg-scripts directory we created previously. If your following these steps from Linux then you should be able to open up the file manager and move the file into the folder.
Now back to Linux. We'll need to modify repack-bootimg.pl with a text editor of your choice. I leave this up to the reader. We need to modify line 19 the system call so that it starts with "./mkbootimg" rather than "mkbootimg". This is so perl fines mkbootimg in the local directory rather than anywhere else.
Now type in the linux console we had open in the Bootimg-scripts directory the following command.
Code:
perl ./unpack-bootimg.pl boot.img
ls -l
You should see boot.img-kernel.gz and boot.img-ramdisk.cpio.gz and a directory boot.img-ramdisk.
Open boot.img-ramdisk/default.prop in your favorite text editor and make the following adjustments.
ro.secure=1 should be edited to ro.secure=0 and ro.debuggable=0 should be ro.debuggable=1 and if you want ro.allow.mock.location can also be changed to 1 if you like.
Now we've made the required changes to our initrd (initial ramdisk) files we need to repack them to put back on the device.
Code:
perl ./repack-bootimg.pl boot.img-kernel.gz boot.img-ramdisk boot-debug.img
You will now have a new file called boot-debug.img. This contains our modified initial ramdisk. It will probably be smaller than the original. This is no concern as the original we copied was an image of the entire disk including the unused areas, where as the new image is only the data we need.
I now FTP'd this file back to my Windows machine, but as before if your doing this from Linux then you can just carry on.
We now need to flash this image file back onto the Nexus 7 replacing our current boot image. To do this we need to put the device into bootloader mode.
Back to your console/command window, and enter in.
Code:
adb reboot bootloader
Windows might want to install drivers and as before direct the wizard to <SDK>\extras\google\usb_driver.
Once your device is in bootloader mode. Go back to the console/command and enter in.
Code:
fastboot flash boot boot-debug.img
fastboot reboot
Now cross your fingers and hopefully you will get the boot loading animation and your device will get back to the Android launcher.
Now finally from your console/command window type in:
Code:
adb root
Hopefully if all is well it should reply with "adbd is already running as root". Now if you type in:
Code:
adb shell getprop ro.debuggable
It should tell you that its set to 1, meaning it is switched on.
Congratulations!! You have now True Rooted your device!.
You can now debug even system level apps, see log messages from all processes and logcat will now resolve all app names. Use Hierarchy Viewer on a live device instead of the horrible emulator. Do absolutely everything with your device that you want.
Happy hacking,
Napalm :good:
better late than never.....a thorough quide
Thanks for this guide.
Sent from my Nexus 7
Thanks.
Napalm2 said:
[GUIDE] Make your android device True Root! - by Napalm​
I did this on my Nexus 7 but it should all still apply to most devices. You might need to follow different driver advice for other devices.
Pre-requirements:
Installation of the SDK platform-tools.
Have platform-tools directory of the SDK in your PATH environment variable (Google this if your unsure).
This was all done a Windows installation, but access to Linux will be required later on. Mac users might be able to get away with doing the Linux portions directly on there computer. Please let me know if your a Mac user and have had success with this and I will update the guide with details.
Step 1: Driver Installation (READ THIS, do not skip)
First I needed to update to the usb_driver from SDK and then modify the installation inf with the IDs for Nexus 7.
Browse to your SDK directory and futher into <SDK>\extras\google\usb_driver
Open android_winusb.inf in your favorite text editor.
Find the appropriate section Google.NTx86 if your on 32bit or Google.NTamd64 if your on 64bit (doesnt matter that your using intel chip). Now find the ";Google Nexus 7" line inside that section and you'll see a series of settings below. Add the following lines at the end of that block.
Code:
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E44&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_D001
These are the identifiers for the Nexus 7 recovery and bootloader usb connections.
Step 2: Standard Root
Next you'll need access to the bootloader and recovery mode so follow this guide to unlock and "root" your device. http://forum.xda-developers.com/showthread.php?t=1741395
Here I've laid out the steps I did instead of the above. Remember this wipes your device and its internal memory completely, so backup your data.
All local work is done from the desktop, so when you first open a command prompt or if you close it and reopen it enter the following.
Code:
cd Desktop
Download CWM recovery image to Desktop. http://goo.im/devs/birdman/CWM-grouper-recovery.img
Download SuperSU CWM update zip to Desktop. http://forum.xda-developers.com/showthread.php?t=1538053
Go to Start or Start>Run and type in: cmd
Code:
cd Desktop
fastboot oem unlock
fastboot flash recovery CWM-grouper-recovery.img
adb reboot recovery
Now the device will reboot into recovery mode. If windows asks for drivers for the "new" usb connection direct the wizard to your <SDK>\extras\google\usb_driver. And the earlier modifications made in Step 1 should mean it installs the device and adb link.
Once drivers are installed and every is good go back to the command prompt, and type
Code:
adb devices
It should list your device with the word "recovery" next to it. If it doesn't then your device is not in recovery mode. Now enter in the following commands into the command prompt and it will make your devices CWM installation permanent.
Code:
adb shell
mount /system
cd /system
mv recovery-from-boot.p recovery-from-boot.bak
umount /system
exit
Now to install SuperSU. Tap "reboot system now" on the screen (if you dont see CWM, press the power button to show/hide it). Wait for the reboot. And then enter the following into the command prompt.
Code:
adb push CWM-SuperSU-v0.94.zip /sdcard
adb reboot recovery
Wait for reboot. You should see an image in the center of the screen. You might have to press the power button to toggle the visibility of the CWM menu. If you miss-tap on the screen, the power button acts like a back button and will return you to the previous menu screen.
Tap "install zip from sdcard" and then "choose zip from sdcard". Then select the CWM-SuperSU-v0.94.zip file (You may have to use the vol-up/down keys to highlight this if the file is listed off the bottom of the screen)
Let that install and then go back on the menus and choose "reboot system now".
Now if all is well after the reboot, if you run the following commands in command prompt.
Code:
adb shell
su
SuperSU might now prompt you on your devices screen to accept the root access, and then hopefully your command prompt should end in a # (this means you are root user 0). Now type exit twice to get back to the windows command prompt.
Now if you were to type "adb root" you will notice it tells you adbd is not able to go "full root". This will be solved in the next step. This is going to get complicated. You have been warned.
Step 3: True Rooting!
Now your device is "rooted". This is true, you now have a "su" binary installed and a visible app in the OS to manage super user privileges, but as a developer I want to be able to use things like "hierarchy viewer" on my live device. And have the room to do what I need to debug complex situations. So this is where True Root comes in. This essentially turns the device into a debug device that you would get direct from the manufacturer.
You may be able to get away with doing the following in a different way and you may not need to compile anything since fastboot has a boot flash option, but since I've never used this I've done it this way. If you prefer you can explore things in that direction, but be warned I've not tried it and so I have no idea if it would work.
Now for this step you will need access to a Linux installation. If you've never used Linux before don't be too afraid. But I am going to have to gloss over a few things. If you need further help on this step you will need to post in the topic and allow the community to advise on best pratices.
If you dont have access to a Linux installation or your newb to Linux then go here and follow the steps. It will add Linux to your PCs boot options and then you can go in and out of Linux when you need it. http://www.ubuntu.com/download/help/install-ubuntu-with-windows
Remember if your working on this step from a fresh Linux install like the above then you will probably want to install the android sdk for linux, at least enough to use adb from linux. This topic might help with this: http://forum.xda-developers.com/showthread.php?t=537508
Ok now from Linux follow along. You'll need git installed for this "apt-get install git".
We now need to compile the apps needed to modify our boot image. Details can be found here https://gist.github.com/1087757 but you might just want to follow my specific instructions.
Open a console window and type.
Code:
git clone https://android.googlesource.com/platform/system/core
cd core/libmincrypt
gcc -c *.c -I../include
ar rcs libmincrypt.a *.o
cd ../mkbootimg
gcc mkbootimg.c -o mkbootimg -I../include ../libmincrypt/libmincrypt.a
cd ../cpio
gcc mkbootfs.c -o mkbootfs -I../include
cd ../..
git clone https://github.com/beide/Bootimg-scripts.git
cd Bootimg-scripts
cp ../core/mkbootimg/mkbootimg ./
cp ../core/cpio/mkbootfs ./
Ok that has prapared the a Bootimg-scripts directory with the perl scripts we need and compiled binaries they use. Now make sure you have perl installed "apt-get install perl".
This is where things are going to split and it becomes your best guess as to how to proceed. I will show you the method I used from Windows. But if you have a installation of the SDK in Linux then you should be able to just open a new console and continue from here and ignore the bits I used to transfer files between Linux and Windows.
Back to the command console on Windows. We use adb to identify our boot partition and extract it.
Code:
adb shell cat /proc/partitions
You will now be presented with a list of paritions on your Nexus 7. Each block here for my device is 1K. So I'm looking down the list and I see one thats 8192 blocks, called "mmcblk0p2". Thats 8MB and I'm taking a educated guess that this is the boot partition, and for my Nexus 7 it is. (Note: if anyone has a better way of determining the boot parition please let me know).
Now we need to take a image of the partition. From here on out replace my partition device name in the commands below with yours if it differs.
Code:
adb shell
cat /dev/block/mmcblk0p2 > /sdcard/boot.img
exit
adb pull /sdcard/boot.img
Now if you want to confirm that this is the boot partition you will need to open the image file in your favorite hex editor and confirm the first bytes of the file are "ANDROID!" in ascii.
Now I FTP'd this image file over to my Linux box and into the Bootimg-scripts directory we created previously. If your following these steps from Linux then you should be able to open up the file manager and move the file into the folder.
Now back to Linux. We'll need to modify repack-bootimg.pl with a text editor of your choice. I leave this up to the reader. We need to modify line 19 the system call so that it starts with "./mkbootimg" rather than "mkbootimg". This is so perl fines mkbootimg in the local directory rather than anywhere else.
Now type in the linux console we had open in the Bootimg-scripts directory the following command.
Code:
perl ./unpack-bootimg.pl boot.img
ls -l
You should see boot.img-kernel.gz and boot.img-ramdisk.cpio.gz and a directory boot.img-ramdisk.
Open boot.img-ramdisk/default.prop in your favorite text editor and make the following adjustments.
ro.secure=1 should be edited to ro.secure=0 and ro.debuggable=0 should be ro.debuggable=1 and if you want ro.allow.mock.location can also be changed to 1 if you like.
Now we've made the required changes to our initrd (initial ramdisk) files we need to repack them to put back on the device.
Code:
perl ./repack-bootimg.pl boot.img-kernel.gz boot.img-ramdisk boot-debug.img
You will now have a new file called boot-debug.img. This contains our modified initial ramdisk. It will probably be smaller than the original. This is no concern as the original we copied was an image of the entire disk including the unused areas, where as the new image is only the data we need.
I now FTP'd this file back to my Windows machine, but as before if your doing this from Linux then you can just carry on.
We now need to flash this image file back onto the Nexus 7 replacing our current boot image. To do this we need to put the device into bootloader mode.
Back to your console/command window, and enter in.
Code:
adb reboot bootloader
Windows might want to install drivers and as before direct the wizard to <SDK>\extras\google\usb_driver.
Once your device is in bootloader mode. Go back to the console/command and enter in.
Code:
fastboot flash boot boot-debug.img
fastboot reboot
Now cross your fingers and hopefully you will get the boot loading animation and your device will get back to the Android launcher.
Now finally from your console/command window type in:
Code:
adb root
Hopefully if all is well it should reply with "adbd is already running as root". Now if you type in:
Code:
adb shell getprop ro.debuggable
It should tell you that its set to 1, meaning it is switched on.
Congratulations!! You have now True Rooted your device!.
You can now debug even system level apps, see log messages from all processes and logcat will now resolve all app names. Use Hierarchy Viewer on a live device instead of the horrible emulator. Do absolutely everything with your device that you want.
Happy hacking,
Napalm :good:
Click to expand...
Click to collapse
can't find recovery-from-boot.p. Y?
5implelove said:
can't find recovery-from-boot.p. Y?
Click to expand...
Click to collapse
Try not to quote a post that big mate, makes navigation a pain
5implelove said:
can't find recovery-from-boot.p. Y?
Click to expand...
Click to collapse
That part is only for the Nexus 7, and if you are using a Nexus 7 with custom ROM then this file may not exist. If you are using stock on a Nexus 7 then the only other question is whether you have renamed/moved/deleted it before. Once you
Code:
cd /system
type
Code:
ls -l recovery*
and see if anything is listed.
Napalm
Where did you find the info for step one?
Sent from my Nexus 7 using Tapatalk 2
I worked it out. You can find your VID and PID from your unknown device in Device Manager. You have to right click the device > Properties > Details > Choose Hardware Ids from the list. Since the driver from Google supports the same interfaces for other devices we can assume it works with the Nexus 7. I made the modifications and it works. Below is a full list of IDs if anyone wants them.
Napalm
Code:
Nexus 7
USB\VID_18D1&PID_4E40 : fastboot
USB\VID_18D1&PID_D001 : adb-recovery
USB\VID_18D1&PID_4E42 : composite-adb-interface (with mtp)
USB\VID_18D1&PID_4E42&MI_00: mtp-composite
USB\VID_18D1&PID_4E42&MI_01: adb-composite
USB\VID_18D1&PID_4E44 : composite-adb-interface (with ptp)
USB\VID_18D1&PID_4E44&MI_00: mtp-composite
USB\VID_18D1&PID_4E44&MI_01: adb-composite
USB\VID_18D1&PID_4E41 : mtp-only
USB\VID_18D1&PID_4E43 : ptp-only
Galaxy Nexus
USB\VID_18D1&PID_4E30 : fastboot
USB\VID_18D1&PID_D001 : adb-recovery
USB\VID_04E8&PID_6860 : composite-adb-interface (with mtp)
USB\VID_04E8&PID_6860&MI_00: mtp-composite
USB\VID_04E8&PID_6860&MI_01: adb-composite
USB\VID_04E8&PID_6866 : composite-adb-interface (with ptp)
USB\VID_04E8&PID_6866&MI_00: ptp-composite
USB\VID_04E8&PID_6866&MI_01: adb-composite
USB\VID_04E8&PID_685C : mtp-only
USB\VID_04E8&PID_6865 : ptp-only
Great guide, but why not just post up the new initrd for people that don't want to do this? It looks as if its the same for all devices.
As requested. Attached are the compiled tools and modified scripts used and the original and modified boot partition image files for the Nexus 7 running Android 4.1.2.
Napalm
Update for Android 4.2
Attached is the original and modified boot partition image files for the Nexus 7 running Android 4.2.
You can update yours with the following:
Code:
adb reboot-bootloader
fastboot flash boot nakasi-jop40c-android42-boot-new.img
Napalm
Attached is the original and modified boot partition image files for the Nexus 7 GSM/HSPA+ running Android 4.2.1
You can update yours with the following:
Code:
adb reboot-bootloader
fastboot flash boot nakasig-jop40d-android421-boot-new.img
Napalm
Amazing !
Is it possible to post the same file for N7 4.2.1 Wifi version?
Thanks
JulienDev said:
Amazing !
Is it possible to post the same file for N7 4.2.1 Wifi version?
Thanks
Click to expand...
Click to collapse
If I'm not mistaken, they are the same for wifi and 3g versions?
Same as before.. just an update for Android 4.2.2... as per the previous posts.. no idea if the non-GSM variant has the same boot partition. If anyone can test please post.
Attached is the original and modified boot partition image files for the Nexus 7 GSM/HSPA+ running Android 4.2.2
You can update yours with the following:
Code:
adb reboot-bootloader
fastboot flash boot nakasig-jdq39-android422-boot-mod.img
Getting a No_Command error
Hi, I am trying to true root Android M on my Nexus 7 2012 Wifi edition. I followed the steps here and was able to create the boot.img with the ro.debuggable=1 and ro.secure=0. however if i flash this boot.img the device boots and gets stuck in a android bot with a Red ! (bang) triangle. and says No command.
Any idea how to get ro.debuggable on for Android M?

[GUIDE] Build CyanogenMod (or AOSP) from source

Start building!​Requirements:
A good CPU (2 cores more prefered)
4 GB RAM or more
Knowledge of using Linux
Time and patience
Step 0: (getting ready)
Make sure you have at least 50GB space free and all the required packages installed.
You can get a guide to installing packages on Ubuntu here.
Step 1:
Get the repo tool installed.
A guide for this over here.
Step 2:
Create a folder in your home directory named 'android'. This can also be any other name in any other place just make sure you remember the path.
Step 3:
Run
Code:
cd ~/android/
inside a Terminal (or the path you created the directory in)
Step 4: (getting the source)
Inside your android folder run
Code:
repo init -u git://github.com/S6310-Development/android.git -b cm-11.0
You can edit the 'cm-11.0' parameter to the version of CyanogenMod you want to build. Currently supported versions are 'cm-11.0' and 'cm-12.0'.
After you ran the command run
Code:
repo sync
The syncing can take from half an hour up to a few days. This depends on your Internet connection. On a 30Mbits/s connection it takes about two to three hours to sync.
Step 5: (preparing the build)
Make sure your PATH variable points to Python 2.7 if you have multiple instances of Python installed.
Step 6:
Open up a Terminal window in the Android source tree. (for people who followed step 2 exactly this is '~/android/')
Step 7: (building)
We have provided a prebuilt build script so no new one has to be made. You can run this script with
Code:
./build-script.sh
Select your device once the selection comes up and select the build type depending on the type of build you want to create.
We use 'userdebug' for releases and 'eng' for testing and debugging. 'user' in general is never touched by us.
Happy building!​
must try if i have

[GUIDE] How to fix the touchscreen in TWRP (Moto G 5G)

In this guide a describe how you can easily fix the touchscreen issue in TWRP for Moto G 5G.
Before providing the necessary steps, I would like to express my gratitude to the guys here, especially Andrew Hexen for providing the sources and instructions to build the TWRP for this great device.
Building the TWRP from source might result in a recovery without the touchscreen support. To fix that, you can follow these simple steps.
First, we need to extract the touchscreen drivers from the phone. To do this, you need to boot to TWRP. Connect your phone to your PC, open up the terminal and type:
Bash:
# reboot to bootloader
adb reboot bootloader
# boot to recovery
fastboot boot twrp.img
Wait for the phone to boot to recovery. If your phone uses password/PIN or other forms of protection you might have to decrypt the filesystem before proceeding. You can use OTG mouse to do that.
On your PC, in terminal type:
Bash:
adb pull "/vendor/lib/modules/" <path to where you want the modules folder to be pulled>
This will pull from the phone all the necessary drivers, among those are the drivers for the touchscreen. (Probably you could pull just the touchscreen driver, but to be sure I pulled everything.)
On you PC, use Android Kitchen to unpack the recovey image. I usually use the terminal to go to the Android Kitchen folder and I run:
Bash:
./unpacking.sh <path to your twrp.img>
Then go to ramdisk folder that was created by Android Kitchen
Bash:
cd ramdisk
and manually create the following folder:
Bash:
sudo mkdir -p vendor/lib/modules
Then copy the drivers you previously pulled from your phone to this folder:
Bash:
sudo cp <path to modules folder with drivers>/* vendor/lib/modules/
In the ramdisk folder open the init.rc file. We need to open it as su user. You can use:
Bash:
sudo gedit
and then open the file from the editor.
Find the following lines:
Code:
# Load properties, Android 6.0+, vendor init lives here
on load_persist_props_action
load_persist_props
and add a line after load_persist_props so that you get:
Code:
# Load properties, Android 6.0+, vendor init lives here
on load_persist_props_action
load_persist_props
start load_modules # this is the line you must add
Use Android Kitchen to repack the image:
Bash:
cd .. # to move back to the folder where Android Kitchen is
./repacking.sh
You'll get a file called image-new.img. That's your new recovery with a working touchscreen!
I'm sure there's a better way to do this so feedback is welcome.
I tired your method and completed with a newimage file, and flastboot booted off it. Still had touch problems, files attached. Vendor.zip was placed in ramdisk\vendor\lib\modules. Any ideas?
Thankyou
PS (edit): would anything needed to be added to ramdisk/vendor/manifest.xml?
Lostwon said:
I tired your method and completed with a newimage file, and flastboot booted off it. Still had touch problems, files attached. Vendor.zip was placed in ramdisk\vendor\lib\modules. Any ideas?
Thankyou
Click to expand...
Click to collapse
Lostwon said:
I tired your method and completed with a newimage file, and flastboot booted off it. Still had touch problems, files attached. Vendor.zip was placed in ramdisk\vendor\lib\modules. Any ideas?
Thankyou
PS (edit): would anything needed to be added to ramdisk/vendor/manifest.xml?
Click to expand...
Click to collapse
PPS I am trying this on the Moto G stylus xt2043-4. I just noticed thats not the phone you wrote this for, Im going to pull and umpack my stock recovery and compre that to the Twrp3.4 image and see whats missing .

Categories

Resources