Related
I've created a small *nix shell script which tries to generate a nicely formatted list of changes between the /system portion of two firmwares. It also produces a 'diff' file containing the changes between text files it encounters.
It tries to present the information in a compact way, keeping the most pertinent information (like changes in build.prop/default.prop) on top. File changes are grouped together by directory, again keeping additions and deletions on top, followed by modifications.
You can see some example output in this thread
The script requires a few utilities to be available: grep, fmt, diff, filterdiff and interdiff.
grep and fmt are probably available on any *nix system, diff is part of the basic development package set.
filterdiff and interdiff are part of the 'patchutils' package in Debian and Ubuntu.
On Ubuntu you can install the dependencies with:
$ sudo apt-get install diffutils patchutils
To use the changelist script, simply run it with two directories into each of which you have extracted a factoryfs.rfs from the corresponding firmware, e.g.:
$ # Extract I9000XWJPI's factoryfs.rfs into I9000XWJPI/system
$ # Extract I9000XWJS3's factoryfs.rfs into I9000XWJS3/system
$ # then run
$ ./changelist I9000XWJPI I9000XWJS3
The script will produce two output files in the current directory, in this example they are:
I9000XWJPI-I9000XWJS3.txt (containing the formatted changelist)
I9000XWJPI-I9000XWJS3.diff (containing the textual changes in 'diff' format)
I hope you like it, please post any suggestions, bugfixes etc., in this thread.
Took me a few minutes to figure this out, so I thought to share
This is taken from some scripts I use in CF-Root, you might need to change it slightly for other CWM3 kernels (like prefixing busybox to various commands, etc).
updater-script
Assumptions:
- rootfs is mounted as rw, so we can write temporary files anywhere (ram disk)
- you put a "myscript.sh" in the system folder inside the update
All this script does is extract whatever you have in update.zip/system folder to /tmp/update, and run the myscript.sh file.
Code:
ui_print("Extracting files ...");
package_extract_dir("system", "/tmp/update");
set_perm(0, 0, 0755, "/tmp/update/myscript.sh");
run_program("/tmp/update/myscript.sh");
myscript.sh
Assumptions:
- all busybox commands are symlinked in /sbin, this is usually the case for CWM3 kernels
Code:
#!/sbin/busybox sh
# get file descriptor for output
OUTFD=$(ps | grep -v "grep" | grep -o -E "update_binary(.*)" | cut -d " " -f 3);
# same as progress command in updater-script, for example:
#
# progress 0.25 10
#
# will update the next 25% of the progress bar over a period of 10 seconds
progress() {
if [ $OUTFD != "" ]; then
echo "progress ${1} ${2} " 1>&$OUTFD;
fi;
}
# same as set_progress command in updater-script, for example:
#
# set_progress 0.25
#
# sets progress bar to 25%
set_progress() {
if [ $OUTFD != "" ]; then
echo "set_progress ${1} " 1>&$OUTFD;
fi;
}
# same as ui_print command in updater_script, for example:
#
# ui_print "hello world!"
#
# will output "hello world!" to recovery, while
#
# ui_print
#
# outputs an empty line
ui_print() {
if [ $OUTFD != "" ]; then
echo "ui_print ${1} " 1>&$OUTFD;
echo "ui_print " 1>&$OUTFD;
else
echo "${1}";
fi;
}
# --- example usage ---
# empty line after "Extracting ..." from updater-script
ui_print;
# give the user some status
ui_print "doing something (1 of 4)";
# assume this won't take more than 30 seconds
progress 0.25 30;
# you'd do something useful here
sleep 15s;
# update status
ui_print "- done with something (1 of 4)";
# we're done, make sure the progress bar is at 25%
set_progress 0.25;
# empty line
ui_print;
# repeat this a few times ;)
ui_print "doing something (2 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (2 of 4)";
set_progress 0.50;
ui_print;
ui_print "doing something (3 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (3 of 4)";
set_progress 0.75;
ui_print;
ui_print "doing something (4 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (4 of 4)";
set_progress 1.00;
ui_print;
# done !
ui_print "done! rebooting!";
How, what, why ?
While updater-script is fine for a lot of things, like installing a new ROM and whatnot, anything sufficiently complicated still has to be done through shell scripts, because a great many things just cannot be easily done in edify. It's nice to be able to give the user some status when doing these operations. There are modded versions of CWM that make the same thing possible in other ways, like simply writing to STDOUT or STDERR. This requires either a custom update_binary or recovery binary, though.
This works because communication between recovery and update_binary is through a file descriptor (pipe). Recovery runs update_binary with the FD as command line parameter. Because the shell script is run as a child process of update_binary, it can write the same commands to that FD (commands recovery listens for), because child processes inherited FD numbers and access rights.
So, all the script has to do is figure out which FD to write to, and pass it the right commands. Finding the FD isn't difficult, as it is passed on the command line and so is listed in the output of ps. Some grep and cut magic retrieve it. See the OUTFD=$(...) line. The right commands are defined in the functions at the top.
Note: this is all taken from my rfs<=>ext4 conversion script for CF-Root/ext4. Slightly adjusted, hopefully it still works as expected
Enjoy!
Thank you chainfire
Sent from my GT-I9000 using Tapatalk
Thanks for this chainfire.
Precisely what I was looking for! You're my hero today, man!
Hi Chainfire
Thanks for your tricks, I'm using it for an almost bulletproof MTD flash script.
BTW, i'd like to call some set_perm commands. But set_perm isn't a recognized command for update-binary.
IDK if I'm clear.
Do you have some advise on that?
RolluS said:
BTW, i'd like to call some set_perm commands. But set_perm isn't a recognized command for update-binary.
Click to expand...
Click to collapse
I've sort this writing equivalent functions:
Code:
set_perm() { # same as set_perm command in updater-script, for example:
#
# set_perm 0 3003 02750 "/system/bin/netcfg"
#
# sets user:group to 0:3003 and perm to 02750 for the file /system/bin/netcfg
$CHOWN $1:$2 $4
$CHMOD $3 $4
}
set_perm_recursive() { # same as set_perm command in updater-script, for example:
#
# set_perm_recursive 0 2000 0755 0755 "/system/bin"
#
# sets uid:gid to 0:2000 and perm to 0755 for folders and 0755 for files recursively in /system/bin
$CHOWN -R $1:$2 $5
$CHMOD $3 $5
#chmod recursive of folder
$FIND $5/* -type d |while read folder; do
$CHMOD $3 $folder
done
#chmod recursive of files
$FIND $5/* -type f |while read file; do
$CHMOD $4 $file
done
}
There is no error handling (yet), so be carrefull when calling these functions
no FD, no output
Chainfire said:
This works because communication between recovery and update_binary is through a file descriptor (pipe). Recovery runs update_binary with the FD as command line parameter. Because the shell script is run as a child process of update_binary, it can write the same commands to that FD (commands recovery listens for), because child processes inherited FD numbers and access rights.
So, all the script has to do is figure out which FD to write to, and pass it the right commands. Finding the FD isn't difficult, as it is passed on the command line and so is listed in the output of ps. Some grep and cut magic retrieve it. See the OUTFD=$(...) line.
Click to expand...
Click to collapse
finding the FD is difficult on an SGY phone under MT 2.0 kernel, because is is not passed as command line param and therefore not in the ps output.
can anyone give an example of a working FD ?
the expression returns "" on my SGY, and no output is readable from script.
above zip as one file with the (.*) business removed from FD expression in myscript.sh
I don't see that ps gives me a "FD" in its output. whatever that really is. /tmp/recovery.log says that /sbin/recovery has no command line params either on SGY
from recov.log:
I:Set boot command "boot-recovery"
Command: "/sbin/recovery"
there is no FD in the command line ! where is it then ?
I'll test this in a bit. Nice hack b/w.
any news?
Thanks for this trick. What I wanted to do is to redirect stdout (and stderr) of my script to the UI. I know that you can see this in "show logs", but I wanted it to display right during the installation. Here is what I came up with:
Code:
#!/sbin/busybox ash
OUTFD=$(ps | grep -v "grep" | grep -o -E "update_binary(.*)" | cut -d " " -f 3);
/sbin/busybox ash $* 2>&1 |
while read -r line
do
echo "ui_print $line" >&$OUTFD;
echo "ui_print " >&$OUTFD;
done
If you save this as "scripts/stdoutwrapper.sh", you can do something like this:
Code:
package_extract_dir("scripts", "/tmp/update");
set_perm(0, 0, 0755, "/tmp/update/stdoutwrapper.sh");
run_program("/tmp/update/stdoutwrapper.sh", "/tmp/update/myscript.sh", "param1", "param2");
In myscript.sh, use any shell commands. The output will be redirected to the UI. Therefore, you should be able to write scripts that work both on the command line and in recovery without changes.
Please note: As all output will be printed, the tricks with set_progress etc. don't work. It would probably be possible to use a prefix to identify commands that should be executed, not printed, so you could do e.g. "echo '<#>set_progress 0.25'".
what value does OUTFD have? find out like below:
adb shell
ps
then /sbin/recovery might have PID 2166 on SGY phone
su
ls -l --color=never /proc/2166/fd
may give you e.g.
3 -> /dev/tty0
so 3 is your OUTFD !
now grep it accordingly for the script. use MT kernel 2.0 on SGY for above capability
time saver
edify Scripts may be tested by executing update-binary directly:
update-binary version output package
An example would be:
update-binary 2 stdout /sdcard/update.zip
Just noticed Chainfire's ui_print shell script in the latest SuperSU zip, and that lead me here.
Here are some updated versions (for CWM6?); ui_print and set_perm from SuperSU and the other 2 from my tinkering today:
Code:
OUTFD=$2;
ZIP=$3
ui_print() {
echo -ne "ui_print $1\n" > /proc/self/fd/$OUTFD;
echo -ne "ui_print\n" > /proc/self/fd/$OUTFD;
}
set_perm() {
chown $1.$2 $4
chown $1:$2 $4
chmod $3 $4
}
show_progress() { echo "progress $1 $2" > /proc/self/fd/$OUTFD; }
set_progress() { echo "set_progress $1" > /proc/self/fd/$OUTFD; }
ex:
show_progress 1.34 0;
ui_print "Hello world!";
set_progress 0.5;
ui_print " "; #blank line
set_progress 1.34;
ui_print "Done!";
Also worth noting he just uses busybox unzip to extract files from the flashable zip directly and goes from there.
ex:
ui_print "Extracting files!"
cd /tmp
unzip -o "$ZIP"
mai77 said:
what value does OUTFD have?
Click to expand...
Click to collapse
I put ui_print "Test: $OUTFD" in a script and the value of OUTFD appears to increase with every zip flashed.
Not much use knowing it in that case.
Nice work, I used this in my little zip. However, it doesn't work with TWRP. Is there any way to accomplish that?
sorry to put this here but could anyone direct me towards the cwm or TWRP version for "jxjpb" (asia) baseband pls?
klenamenis said:
Nice work, I used this in my little zip. However, it doesn't work with TWRP. Is there any way to accomplish that?
Click to expand...
Click to collapse
TWRP names the extracted update-binary "updater", so you can add something like this (or modify the regex in the existing line):
Code:
[ $OUTFD != "" ] || OUTFD=$(ps | grep -v "grep" | grep -o -E "updater(.*)" | cut -d " " -f 3)
_that said:
TWRP names the extracted update-binary "updater", so you can add something like this (or modify the regex in the existing line):
Code:
[ $OUTFD != "" ] || OUTFD=$(ps | grep -v "grep" | grep -o -E "updater(.*)" | cut -d " " -f 3)
Click to expand...
Click to collapse
Shouldn't be necessary with any reasonably current recovery. That was just a hack Chainfire wrote to get the FD back in the CWM3 days.
All that should be required (and has always worked for me) is to make the update-binary your shell script, then:
Code:
OUTFD=$2;
See my other updated commands above. And some zips I've made which should provide good references for people: Nexus Louder, Xposed Framework Installer, and Nexus BootUnlocker. All available in my Odds and Ends thread, linked in my sig.
osm0sis said:
Shouldn't be necessary with any reasonably current recovery. That was just a hack Chainfire wrote to get the FD back in the CWM3 days.
All that should be required (and has always worked for me) is to make the update-binary your shell script, then:
Code:
OUTFD=$2;
Click to expand...
Click to collapse
Yes, that works if you replace the whole update-binary with a shell script, but this method is for scripts that are called from the updater-script when using a binary updater.
I've recently switched to a shell script as updater too, but I had to write my own zip signing program because busybox unzip was unable to extract files from a zip signed by SignApk.
osm0sis said:
See my other updated commands above. And some zips I've made which should provide good references for people: Nexus Louder, Xposed Framework Installer, and Nexus BootUnlocker. All available in my Odds and Ends thread, linked in my sig.
Click to expand...
Click to collapse
Wow, nice collection! I remember some other posts from you that were very helpful, thanks!
_that said:
Yes, that works if you replace the whole update-binary with a shell script, but this method is for scripts that are called from the updater-script when using a binary updater.
I've recently switched to a shell script as updater too, but I had to write my own zip signing program because busybox unzip was unable to extract files from a zip signed by SignApk.
Wow, nice collection! I remember some other posts from you that were very helpful, thanks!
Click to expand...
Click to collapse
Nice! My misunderstanding then.
And ah yes, the old "1 and 8" issue with unzip. Might be resolved in the latest busybox 1.22.1 but I'm not 100% about that, and it'll be awhile before that makes it into recoveries.
I'd love to get hold of your zip signer if that'd be okay. I have Chainfire's solution, but I was still running into some verification problems (I think) from the MinSignApk whole file resigning.
osm0sis said:
And ah yes, the old "1 and 8" issue with unzip. Might be resolved in the latest busybox 1.22.1 but I'm not 100% about that, and it'll be awhile before it makes it into recoveries.
Click to expand...
Click to collapse
Exactly! I learned a lot about the zip format while researching this.
osm0sis said:
I'd love to get hold of your zip signer if that'd be okay. I have Chainfire's solution, but I was still running into some verification problems (I think) from the MinSignApk whole file resigning.
Click to expand...
Click to collapse
Argh! I saw your original question in that thread but I never found the solution because there were so many pages in between...
I ended up with a hack that appears to resemble Chainfire's minsignapk, but I didn't need to write my own zipadjust. Basically I simply sign the zip normally with signapk, then I unpack and repack the whole archive using 7zip (bonus: slightly better compression), and then I run the whole-zip-signer on the archive.
Here is my SignWholeFile.jar - the source code is just too ugly to publish. View attachment SignWholeFile.jar If you find that it works better than Chainfire's version, I'll clean the source and release it.
This is the script I use for signing:
Code:
#!/bin/sh
KEYDIR=~/android/aosp/build/target/product/security
SIGNAPK=~/android/aosp/prebuilts/sdk/tools/lib/signapk.jar
SIGNWHOLEFILE=~/android/src/signapk/SignWholeFile.jar
java -jar $SIGNAPK -w $KEYDIR/testkey.x509.pem $KEYDIR/testkey.pk8 "$1" "$1.signed.zip"
mv "$1" "$1.unsigned"
signedzip=$(readlink -f "$1.signed.zip")
[ -d /tmp/signapk2 ] && rm -rf /tmp/signapk2
mkdir /tmp/signapk2
pushd /tmp/signapk2
unzip $signedzip
rm $signedzip
7z a -r -mx=9 $signedzip *
#7z a -r $signedzip *
popd
mv "$1.signed.zip" "$1"
java -jar $SIGNWHOLEFILE $KEYDIR/testkey.x509.pem $KEYDIR/testkey.pk8 "$1" "$1"
I was wondering if I could mount an empty.img file so that I could add executable into it and chmod 777 them or what ever the number is maybe 666.
Then I would add the location to my $PATH variable in the "/system/etc/mkshrc" file so I could execute those programs from any directory.
What say you?
Has this been done before?
It works!
Well, I wen ahead and tried it out, I figured "What the hell, its not like I have to format my sd card." It worked!
So what I did
1) I changed directories to Downloads. ("cd ~/Downloads")
2) I created a directory for my image in Downloads, and moved into it. (mkdir image && cd ./image)
3) I created an empty 4 gig image called apps.img using dd ("dd if=/dev/zero of=apps.img bs=1MB count=0 seek=4096")
4) I formated it to ext2 ("mke2fs -F apps.img")
5) I used adb to push it to my phone ("adb push ~/Downloads/image/apps.img /storage/sdcard0/Download/")
6) Then on my phone as su I mounted the image ("mount -o loop '/storage/sdcard0/Download/apps.img' '/data/local/mnt' ") {with single quotes around the directories, the double quotes wrap the whole actual command, you don't need them} [EDIT: I used bash on the phone to do this, ie I "su" [enter] ; "bash" [enter] ; "THE ABOVE COMMAND" [enter]
7) To test I used the python interpreter as my executable so I created a folder in /data/local/mnt called apps,(note* I should have made that folder on my pc before I pushed it to my phone to ensure that the foder was actually in the apps.img file.) I created two more folders "bin" and "lib" using "File Manager" on my phone. I then moved what I needed to run python into those folders (though you'll see I forgot something)
8) I added PYTHONHOME PYTHONPATH and added the bin folder I created to $PATH in the /system/etc/bash/bashrc file (Ask and I'll explain). If you don't have bash the mkshrc file is located "/system/etc/mkshrc" on your phone (if its Sprint SGSIII) adding environment variable there will accomplish the same thing, sorta.
9) I connected my phone to pc w/usb, opened up a teminal on pc, started an adb shell
10)........
Code:
[email protected]:~$ adb devices
List of devices attached
xxxxxxxx device
[email protected]:~$ adb shell
[email protected]:/ $ su
[email protected]:/ # bash
void endpwent()(3) is not implemented on Android
localhost / # which python
/data/local/mnt/apps/bin/python
localhost / # python
'import site' failed; use -v for traceback
Python 2.6.2 (r262:71600, Mar 20 2011, 16:54:21)
[GCC 4.4.3] on linux-armv7l
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import sys
>>> import math
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named math
>>> import io
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/io.py", line 63, in <module>
ImportError: No module named _fileio
>>>
localhost / # exit
[email protected]:/ # ^D
[email protected]:/ $ ^D
[email protected]:~$
I'm thinking that if I can get my mkbootimg tools to work, I would mod an init script to mount the apps.img and then create links for each file in say '/mnt/apps/bin' create a link*in '/system/bin'. this should allow for phones with small or near full system partition install stuff like busybox or your own pprograms. More usefull for a developer.
I wanna try this with pythonforandroid, if I can make python and its modules. accessible during early init or just before the boot process finishes in general, and use it to run python, maybe python can handle boot in a different way, or maybe just one specific. function you might needs.
one big question I have. Does the pythonforandroid interpreter run ontop of the D VM?
Edge-Case said:
I'm thinking that if I can get my mkbootimg tools to work, I would mod an init script to mount the apps.img and then create links for each file in say '/mnt/apps/bin' create a link*in '/system/bin'. this should allow for phones with small or near full system partition install stuff like busybox or your own pprograms. More usefull for a developer.
I wanna try this with pythonforandroid, if I can make python and its modules. accessible during early init or just before the boot process finishes in general, and use it to run python, maybe python can handle boot in a different way, or maybe just one specific. function you might needs.
one big question I have. Does the pythonforandroid interpreter run ontop of the D VM?
Click to expand...
Click to collapse
I don't think so. All command-line programs I know of interface directly with the kernel.
Sent from my S3 on Sense 5 (you jelly?)
CNexus said:
I don't think so. All command-line programs I know of interface directly with the kernel.
Sent from my S3 on Sense 5 (you jelly?)
Click to expand...
Click to collapse
So getting an extended set of Linux (kernel) cli programs working with Android (kernel) is a matter of having the nessissary libraries, kernel prereq., and being compiled for the target processor?
From what I have read, the Android kernel has been cut back so far from the original Linux kernel that its difficult to port "Linux apps" to Android. Something about a slimmed down version of the GNU C/C++ libraries and the Android kernel being designed to run mostly Dalvik.
I haven't tried directly running any "Linux app" (already compiled for arm) on Android yet, but my game plan for that test was to load up an .img file with the nessissary execs, libs, config, etc files (as ext3 this time) and running some scripts that get the paths variables set up and then execute the script, I wrote a short Bash script that sets up python variables and adds others to PATH etc, and it worked, I had python on the img and the img mounted to /mnt/myside and python ran but with some errors, I need to get the variables right, its driving me mad, if its not this its that, last time it was the basic "help()" command not being declaired or something.
Well thats my plan, either these "Linux apps" run on Android without problem or I am going to A) write my own kernel to be compatible with Android/ cli Linux or I am going to get as much source code as I can and practice the art of compiling against Android and/or patching the code when/where nessissary.
We'll see what happens, I've done enough today/night.
How to compile CyanogenMod 10.1 for your Samsung D2ATT
This post is a copy of the guide found at http://lindroidsoup.com/so-you-want-to-build-androidIt's a compilation of guides I've used along the way. It details the work-arounds I've used to get builds to complete, so I thought it would be nice to share. Special thank you to guys like DesignGears, pmos69, and Task650 for inspiring me to lean more about Android
Tired of flashing someone else’s ROM? Ready to make your own? Read on!
This tutorial will take you from scratch to ROM with a clean new build of CyanogenMod 10.1 that you can slap on your AT&T SGS III as a daily driver. Once you’ve got the concept down, you’ll be able to change it up and build for whatever you’d like. Let’s take a look at what we’ll need to get going:
_______________________________
PREREQUISITES
Anything less would be uncivilized
Broadband Internet Connection (No, this IS a must. Attempting to sync a repo with dial-up will make your brain explode. Really).
A rooted Samsung Galaxy SIII D2ATT with CyanogenMod 10.1 or newer already flashed on it.
A 64bit Ubuntu 12.04 or later based Linux OS installed on your PC, or in a VM with adequate resources (at least 2 cores and 2-4GB RAM). This guide was written on Kubuntu 13.04, but even Mint works- notes included below.
@50GB of disk space to be used for repo storage and building.
Free Time (@3-6hrs, depending on the chomping power of your PC and the speed of your broadband).
_______________________________
!!!!! DISCLAIMER !!!!!
This tutorial is posted as a guide for the adventurous who are eager to learn the basics of compiling a ROM. The procedures detailed here do have the ability to miff up your mobile device if something goes wrong. Since it has now been listed as a warning, you follow this guide at your own risk, and I take absolutely no responsibility for any consequences that result from any mishaps you may encounter.
Part 1 – Setting Up The Environment
1.1 – Install The Necessary Packages
Copy and paste everything after the prompt symbol (~$) in terminal. A new prompt means a new line:
Code:
~$ sudo apt-get install git-core gnupg flex bison python rar original-awk gawk p7zip-full gperf libsdl1.2-dev libesd0-dev libwxgtk2.8-dev squashfs-tools build-essential zip curl libncurses5-dev zlib1g-dev pngcrush schedtool
~$ sudo apt-get install libc6-dev x11proto-core-dev libx11-dev libgl1-mesa-dev mingw32 tofrodos python-markdown libxml2-utils
~$ sudo apt-get install g++-multilib lib32z1-dev ia32-libs lib32ncurses5-dev lib32readline-gplv2-dev gcc-multilib g++-multilib xsltproc
1.2 – Make Sure We Have The Right JAVA
If you try to compile with anything other than JDK 1.6, you’ll receive errors and fail to compile. If you try to download JDK 1.6 from the Oracle site, you’ll have a heck-of-a-time trying to find their archives. Luckily LindroidSoup.com just happens to have a copy of a JDK you can use…
http://lindroidsoup.com/Downloads/jdk-6u35-linux-x64.bin
Once you have the JDK downloaded, make sure you move it into your home directory. Then we’ll need to clear out any other versions of Java installed on the machine.
Code:
~$ sudo apt-get purge openjdk-\* icedtea-\* icedtea6-\*
Now we’re clear to install the correct JDK.
Code:
~$ sudo mkdir -p /opt/java/64 && sudo cp jdk-6u35-linux-x64.bin /opt/java/64
~$ sudo su -
~$ cd /opt/java/64 && chmod +x jdk-6u35-linux-x64.bin
~$ ./jdk-6u35-linux-x64.bin
~$ exit
Now we need to make our first PATH entry. Using your text editor of choice, (I use nano, some use vi, others use gedit…just pick one) we’ll need to add the following to our .bashrc file:
_________________________IMPORTANT NOTE FOR LINUX MINT USERSIf you’re using Linux Mint, you’ll need to make sure you’re editing the .bashrc file located at /etc/bash.bashrc
So if you see a reference to "~/.bashrc", you should replace it with "/etc/bash.bashrc"
Got it? Good.
_________________________
Code:
~$ sudo nano ~/.bashrc
Once the file is opened up, paste in the following at the end of the file, save, and close it.
Code:
#Java PATH
export JAVA_HOME=/opt/java/64/jdk1.6.0_35
export PATH=$PATH:$JAVA_HOME/bin
1.3 - Install The Android SDK
Now that we have our JAVA situated, it’s on to installing the Android SDK. Once again, LindroidSoup is your one-stop-shop- hit the link below for the 64bit Linux flavor of the SDK. Make sure to move it to your home directory once it’s downloaded.
http://lindroidsoup.com/Downloads/adt-bundle-linux-x86_64-20130917.zip
Let’s set up our SDK directory, and put the SDK in place.
Code:
~$ cd ~
~$ mkdir android && mkdir android/sdk
~$ sudo cp adt-bundle-linux-x86_64-20130917.zip android/sdk
~$ cd android/sdk && unzip adt-bundle-linux-x86_64-20130917.zip
~$ sudo rm -rf adt-bundle-linux-x86_64-20130917.zip && cd adt-bundle-linux-x86_64-20130917/sdk
~$ sudo cp -R platform-tools ../.. && sudo cp -R tools ../..
Now we’ll need to make sure the platform-tools and tools have the proper ownership, or the command “android” won’t work when we invoke it after adding the tools to our PATH.
You’ll need to know your username for this one- it’s pretty easy, but for those new to the scene your username is what you see listed before the “@” symbol in your prompt. For instance, my prompt shows
Code:
[email protected]:~$>
So my username is “christopher”. Now we can correct the ownership of the files, just replace each instance of username on both sides of the colons below with your username:
Code:
~$ cd ~/android/sdk
~$ sudo chown -R username:username platform-tools && sudo chown -R username:username tools
We can now add the Android SDK to our PATH, and we’ll also need to add an Extra PATH for our Device. Mint users, don’t forget to edit /etc/bash.bashrc, not ~/.bashrc.
Code:
~$ sudo nano ~/.bashrc
Once the file is opened up, paste in the following at the end of the file, save, and close it.
Code:
#Android PATH
export PATH=$PATH:~/android/sdk
export PATH=$PATH:~/android/sdk/platform-tools
export PATH=$PATH:~/android/sdk/tools
And the Extra PATH for our device. **NOTE** Mint users will edit the same file this time.
Code:
~$ sudo nano /etc/udev/rules.d/99-android.rules
Code:
#Samsung
SUBSYSTEM==usb, SYSFS{idVendor}==04e8, MODE=0666
SUBSYSTEM==”usb”, ATTRS{idVendor}==”####:####”, SYMLINK+=”android_adb”, MODE=”0666″ GROUP=”plugdev”
TEST==”/var/run/ConsoleKit/database”, \
RUN+=”udev-acl –action=$env{action} –device=$env{DEVNAME}”
Let’s make that file executable, shall we?
Code:
~$ sudo chmod +x /etc/udev/rules.d/99-android.rules
Ok, now we’ll need to close our terminal and open a new one to load all the changes we’ve made to this point.
Failure To Close And Open A New Terminal At This Point Will Cause The Android Command To Fail!
Oooh. That looked important. We should make sure we do that then. Close your terminal and open a new one.
Now to install the tools:
Code:
~$ android
The “android” command will open up the Android SDK Manager. Make sure that both the “Android SDK Tools” and “Android SDK Platform-Tools” show to be installed. If they don’t show to be, make sure you install them.
Part 2 – Gettin’ That Source Code
2.1 – Installing The Repository
Now comes the part where you’ll need to find something to do for awhile. A long while. We’re going to initialize the repository, and then start the sync process to pull in the majority of the Android Source code you’ll need to compile your ROM- but it’s several gigabytes of data and will take a fair amount of time to sync.
Code:
~$ mkdir -p ~/bin
~$ mkdir -p ~/android/system
~$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
~$ chmod a+x ~/bin/repo
And then we can make our PATH entry for the repository. Again- Mint users need to edit /etc/bash.bashrc.
Code:
~$ sudo nano ~/.bashrc
Once the file is opened up, paste in the following at the end of the file, save, and close it.
Code:
#Repo PATH
export PATH=$PATH:~/bin
We need to close our terminal again, and open another one to load our changes.
Failure To Close And Open A New Terminal At This Point Will Cause The Repo Sync Command To Fail!
Close your terminal and open a new one.
This next batch of commands will start the repo sync.
Helpful Tip
The repo sync command is used to update the latest source code from CyanogenMod and Google. Remember it, as you can do it every few days to keep your code base fresh and up-to-date. The CM manifests include a sensible default configuration for repo, which they strongly suggest you use (i.e., don’t add any options to sync). For reference, their current default values are -j4, and -c. The “-j4” part means that there will be four simultaneous threads/connections. If you experience problems syncing, you can lower this to -j3 or -j2. “-c” will ask repo to pull in only the current branch, instead of the entire CM history.
Code:
~$ cd ~/android/system
~$ repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1
~$ repo sync -j4
2.2 – Grab The Device Code
Now that we have the Android Source Code, we need to pull in the code specifically for the D2ATT. We’re going to be pulling specifically from CyanogenMod’s Github, so you’ll need to make sure git is configured correctly on your machine- if their github doesn’t know who you are, you get no git! Make sure to enter you own info when configuring git. (NOTE- Those are double dashes in front of "global". Not sure why, but universally text boxes don't seem to like them, and don't display them correctly)
Code:
~$ git config –global user.name (firstname.lastname)
~$ git config –global user.email ([email protected])
Just so no one is confused, it should read like the following:
Code:
~$ git config –global user.name john.doe
~$ git config –global user.email [email protected]
Now we can use git to pull in the device code:
Code:
~$ git clone https://github.com/CyanogenMod/android_device_samsung_d2att.git -b jellybean device/samsung/d2att
~$ git clone https://github.com/CyanogenMod/android_kernel_samsung_d2.git -b jellybean kernel/samsung/msm8960
Now we can get the prebuilts from CyanogenMod as well:
Code:
~$ cd ~/android/system/vendor/cm && ./get-prebuilts
2.3 - Breakfast
Now that we have all our device specific code from both the Android and CyanogenMod repo’s, we can setup our environment and make breakfast.
Code:
~$ cd ~/android/system
~$ source build/envsetup.sh
~$ breakfast d2att
2.4 - Extracting The Blobs
The manufacturer “blobs” are kind of like a PC’s device drivers. You have to have the specific ones for the phone’s hardware, or your ROM probably won’t do important stuff- like showing anything on the display… Let’s go get them.
Now, we have two separate ways of going about this:
Option 1 –
Connect your phone to your pc via usb. You’ll need to make sure you have “UserDebug” mode enabled, as well as “Root Access for Apps and ADB” under the Developer Options of the phone.
Code:
~$ cd ~/android/system/device/samsung/d2att
~$ ./extract-files.sh
Option 2 –
Extract them from an existing CyanogenMod ROM. You’ll need to make sure you have a current copy of a CyanogenMod Nightly ROM downloaded and extracted, and you’ll need to know the path to it.
CyanogenMod Nightlies can be found here: http://download.cyanogenmod.org/?type=nightly&device=d2att
Code:
~$ cd ~/android/system/device/samsung/d2att
~$ ./extract-files.sh path/to/your/extracted/ROM
Just so everyone is clear, if I extracted my nightly ROM inside my Downloads folder- my command for Option 2 would look like this:
Code:
~$ ./extract-files.sh /home/christopher/Downloads
Wow, this is exciting. We’re almost ready to build, but first we make our last PATH entry- adding our toolchain. This step is important, because it’s the only PATH entry that has your username in it. You remember getting your username earlier, don’t you? Good!
Mint users, same old song and dance- make sure you’re editing the .bashrc file at /etc/bash.bashrc.
Code:
~$ sudo nano ~/.bashrc
Once the file is opened up, paste in the following at the end of the file, save, and close it:
Code:
#Android Toolchain PATH
export ARCH=arm
export CCOMPILE=$CROSS_COMPILE
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:/home/(YOUR-USERNAME-HERE)/android/system/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
Save that file, close it, and then close and open a new terminal to load our changes. For the last time.
Failure To Close And Open A New Terminal At This Point Will Cause The Brunch Command To Fail!
Close your terminal and open a new one.
Part 3 – BUILD ANDROID
Fire up that terminal one more time:
Code:
~$ cd ~/android/system
~$ . build/envsetup.sh && brunch d2att
And watch it go. Go grab yourself a stimulating beverage- this is gonna take awhile.
Once everything wraps up, you should see a nice neat “Package Complete” message in your terminal window. Congratulations! Now go flash it- you know you wanna!
Don’t forget to grab the latest version of GAPPS if you want your Google Apps!
BONUS SECTION!!!
Q.- What the hell do I do if the build breaks!?!?
A.- This is a very valid question, although if you followed the guide you shouldn’t run into any issues- but these things happen. Google is your friend when all else fails, but here are some common occurences:
Code:
ERROR: signapk.jar failed: return code 1make: *** [out/target/product/d2att/cm_d2att-ota-eng.root.zip] Error 1
Change the following in your system/build/tools/releasetools/common.py file:
Change: “java -Xmx2048m” to “java -Xmx1024m” or “java -Xmx512m”
If you see a message about things suddenly being “killed” for no reason, your (virtual) machine may have run out of memory or storage space. Assign it more resources and try again.
DOUBLE BONUS SECTION!!!
How do I make an update?
So glad you asked. So glad I saw that I left this out initially, and now I’m putting it in here…
To the terminal we go:
Code:
~$ cd ~/android/system
~$ repo sync -j4
~$ make installclean
~$ find ./out/ -name 'build.prop' | xargs rm
~$ find ./out/ -name 'cm_d2att-target_files-eng.*.zip' | xargs rm
~$ . build/envsetup.sh && brunch d2att
Just flash that update right on top of your already flashed build, and it will update it.
Again, Google is your friend.
Cheers
Automated ROM update script!!!
Want to make updating your ROM super easy? Not a problem! Download the following 'buildromupdate.sh' script from Lindroidsoup.com, or simply use a text editor to copy and paste the following! Don't forget to 'chmod +x' and make it executable- then just run it from the command line with ~$ ./buildromupdate.sh -It doesn't get much easier!
Code:
#!/bin/bash
# This script will clear out old files, and update your ROM
# Flash this updated .zip on top of your existing ROM
# You should see 'Android is updating' on next boot
cd ~/android/system
repo sync -j4
make installclean
find ./out/ -name 'build.prop' | xargs rm
find ./out/ -name 'cm_d2att-target_files-eng.*.zip' | xargs rm
. build/envsetup.sh && brunch d2att
Download the script: http://lindroidsoup.com/Downloads/buildromupdate.sh
Cheers!
I have moved your thread to general, as typically users will find guides here. I am sorry for any inconvenience.
Lindroidsoup.com will be down for maintenance on 10/16/2013
LindroidSoup.com will be down for maintenance on 10/16 - 10/19
We apologize for any inconvenience this may cause, and are providing the direct links for both the Android SDK and Java JDK below:
Java JDK 1.6.35- http://download.oracle.com/otn/java/jdk/6u35-b10/jdk-6u35-linux-x64.bin
Android SDK- http://developer.android.com/sdk/index.html#linux-bundle
The server will be up and operational again on 10/19/2013.
Lindroidsoup.com completed maintenance ahead of schedule
LindroidSoup.com is back online!
We're pleased to announce that the wonderful team at KnownHost, LLC was able to finish site/server maintenance well ahead of schedule, and we're now back online!
Linux Mint Users Note
If you're a Linux Mint user, just a handy little note-
Mint is notorious for over-writing /etc/bash.bashrc when major system updates are pushed out. This becomes a pain in the ass when your PATHs keep getting over-written and you receive errors when trying to build an update after you've set everything up.
To work around it, just make a copy of your /etc/bash.bashrc file- and then put it back in place if you see the original's been over-written:
To make a backup of /etc/bash.bashrc after initial setup
Code:
~$ sudo cp /etc/bash.bashrc /home/bash.bashrc.backup
To replace an over-written /etc/bash.bashrc after a system update
Code:
~$ sudo rm -rf /etc/bash.bashrc && cp /home/bash.bashrc.backup /etc/bash.bashrc
That should keep you from pulling your hair out!
Cheers
Damn it, Google!!!
Google changed the storage location of their repo code, so trying to download it was causing a '/bin/repo: line 1: syntax error near unexpected token `newline'' error.
I've adjusted the guide to reflect the new storage location for the curl command.
Sorry if this caused anybody any headaches.
Regards,
C
Any guide for Windows? If not is it cool to develop via a VMware image of Linux?
drivel2787 said:
Any guide for Windows? If not is it cool to develop via a VMware image of Linux?
Click to expand...
Click to collapse
Yes, using a vm is fine
Slithering from the nether regions of a twisted mind and tarnished soul
Hello, I am on ubuntu 14.4 and I am trying to build CM-12. When the rom is building, it keep stoppinig at the following error;
target R.java/Manifest.java: com.android.emailcommon (/home/larmyv/android/system/out/target/common/obj/JAVA_LIBRARIES/com.android.emailcommon_intermediates/src/R.stamp)
/home/larmyv/android/system/out/host/linux-x86/bin/aapt: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
make: *** [/home/larmyv/android/system/out/target/common/obj/JAVA_LIBRARIES/com.android.emailcommon_intermediates/src/R.stamp] Error 127
make: *** Waiting for unfinished jobs....
Any Ideas? Any help would be greatly appreciated.
Thanks
LARMYV said:
Hello, I am on ubuntu 14.4 and I am trying to build CM-12. When the rom is building, it keep stoppinig at the following error;
target R.java/Manifest.java: com.android.emailcommon (/home/larmyv/android/system/out/target/common/obj/JAVA_LIBRARIES/com.android.emailcommon_intermediates/src/R.stamp)
/home/larmyv/android/system/out/host/linux-x86/bin/aapt: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
make: *** [/home/larmyv/android/system/out/target/common/obj/JAVA_LIBRARIES/com.android.emailcommon_intermediates/src/R.stamp] Error 127
make: *** Waiting for unfinished jobs....
Any Ideas? Any help would be greatly appreciated.
Thanks
Click to expand...
Click to collapse
Sounds like you're running into this: http://ideid.blogspot.co.uk/2013/01/resolve-shared-library-problem-with.html
Give it a shot, and let me know what you get.
samoled said:
Sounds like you're running into this: http://ideid.blogspot.co.uk/2013/01/resolve-shared-library-problem-with.html
Give it a shot, and let me know what you get.
Click to expand...
Click to collapse
Thank you so much, i was looking for days on the error. When I put in the following command;
sudo apt-get install ia32-libs
it gave me an error that said that it was no longer available. It said to download the following;
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
I downloaded those packages and i am now in business and have finally built a rom. Now I am learning on the whole cherry picking.
Thanks again.
Awesome, glad to hear you got that sorted out.
Let me know if you run into anything else.
samoled said:
Awesome, glad to hear you got that sorted out.
Let me know if you run into anything else.
Click to expand...
Click to collapse
Hi, I have a new question for you. I am currently building slim roms and I have an issue with the kernel. The phone will boot up but would be stuck on the samsung logo screen. My question to you is how do I port over the CM12 kernel and merge it with the slim rom?
Has anyone installed self signed ROMs using the method described in this blog http://mjg59.dreamwidth.org/31765.html? The goal is to install a self signed image that allows you to only install images signed by a key you generate yourself to avoid the giant security hole caused by custom recoveries that don't check signatures.
Here's the overview :
First: Unlock your bootloader. /data will be wiped.
Second: Get a copy of the stock recovery.img for your device.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Fourth: Generate some keys. Get this script and run it.
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Eighth: Write the new recovery image to your device
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Tenth: Relock your bootloader
Eleventh: Boot into recovery mode and sideload your newly signed image.
Click to expand...
Click to collapse
I have the 8" Tab (SM-T310) and want to try it. Anyone know if there's an official source of stock recovery images? I have the 4.4.2 update.zip from an OTA update I never installed (my tablet's still on stock 4.2.2), can the recovery somehow be extracted from that? Since I'm still on 4.2.2, I don't need to unlock the bootloader, right? Can I use Heimdall to put the new recovery on the tab?
Here's my step by step if anyone else is crazy enough to try this.
First: Unlock your bootloader. /data will be wiped.
Click to expand...
Click to collapse
Skipped so far, running 4.2.2 which from what I've been reading I think isn't locked.
Second: Get a copy of the stock recovery.img for your device.
Click to expand...
Click to collapse
Grabbed the update from Kies (on Windows VM):
Agreed to Kies update when I plugged in the tablet.
Watched my temp folder (from windows search bar enter %temp%) until tmp*.tmp.zipfolder showed up (wait for tmp*.tmp file to download and get converted to a zip, then it unzips into zipfolder automatically), unplugged the tablet immediately as it booted into download mode, copied tmp*.tmp.zipfolder somewhere else (desktop) before Kies cancelled the update process and deleted the temp files.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Click to expand...
Click to collapse
Source is on github: osm0sis/mkbootimg From here on I'm using linux.
cd into mkbootimg folder and run "make"
run
Code:
./unpackbootimg -i recovery.img -o rec
(rec is the folder I unpacked to, make the folder first or it'll segfault)
Fourth: Generate some keys. Get this script and run it.
Click to expand...
Click to collapse
Saved script (posted below, can't post links yet...) to "make_key.sh", then
Code:
chmod +x make_key.sh
to make it executable.
Ran script, usage: /make_key.sh <name> <subject> [<keytype>]
subject must be in the format "/C=GB/ST=London/L=London/O=Global Security/OU=IT Department/CN=example.com" (look up "Create CSR using OpenSSL Without Prompt (Non-Interactive)" for what all that means)
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Click to expand...
Click to collapse
Make a directory, cd into it, run
Code:
zcat recovery.img-ramdisk.gz | cpio -id
with recovery.img-ramdisk.gz pointing to where your file is (mine was ../recovery.img-ramdisk.gz).
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Click to expand...
Click to collapse
Not sure why he's using a different DumpPublicKey.java than the one that's in the mkbootimg git... but it's in the "libmincrypt/tools/DumpPublicKey.java" that was in the mkbootimg git, I didn't see any differences using diff.
Running
Code:
javac DumpPublicKey.java
tells me I need BouncyCastleProvider. And now I'm stuck.
Downloaded the Bouncy Castle jar and put it in the same folder as DumpPublicKey.java and ran
Code:
javac -cp bcprov-jdk15on-152.jar DumpPublicKey.java
echo "Main-Class: DumpPublicKey" > manifest.txt
jar cvfm DumpPublicKey.jar manifest.txt DumpPublicKey.java
Then running
Code:
java com.android.dumpkey.DumpPublicKey
gave me various class not found errors and I ended up with a file structure like this trying to make it find the bouncy castle. Annnnnd I'm stuck.
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│**** └── dumpkey
│****** ├── bcprov-jdk15on-152.jar
│****** ├── DumpPublicKey.class
│****** ├── DumpPublicKey.jar
│****** ├── DumpPublicKey.java
│****** └── manifest.txt
├── DumpPublicKey.class
├── DumpPublicKey.java
└── manifest.txt
I obviously don't know how to java at all.... any suggestions?
I just needed to put the "-cp" in the java command as well as the javac command.
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey
The full command is
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey /path/to/key.x509.pem > keys
After deleting stuff and testing, I found I only needed files in these locations:
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│** └── dumpkey
│** ├── DumpPublicKey.class
│** └── DumpPublicKey.jar
├── DumpPublicKey.java
└── manifest.txt
Then I replaced the "/res/keys" file with the "keys" file I just made.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Click to expand...
Click to collapse
From the folder that the ramdisk image was extracted into, run
Code:
find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz
mkbootimg needs offsets that were printed when I ran unpackbootimg:
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE 10000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_TAGS_OFFSET 00000100
Still in the folder where I unpacked the recovery image (mkbootimg is one directory up)
Code:
../mkbootimg --kernel recovery.img-zImage --ramdisk recovery.img-ramdisk.gz --base 10000000 --pagesize 2048 --kernel_offset 00008000 --ramdisk_offset 01000000 --tags_offset 00000100 -o newrecovery.img
Eighth: Write the new recovery image to your device
Click to expand...
Click to collapse
This thread says Heimdall 1.4.0 works for T31x: http://forum.xda-developers.com/showthread.php?t=2522091
Oh how nice, Heimdall 1.4.1 is in my package manager.
Connect device and restart in download mode (held the "HOME" button, "Volume Down" and "Power" all at the same time (for about 5 seconds). Hit the "Volume Up" to enter download mode when prompted.)
Code:
sudo heimdall flash --verbose --no-reboot --RECOVERY recovery.img
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Click to expand...
Click to collapse
signapk is on github in android/platform_build/tools. And it gives more bouncy castle errors. Put bcpkix-jdk15on-152.jar and bcprov-jdk15on-152.jar in the signapk folder and run
Code:
javac -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar SignApk.java
echo "Main-Class: SignApk" > manifest.txt
jar cvfm SignApk.jar manifest.txt SignApk.java
make directory com/android/signapk/ and move in all the *.class files and the SignApk.jar
Code:
java -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar com.android.signapk.SignApk /path/to/key.x509.pem /path/to/key.pk8 ../original.zip ../signed.zip
I just replaced the recovery in the OTA with the recovery with my keys from earlier, then rezipped it before signing. And after starting sideloading I noticed I left the "-w" option off the signing command, so I made another file with "-w".
Sideloaded with:
Code:
adb reboot recovery
(then volume down to select apply update from ADB)
adb sideload signed.zip
Then saw:
loading: 'update.zip'
sending: 'update.zip' <completion percent>
(might have to do some adb stopping/starting or adb usb beforehand to make it work, I was getting "error: closed" at first. If it just sits on "loading" something's wrong, as I found out last night when I waited hours for "loading" to turn into something else.)
After the file finished uploading, In terminal I got the response "* failed to write data 'protocol fault (couldn't read status): Success' *"
And on the device I got (for a few seconds before it showed only the sad robot on its back). Then after a couple minutes it rebooted back into recovery.
E: Footer is wrong
E: Footer is wrong
E: Signature verification failed
Installation aborted
So I tried again, but this time selected the option to wipe the cache before adb sideload. Then I tried again, using the update.zip that I forgot to add the "-w" option when signing. So far all fails.
I have no idea if the issue is how the recovery was flashed or what, so I'm doing it manual...
Code:
adb shell
su
#first backup current recovery
dd if=/dev/block/mmcblk0p10 of=/sdcard/recoverybk.img
adb pull /sdcard/recoverybk.img
# now push and dd my signed recovery
adb push /sdcard/recovery.img
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p10
And still having the same signature verification issue.
Edit: I went back and unpacked the recovery I pulled off the device (unpackbootimg), and it looks like somehow I managed to run mkbootimg with the old ramdisk image.
New problem with the new recovery: "E:failed to load keys". Maybe it had something to do with using ec keys just for funsies. So I remade the keys with the default, redumped into the ramdisk image, rebuild/reflashed recovery, resigned the update.zip. Now it's back to the "footer is wrong, signature verification failed" error.
But this is still trying to use the OTA 4.4.something update, not a full ROM. What's it do with Cyanogen?
First attempt: Download Cyanogen and sideload it (unmodified)
E:failed to verify whole-file signature
E:signature verification failed
Ok, expected behavior, it's not signed with my keys.
Attempt 2: sign Cyanogen with my keys and sideload it
Install from ADB complete!! Success!!
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
moonbutt74 said:
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
Click to expand...
Click to collapse
Hmmm... that's a good idea.