I'm seeing more people using CM11 and figured we should have a place to discuss our experience and provide feedback if the device maintainer stops by.
I've been running CM11 since the end of December and have had a great experience with it. The only issues I've had are occasional trouble connecting to saved WiFi networks (that could definitely be the router) and Google Wallet won't allow tap and pay (I'm talking to a Google rep to resolve this)
Anyone else feel free to share your experience.
I'm on CM11 SNAPSHOT-M2
wmuflyer said:
I'm seeing more people using CM11 and figured we should have a place to discuss our experience and provide feedback if the device maintainer stops by.
Click to expand...
Click to collapse
Thanks I think sometimes people are afraid to open new threads and things get awfully confused.
i finally got it loaded 2 days ago and it seemed very polished
i just loaded the 1/17 nightly i have seen very few problems on 1/16. a few forecloses on the camera
no wifi issues no normal call issues. haven't tried speaker phone or headset on 1/15 i had a few freezes but nothing reproducible.
makes my obsolete phone feel like new.
my plan is to keep loading nightly's for a couple of days and note bugs. i would be happy to see if old bugs still exist if people will tell me what to look for. should I report bugs here?
I've been flashing the latest nightly every day. The last time I had an issue was a few weeks ago. I had some random reboots, then. I'm really please CM11 and very grateful CM is still putting out official builds for the phone.
One of the most fluid ROM's I used.
Considering Verizon never put out any code for KitKat use on fireball, I'm very shocked to see how flawless it works! Feels like a stock ROM!
I am having spontaneous reboots with this mornings nightly. Went back to yesterdays.
tj13 said:
I am having spontaneous reboots with this mornings nightly. Went back to yesterdays.
Click to expand...
Click to collapse
I had a couple reboots using today's nightly also (11-20140118). In my case i think it was related to an "Auto Turn Off" feature used by my battery manager. Since I've disabled it I haven't had any reboot issues. Total time on today's nightly ~6 hours, time since last reboot ~4 hours.
I've been running today's nightly, no crashes. Yesterday's crashed when receiving phone calls.
Sent from my Nexus 7 using XDA Premium 4 mobile app
tj13 said:
I've been running today's nightly, no crashes. Yesterday's crashed when receiving phone calls.
Sent from my Nexus 7 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
lots of reboots n the 1/19 nghtly (3 or 4)
1/20 seems better fixed something in the framework / base according to the change log.
nightly 21 and 22 seem to work well
i tried to enable art. no joy
first try gapps kept crashing. so i switched to the paranoid android gapps package (its much more inclusive but its also odexed and art compatible
it worked BUT i didn't see a 10 -20% increase in space required. i saw much more AND my dalvik cache was still in place. deleted it
dalvik was recrated on boot. so i have no idea what is going on. I had almost no space left over. so I restored my nandroid
new firmware
apparently is it recommended that we apply the firmware does any one know how to do this.
or rather which parts of the ota we need to fast boot flash.
here is the ota
https://dl.dropboxusercontent.com/u/5271399/OTAPkg.zip
and here is the update script. i think its the last part we care about.
Code:
# Script Version: I4.4
mount("ext4", "EMMC", "system", "/system");
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "verizon_wwe/fireball/fireball:4.0.4/IMM76D/111397.2:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "verizon_wwe/fireball/fireball:4.0.4/IMM76D/278117.2:user/release-keys");
ifelse( is_ship_bootloader(getprop("ro.bootloader")) == "t" ,
assert(check_cid(getprop("ro.cid"), "00000000" , "11111111" ,
"22222222" , "33333333" , "44444444" , "55555555" , "66666666" ,
"77777777" , "88888888" , "99999999" , "VZW__001") == "t");
);
ifelse( is_ship_bootloader(getprop("ro.bootloader")) == "t" ,
assert(check_mid("full", "PJ5310000") == "t");,
assert(check_mid("simple", "PJ5310000") == "t");
);
assert(getprop("ro.product.device") == "fireball" ||
getprop("ro.build.product") == "fireball");
ui_print("Copying fotaBoot to /data/system for customize reload...");
mount("ext4", "EMMC", "userdata", "/data");
package_extract_file("fotaBoot", "/data/system/fotaBoot");
ui_print("Verifying current system...");
show_progress(0.100000, 0);
bunch of asserts[
Code:
# ---- start making changes here ----
mount("ext4", "EMMC", "userdata", "/data");
delete("/data/data/recovery/radio_checksum");
delete_recursive("/data/data/com.htc.flashliteplugin/lib/",
"/data/data/com.htc.picasa/");
ui_print("Removing unneeded files...");
delete a bunch of stuff
Code:
ui_print("Patching system files...");
apply_patch("/system/app/Aluminum.apk", "-",
d917cdbdf6192a6fe765f90ce2198b877839339e, 3272076,
272abf53ad830bb0b199536447112ead05d7045f, package_extract_file("patch/system/app/Aluminum.apk.p"));
set_progress(0.009242);
apply more patches
Code:
ui_print("Unpacking new files...");
package_extract_dir("system", "/system");
ui_print("Symlinks and permissions...");
retouch_binaries
set a bunch of permissions
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
ui_print("Patching remaining system files...");
apply_patch("/system/build.prop", "-",
496d118a1d81e1cc4ef162efb6e09c6713a79b87, 8735,
91a2a064a29db812f31f49911c82219cec99e9b0, package_extract_file("patch/system/build.prop.p"));
set_perm(0, 0, 0644, "/system/build.prop");
ui_print("Preparing skin_fota tool...");
package_extract_file("skin_fota", "/tmp/skin_fota");
set_perm(0, 0, 06755, "/tmp/skin_fota");
show_progress(0.100000, 10);
ui_print("Running skin_fota tool...");
run_program("/tmp/skin_fota");
write_firmware_image("PACKAGE:firmware.zip", "zip");
unmount("/data");
unmount("/system");
the following files are in the firmware.zip ( i had to change the extension to 7z to open ie
presumable if we are on cm11 we don't want the boot or the recovery
Code:
android-info.txt
boot.img
radio.img
rcdata.img
recovery.img
rfg_1.img
rfg_2.img
rpm.img
sbl1-1.img
sbl1-2.img
sbl1-3.img
sbl2.img
sbl3.img
tz.img
dcooterfrog said:
the following files are in the firmware.zip ( i had to change the extension to 7z to open ie
presumable if we are on cm11 we don't want the boot or the recovery
Click to expand...
Click to collapse
Probably just radio.img which is often referred to as firmware.
Sent from my HTC6435LVW using Tapatalk
durgis said:
Probably just radio.img which is often referred to as firmware.
Sent from my HTC6435LVW using Tapatalk
Click to expand...
Click to collapse
i have seen some stuff on google saying the rcdata.img is also important. that's where my concern comes
I love CM11, and once I got it to work with Pageplus it was awesome. Unfortunately, now I'm switching to t-mobile, and I wanted to keep my phone and have 3g (3g is impossible on t-mobile with stock) but CM11 appears to be unable to use the t-mobile sim card. It keeps trying to use the old Pageplus number, MIN, and PRL stuff instead of using the sim card. This may be enough to finally drive me to sell my inc4g and get something more suited to t-mobile
no nightly today 1/28
I just flashed CM11 for the first time on the new 1/27 build. I have only encountered a couple issues that have been killing me, it is a good possibility that these issues are on my end and not the ROM.
1) Anytime I am on the phone, the screen goes completely black until the phone call has ended. Head phones so far has been the only solution to this for me.
2) I cannot get WiFi to connect to save my life.
I had both of these issues in previous CM10.2 builds, so I am starting to think that it is CM just not getting along with my phone. Any help or suggestions would be much appreciated.
Thanks in advance
TheGOAT232412 said:
1) Anytime I am on the phone, the screen goes completely black until the phone call has ended. Head phones so far has been the only solution to this for me.
Click to expand...
Click to collapse
There were other reports of this, I believe there was an app to calibrate the face sensor. A search through the 10.2 and/or 11 threads should give a solution.
Sent from my HTC6435LVW using Tapatalk
Thanks, the screen is a minor issue compared to the WiFi. Thanks for the info and feedback, much appreciated
Sent from my ASUS Transformer Pad TF300T using Tapatalk
TheGOAT232412 said:
I just flashed CM11 for the first time on the new 1/27 build. I have only encountered a couple issues that have been killing me, it is a good possibility that these issues are on my end and not the ROM.
1) Anytime I am on the phone, the screen goes completely black until the phone call has ended. Head phones so far has been the only solution to this for me.
2) I cannot get WiFi to connect to save my life.
I had both of these issues in previous CM10.2 builds, so I am starting to think that it is CM just not getting along with my phone. Any help or suggestions would be much appreciated.
Thanks in advance
Click to expand...
Click to collapse
Actually I believe the screen going blank is normal. It's to prevent ears from selecting things on the screen. Stock phones do it to.
Wifi should work. I ran the 1/27 for two days with no wifi problems. I moved on the 1/29 this morning.
TheGOAT232412 said:
Thanks, the screen is a minor issue compared to the WiFi. Thanks for the info and feedback, much appreciated
Click to expand...
Click to collapse
My wife has issues as well at home with our att two wire router. There must be something up, but I haven't been able to figure it out.
Sent from my HTC6435LVW using Tapatalk
Related
When scripting a ROM is there a way to verify the a certain version of recovery is installed before flashing?
Thanks!
Hmm, that is a good question. I don't think it can and even if it could, with the limitations in the edify scripting, it would be very hard to. For example, on the EVO 4G, I wanted to make it check what device you were running and what kernel you were using but it was such a PITA to even attempt that I just gave up. What made it even harder was that recovery uses it's own kernel, so trying to find out info from the kernel you were running was impossible.
That would be cool, some form of a incompatibility check.
Does getprop return anything while in recovery?
Must be possibly if ROM Manager can do it.
Edit: NM, sorry, I didn't properly read the OP.
Sent from my PG86100 using XDA Premium App
myn said:
Does getprop return anything while in recovery?
Click to expand...
Click to collapse
Not sure?
-viperboy- said:
Hmm, that is a good question. I don't think it can and even if it could, with the limitations in the edify scripting, it would be very hard to. For example, on the EVO 4G, I wanted to make it check what device you were running and what kernel you were using but it was such a PITA to even attempt that I just gave up. What made it even harder was that recovery uses it's own kernel, so trying to find out info from the kernel you were running was impossible.
Click to expand...
Click to collapse
Thats sorta what I am trying to do! At least I am not alone in this quest.
scrosler said:
When scripting a ROM is there a way to verify the a certain version of recovery is installed before flashing?
Thanks!
Click to expand...
Click to collapse
i don't think there is a definite guaranteed method .. although maybe somebody will prove me wrong as i might be thinking through it too much.
i dont have adb access to verify anything yet, but here is my line of thought.
the recovery binary, generally stored in /sbin/recovery won't really have a stamped version number on it, although you might be able to strings the binary for a version number, which could be executed by a .sh script called by the updater-script and if the script fails, you can stop the update and print an error message.
another thought, the kernel the recovery binary is housed in that is flashed/stored on the recovery partition won't really give much indication as the kernel will probably always be the same kernel version (2.6.35 or whatever is easiest to build for device support), but its compile number might increase, assuming they didn't just merge a new /sbin/recovery binary into the ramdisk and merge with an existing zImage (which could happen).
I've seen manufacturer OTA updater-script files and even cm7 verify device product.model using assert and getprop to confirm the correct .zip is being applied to the correct device before allowing the ROM to be flashed. any official OTA should have this assert getprop command at the top as well as any cm7 .zip.
unfortunately none of those methods or approaches will tell you which version of recovery is being used as twrp, amon and koush all use arbitrary (only really internally significant) version numbers for their recoveries.
on a more positive note, it is possible to test for some types of support in a recovery before allowing an updater-script .zip file to be loaded.
in an effort to better understand and perhaps take an alternate route to provide a solution, what are you trying to accomplish, i.e. what type of support are you requiring from the recovery?
myn said:
Does getprop return anything while in recovery?
Click to expand...
Click to collapse
it should but i can't prove it w/o adb access. i'm pretty positive manf OTA .zip files and cm7 .zip use assert(getprop(ro.product.model="supersonic")) etc to check before they allow the .zip to load .. but i'm thinking ro.product.model should be pulled from /system/build.prop which might/might not be mounted in recovery mode when the .zip is being loaded or stored else where when the updater-script is being executed?
should be easy enough to test with adb access to recovery ....
EDIT: adb access now:
cwm recovery on evo 3d, getprop is not setup in the shell and does not work.
taken from the NS4G OTA released a week or so ago:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.4/GRJ22/121341:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.5/GRJ90/138666:user/release-keys");
assert(getprop("ro.product.device") == "crespo4g" ||
getprop("ro.build.product") == "crespo4g");
if the call to file_getprop mounts /system, then the second call to getprop should read from the same /system/build.prop. otherwise the stock recovery would have to support the getprop command, which i doubt as the first command differs from the 2nd.
hope that makes sense. looks like assert(file_getprop( is your best bet .. and that doesn't verify recovery version. if you can provide more information around what you're wanting to do, perhaps there is another way to approach.
hope that helps!
Interesting...
How about just asking if that is possible in scripting. If twrp then else...., just an idea or if recovery is at a fixed location...read binary to see a signature? Check the md5 and see what it belongs to? You bad boy is my daily driver!
life64x said:
How about just asking if that is possible in scripting. If twrp then else...., just an idea or if recovery is at a fixed location...read binary to see a signature? Check the md5 and see what it belongs to? You bad boy is my daily driver!
Click to expand...
Click to collapse
I don't know if you've ever looked at an updater-script but it's not like standard scripting. I guess you might be able to extract a shell script and run it to check for some identifying information in recovery and have it report back the results in a ui_print but it would be a pain in the balls IF you could get it to work.
-viperboy- said:
extract a shell script and run it to check for some identifying information in recovery and have it report back the results in a ui_print but it would be a pain in the balls IF you could get it to work.
Click to expand...
Click to collapse
the part that would be a pain, as viperboy eludes to, is creating an index of the recovery versions, example:
md5sum: 029jlaksdfl232l34jklas = twrp recovery 1.0.0
md5sum: 0djlsdkj23lkj423lkjasdfl = twrp recovery 1.0.1
md5sum: lksd0923jlszdf092034 = twrp recovery 1.0.2
and doing that for each version of the recovery being released in addition to also indexing cwm recovery. sure, its doable ... is it practical?
the list would need to be updated with each new version of a recovery that is released, otherwise an installing ROM wouldn't know which version a new recovery was.
the OP never answered my inquiry as to what exactly he is looking for in the recovery, a specific feature or function? without knowing the full story, its hard to say this is the best approach.
Never did look up updating script. Just trying to give ideas out of the box. It seems limiting.
life64x said:
Never did look up updating script. Just trying to give ideas out of the box. It seems limiting.
Click to expand...
Click to collapse
in my opinion, i'm not sure its a limitation of edify (updater-script) or a limitation of bash/sh/shell scripting (which edify can leverage) but more of a limitation in how custom recovery's are designed and versioned. provided android wasn't really designed to have many different versions of custom recovery's on one device, there aren't really any APIs setup for version control in the recovery .. in fact very little is supported in recovery as its just that ... a temporary recovery mode.
the method i mention above, hash'n out each version and storing in a table/index, would be one approach to implementing a type of version control w/o the custom recovery developer's changing their approach.
imo, the ideal approach would be for the custom recovery developers to implement a type of version control all custom recovery's follow, but since its not really *needed* or popularily demanded, i dont think that concept has a very high likihood of that occuring in the near future.
edify (updater-script) and bash scripting are both pretty decent languages and i think bring a very good set of features and abilities to the table, given the scope android originally designed the recovery mode for.
if for whatever reason you want recovery to support other languages or more features, i know twrp has a github where they track issues, put in a request or fork, code and send a pull request to their git. likewise i'm sure koush is open also.
the skys the limit!
[TOOL][HOW-TO] [N7] [grouper+tilapia] BootUnlocker Script [Flashable Zip]
BootUnlocker Script for Nexus 7 (2012) -- Unlock your bootloader without fastboot.
Important Information
Those of you with any of the other recent flagship Nexus devices (Galaxy Nexus onward) may already be familiar with the brilliant work of segv11 in creating the BootUnlocker for Nexus Devices app. His app uses root to flip a byte on a device partition, allowing you to relock your bootloader for security and unlock it again any time you wish without the data loss that would come from unlocking via fastboot. I have also followed segv11's method and created a recovery flashable zip for the same devices available from my Odds & Ends thread.
Through the work of myself and several others in the GN BootUnlocker App thread it has been found that the data which controls the lockstate for the N7 '12 is stored in the mmcblk0boot0 partition. Unfortunately we also found this data cannot be simply altered to change the lockstate of the N7 '12 (like it can with the other Nexus devices) due to encryption on a per-device basis. The encrypted data also changes with each new version of the bootloader. The complicated nature of the key means that it's unlikely that the encryption could ever be cracked.
There is, however, still a working solution. Even though your mmcblk0boot0 partition is uniquely encrypted for your device, I found it also changes exactly the same way each time you lock or unlock your bootloader. This means if you back up your mmcblk0boot0 partition when your device is both unlocked and locked, you can simply flash these partition dumps whole to change the lockstate, with no data loss. That's where my script comes in.
In this How-To we are going to make dumps of your mmcblk0boot0 partition in both lockstates, then alter my included zip and updater-script using the dumps so that you have a fully functioning BootUnlocker Script recovery flashable zip tailored to your specific device. When flashed, this zip will lock or unlock your device (depending on what state it's currently in), whenever you want with no data loss.
Requirements
Nexus 7 (2012) grouper/WiFi or tilapia/GSM-HSPA+ (both use the exact same bootloader).
An UNLOCKED bootloader (if locked you'll need to fastboot oem unlock first which WILL factory reset your device).
Bootloader version 4.23 (if newer, then you'll also need to follow the steps to update the bootloader check, found in the 3rd post).
Custom recovery (CWM or TWRP) flashed to your device.
adb+fastboot binaries/executables, either from the Android SDK or you can get them standalone from here.
Universal Naked Driver for Android devices recommended installed for both adb+fastboot on Windows machines.
Notepad2, Notepad++, or another text editor capable of keeping the LF (linefeed) format required for Linux/Unix files like the updater-script.
Disclaimers / Warnings (READ)
I am in no way responsible for you somehow messing up these reasonably simple steps and damaging your device. DO NOT attempt this if you do not accept this risk. If you met the above requirements (in particular the unlocked bootloader), then the following instructions will not result in any data being lost in this process. DO NOT post your zips to this thread once you've followed the directions since the zips will not work on other peoples' devices and if another user somehow flashes your dumps by mistake, could damage their device. Each device must have its own specific BootUnlocker Script zip made using the unique dumps that belong to it.
It is critical that you have read all of the above before you move on.
Building Instructions
Instructions
Step 1 - Getting the dumps and their sha1sums:
Start by downloading the zip attached to this post to your PC. Save it for later.
Boot into your custom recovery on your device with it connected, open a command prompt on your PC where you have adb+fastboot.
Ensure the device is recognized by typing "adb devices".
Type "adb shell" in and then do the following, being sure to copy+paste the sha1sum for unlocked to Notepad for later.
Code:
dd if=/dev/block/mmcblk0boot0 of=/tmp/unlocked-mmcblk0boot0.img
sha1sum /tmp/unlocked-mmcblk0boot0.img
exit
adb pull /tmp/unlocked-mmcblk0boot0.img unlocked-mmcblk0boot0.img
adb reboot-bootloader
fastboot devices
fastboot oem lock
Boot to Recovery using the Bootloader menu then "adb shell" in and do the following, again copy+paste the sha1sum for later, this time for locked.
Code:
dd if=/dev/block/mmcblk0boot0 of=/tmp/locked-mmcblk0boot0.img
sha1sum /tmp/locked-mmcblk0boot0.img
exit
adb pull /tmp/locked-mmcblk0boot0.img locked-mmcblk0boot0.img
It's important that the dumps are named correctly according to the lockstate for the script, and equally important you have kept those sha1sums straight and you know which corresponds to unlocked and which is for locked.
Step 2 - Editing the updater-script:
Extract the updater-script (in /META-INF/com/google/android/) from the zip.
It appears as follows, and is written with safety checks for bootloader version and current lockstate to prevent flashing on the incorrect version or device, respectively. It is currently written for v4.23 ONLY of the bootloader. If you update the bootloader or have a newer version you must update all of these checks (instructions in next post).
Code:
ui_print("");
ui_print("Nexus 7 BootUnlocker Script");
ui_print("by osm0sis @ xda-developers");
ui_print("");
ui_print("For N7 bootloader 4.23 ONLY");
ui_print("and the device belonging to <yourname> ONLY");
show_progress(1.34, 0);
ui_print("");
ui_print("Verifying device...");
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
ui_print(getprop("ro.product.device"));
assert(getprop("ro.product.device") == "<devicename>" ||
getprop("ro.build.product") == "<devicename>");
set_progress(0.2);
ui_print("");
ui_print("Verifying bootloader version...");
ui_print(getprop("ro.bootloader"));
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/USP:10485760:8c206a1a87599f532ce68675536f0b1546900d7a"),
getprop("ro.bootloader") == "4.23" ||
getprop("ro.boot.bootloader") == "4.23");
set_progress(0.5);
ui_print("");
ui_print("Checking bootloader status...");
run_program("/sbin/busybox", "dd", "if=/dev/block/mmcblk0boot0", "of=/tmp/current-mmcblk0boot0.img");
ifelse(sha1_check(read_file("/tmp/current-mmcblk0boot0.img")) == "<locked sha1sum>",
(ui_print("Bootloader is locked.");
ui_print("");
ui_print("Unlocking...");
package_extract_file("unlocked-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img");
),
(ifelse(sha1_check(read_file("/tmp/current-mmcblk0boot0.img")) == "<unlocked sha1sum>",
(ui_print("Bootloader is unlocked.");
ui_print("");
ui_print("Locking...");
package_extract_file("locked-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img");
),
(ui_print("Status does not match known values.");
ui_print("This is not the intended specific device.");
ui_print("");
ui_print("Your system has not been changed.");
ui_print("");
ui_print("Script will now exit...");
ui_print("");
delete("/tmp/current-mmcblk0boot0.img");
unmount("/system");
abort();
)
);
)
);
set_progress(0.9);
assert(run_program("/sbin/sh", "-c", "echo 0 > /sys/block/mmcblk0boot0/force_ro"),
run_program("/sbin/busybox", "dd", "if=/tmp/mmcblk0boot0.img", "of=/dev/block/mmcblk0boot0"),
run_program("/sbin/sh", "-c", "echo 1 > /sys/block/mmcblk0boot0/force_ro"),
delete("/tmp/current-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img"));
set_progress(1.2);
unmount("/system");
ui_print("Done!");
set_progress(1.34);
Open Notepad 2/Notepad++ and ensure it is set so that it won't break the LF (Unix) formatting when it saves, then open the extracted updater-script.
Make sure the device check on lines 14+15 matches your device. ie. If you are running a tilapia then you should change them (quotes intact) to "tilapia", likewise for "grouper".
Replace <yourname> on line 7 with your username. eg. the device belonging to osm0sis ONLY
Replace <unlocked sha1sum> on line 35 with the sha1sum for the unlocked dump you saved from Step 1.
Replace <locked sha1sum> on line 29 with the sha1sum for the locked dump you also saved from Step 1.
The sha1sum replacements are the most important. They MUST match the dumps correctly. Also make sure you leave the quotes in the script surrounding the sha1sums intact, eg. "0000000000000000000000000000000000000000"
Save and exit Notepad.
Step 3 - Putting it all together:
Add both .img files to the zip. They should be in the root (top level) of the zip. Make sure they are located correctly.
Overwrite the updater-script in /META-INF/com/google/android/ of the zip with your new edited version. Double check that it has replaced the old one and has been added correctly.
Save and exit the zip.
It is now recommended you name the zip according to the following scheme: cwm-N7.<device>.BootUnlocker.v<bootloaderversion>-<username> to differentiate device, bootloader version and user. Mine is cwm-N7.grouper.BootUnlocker.v4.23-osm0sis.zip. This should help prevent confusion.
Done! You now have a BootUnlocker zip for your N7 '12 until the bootloader gets updated.
Flash it to unlock your device again. Flash it again to lock it.
Previous version download count: 131
Update Instructions
Updating When A New Bootloader Is Released
Once built for your device, the above script will work as long as the bootloader remains at v4.23 (as per the naming). The way I've scripted it, for safety it shouldn't work on any other bootloader version or on anyone else's device, but I'd still advise against trying. Since the encrypted data also changes based on the version of the bootloader, if/when you update the bootloader you MUST also get NEW dumps of the mmcblk0boot0 partition both unlocked and locked.
BEFORE you update your bootloader, if your device is locked, start by using the BootUnlocker Script zip you previously created to unlock.
Update your bootloader to the new version (usually done via OTA or fastboot flash of a Factory Image).
Follow the steps in the 2nd post again to update your zip, replacing the .img files with the new dumps, and altering the update-script with the new corresponding sha1sums.
Change the version number in the updater-script warning on line 6 and the version number check on lines 22+23 to that of the new bootloader, and be sure you have renamed the zip with the new version number as well to keep things straight.
"adb shell" in while booted to custom recovery and run the following, copy+paste the bytesize and sha1sum for the next step.
Code:
dd if=/dev/block/platform/sdhci-tegra.3/by-name/USP of=/tmp/USP.img
sha1sum /tmp/USP.img
rm /tmp/USP.img
Enter the new bootloader's bytesize and sha1sum into the bootloader version check on line 21, in the following format USP:<bytesize>:<bootloader sha1sum>, eg. for v4.23 it is
Code:
USP:10485760:8c206a1a87599f532ce68675536f0b1546900d7a
Enjoy!
Questions, comments and feedback welcome.
Thanks to segv11 and efrant for all the fun in the GN BootUnlocker App thread, scary alien for the help with the bootloader check assert syntax in his OTA Verifier App thread, and thanks to trevd for the update-binary info/help in the GN EDIFY Scripting thread. Also a special thank you to Mach3.2, scary alien, partha and drose6102 for submitting dumps so all this could be figured out, and for basically being the Beta/RC testers for this script. Cheers!
You finally got it working! I ought to try this, of course after wrestling with the grizzly dad of mine. Awesome job there Chris!
Sent from my Galaxy Nexus using Tapatalk 2
Haha yup. I've had it working for awhile now, it was just a matter of writing up this monster guide. Thanks Fitz. Good luck with that wrestling.
Very cool, and very nice work.
osm0sis said:
Since the encryption also changes based on the version of the bootloader
Click to expand...
Click to collapse
The encryption does not change, that is static for the life of the device, what changes is the data stored. Also boot0/1 are technically not partitions and are more analogous to mmcblk0 than mmcblk0px there are 3 partitions that start within this range, BCT, PT and the start of the bootloader. BCT takes up the entire boot0 and part of boot1.
The reason you cannot just flash back your backup copy is a hash of the bootloader is stored in the bct for verification and integrity checking purposes[1]. This changes the end result because all SBK encrypted data is done in AES-128-CBC meaning the previous blocks cipher text is the next blocks IV.
Because of this you should also be careful of any number of other conditions that cause writing to the BCT as they have the potential to cause the decryption to fail on the rest of the BCT which is in mmcblk0boot1. While this may not (and at this point should not) cause bricking, changes made by google in the future may alter this outcome.
[1] The hash stored in BCT not matching the bootloader hash causes the device to fall back into APX mode.
lilstevie said:
The encryption does not change, that is static for the life of the device, what changes is the data stored. Also boot0/1 are technically not partitions and are more analogous to mmcblk0 than mmcblk0px there are 3 partitions that start within this range, BCT, PT and the start of the bootloader. BCT takes up the entire boot0 and part of boot1.
The reason you cannot just flash back your backup copy is a hash of the bootloader is stored in the bct for verification and integrity checking purposes[1]. This changes the end result because all SBK encrypted data is done in AES-128-CBC meaning the previous blocks cipher text is the next blocks IV.
Because of this you should also be careful of any number of other conditions that cause writing to the BCT as they have the potential to cause the decryption to fail on the rest of the BCT which is in mmcblk0boot1. While this may not (and at this point should not) cause bricking, changes made by google in the future may alter this outcome.
[1] The hash stored in BCT not matching the bootloader hash causes the device to fall back into APX mode.
Click to expand...
Click to collapse
Hey great to finally get some more information about the encryption used and the contents of boot0-1. Very interesting stuff. How did you determine this? We couldn't find much documentation on the matter. Any ideas on how to decrypt it would also be greatly appreciated, since that might allow segv11 to still be able to include it in the BootUnlocker app.
So far the only time we've seen the md5hash of the boot0 block change on a particular device is with a bootloader version change, after which it continues to remain consistent depending on lockstate. I was merely guessing that was part of the encryption process but the data changing would of course also make perfect sense, so thank you for that information. What doesn't change when unlocking/locking the bootloader is boot1, so flipping between the two states for boot0 will still keep decryption of boot1 intact.
I definitely understand your concerns that it is a dangerous business writing to these blocks, and I agree, but as you've seen I haven't taken this lightly in either my posts or my script; the script has safeties built in to make sure it only writes to boot0 when it meets one of the two known states for that person's device (locked or unlocked). If somehow the boot0 did change randomly in the future without a bootloader update then the script wouldn't run, it would abort, questioning whether this was the intended device or not since it couldn't determine the lockstate from the stored sha1sums. :good:
osm0sis said:
Hey great to finally get some more information about the encryption used and the content of boot0-1. Very interesting stuff. How did you determine this? We couldn't find much documentation on the matter. Any ideas on how to decrypt it would also be greatly appreciated, since that might allow segv11 to still be able to include it in the BootUnlocker app.
So far the only time we've seen the md5hash of the boot0 block change on a particular device is with bootloader version change, after which it continues to remains consistent depending on lockstate. I was merely guessing that was part of the encryption process but the data changing would of course also make perfect sense, so thank you for that information. What doesn't change when unlocking/locking the bootloader is boot1, so flipping between the two states for boot0 will still keep decryption of boot1 intact.
I definitely understand your concerns that it is a dangerous business writing to these blocks, and I agree, but as you've seen I haven't taken this lightly in either my posts or my script; the script has safeties built in to make sure it only writes to boot0 when it meets one of the two known states for that person's device (locked or unlocked). If somehow the boot0 did change randomly in the future without a bootloader update then the script wouldn't run, it would abort, questioning whether this was the intended device or not since it couldn't determine the lockstate from the stored md5hashes. :good:
Click to expand...
Click to collapse
it is off the shelf tegra security. As I said at this time changes shouldn't echo all the way through, but the BCT partition is usually ~3MB but only uses a fraction of that.
Decryption and Encryption of the data is not something easily available, it entirely defeats the purpose of it if you can do it yourself.
lilstevie said:
it is off the shelf tegra security. As I said at this time changes shouldn't echo all the way through, but the BCT partition is usually ~3MB but only uses a fraction of that.
Decryption and Encryption of the data is not something easily available, it entirely defeats the purpose of it if you can do it yourself.
Click to expand...
Click to collapse
Haha yeah of course it defeats the purpose, but in a way so does unlocking the bootloader with root.
Either way, thanks for the help and your Tegra knowledge.
Works perfect
Thanks a ton osm0sis. Just tested and it's flawless. Finally got rid of that unsightly unlock icon when you first boot and I still have full functionality. Locks and unlocks in an instant with the edited .zip file. Great work! :highfive:
lilstevie said:
The encryption does not change, that is static for the life of the device,
Click to expand...
Click to collapse
I am very interested in unlocking the bootloader without rooting or fastboot oem unlock my device. I'd love to find that key and be able to write an encrypted bootloader via JTAG access for example (I guess can't do otherwise to write an encrypted image as the encryption is probably done by the bootloader while uploading an image through fastboot am I right?)
I foresee 2 possibilities, but might be very wrong: 1) key hardcoded (in the BIOS for ex), I am trying to see if I can JTAG access the processor next week (theoretically frist, as my N7 arrives after 2 weeks)
2) the key is computed based on the device serial number (which I think might very well be the case) at startup (I'd guess a logical operation like an XOR on the serial maybe with a master key hardcoded or just a crypto op on the serial) in this case it might not be required to search for it in a memory dump but aska crypto guy see if with the knowledge of cyphered data, the algorithm and the serial, a key could be diversified...
If some of you guys are interested to work on that...we could open a new thread?
Meanwhile any of you know where I can get more info on the memory map of the flash?
My guess was that it was device serial number based as well. If you want to work on decrypting it, you could probably take it back to the main BootUnlocker App Dev thread: http://forum.xda-developers.com/showthread.php?t=1731993, since if you ever got it working it could likely be included in the app again.
No idea on the memory map unfortunately.
Just a reminder to everyone to unlock before you flash the OTA. Instructions for updating the script for new bootloader versions are in the 3rd post of this thread.
Happy OTA Day!
What is strange USP.img sha1 did not change. It still is 8c206a1a87599f532ce68675536f0b1546900d7a
???
---------- Post added at 06:07 PM ---------- Previous post was at 05:58 PM ----------
Anyway....working ok with 4.2.2 after updating with post 2 instructions.
sebarkh said:
What is strange USP.img sha1 did not change. It still is 8c206a1a87599f532ce68675536f0b1546900d7a
???
---------- Post added at 06:07 PM ---------- Previous post was at 05:58 PM ----------
Anyway....working ok with 4.2.2 after updating with post 2 instructions.
Click to expand...
Click to collapse
You're right, interesting! My guess, based on what lilstevie said, is that when the OTA writes the new bootloader to /USP it actually writes it to multiple contiguous partitions starting with USP, including the mmcblk0boot ones we dump. So whatever changed in the bootloader didn't alter the actual USP part this time, and that's why it checksums the same. The mmcblk0boot blocks do change, so the method in post 3 should still be followed.
Just updated to 4.18 and followed the instructions (minus the USP section in post 3) and all is working as expected. Thanks again!
Just noticed that having the mount /system in an assert will actually fail the assert if the system is already mounted. Not really a big deal, just means /system can't already be mounted when you go to run the BootUnlocker script or it won't make it past the device check. I haven't decided whether it matters enough to upload a new version of the script zip or not, since it's easy enough to go unmount /system before running it.
Also easy enough to fix it yourselves if you like:
Code:
assert(mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system"),
getprop("ro.product.device") == "grouper" ||
getprop("ro.build.product") == "grouper");
should instead be:
Code:
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
assert(getprop("ro.product.device") == "grouper" ||
getprop("ro.build.product") == "grouper");
Anyway, thought I'd give everyone the heads up even though nobody's apparently run into it or brought it to my attention before. :good:
Thanks for your tips! As I prefer to use the stock recovery I made a script to use your solution from the device itself, placing the partition backups in /system/usr/bootunlock. Here it is in case anyone else finds it useful:
Code:
#!/system/bin/sh
case $1 in
"lock")
echo "[x] Locking bootloader..."
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/system/usr/bootunlock/locked-mmcblk0boot0.img of=/dev/block/mmcblk0boot0
echo 1 > /sys/block/mmcblk0boot0/force_ro
echo "[x] Bootloader locked!"
;;
"unlock")
echo "[x] Unlocking bootloader..."
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/system/usr/bootunlock/unlocked-mmcblk0boot0.img of=/dev/block/mmcblk0boot0
echo 1 > /sys/block/mmcblk0boot0/force_ro
echo "[x] Bootloader unlocked!"
;;
*)
echo "Usage: $0 <lock|unlock>"
exit 1
;;
esac
Does it still work on the latest bootloader of Androud 4.3?
I just need to change the value in script and replace img files?
Thanks.
reserved....
Please make a post if you encounter a problem while using BMM
Whirly, just to make sure I'm doing things correctly, to create a virtual system on say system 3. All I have to do in the settings is create, the system, data and cache.img files
In root explorer I go into sdcard-ext and I can see the folder Virtual>System 3>then all the image files inside, then flash the zip yet when I try to boot it gets stuck on booting with the green droid
I'm trying to flash Dwiz ROM that I had working before on my number 1 system, also I unchecked 2nd boot and kexec.
Also I know you haven't got full Razr V yet support so it may just be a bug
Thanks for being so helpful!
complete erase the slot
As most ROM requires clean slot to work, how can we completely erase the slot?
metalhead_rulz said:
As most ROM requires clean slot to work, how can we completely erase the slot?
Click to expand...
Click to collapse
A properly designed ZIP installer should take care of cleaning by itself. In order to start afresh you can destroy old image and create a new one - this is not possible for real partitions. These can be reflashed from FXZ and then "formatted" by removing all files and directories.
will u upgrade bmm to be compatible with cm 10.1 from hashcode? thanks. if yes, will it be possible to install cm 10.1 as stock rom?
For some reason I cant restore any back ups. I have tried both formats and I have been doing the quick backup.
When I restore it goes through the process then finishes with an error "there was an error writing to system" or something similar. I have tried mounting and formatting system etc but no good.
Can someone tell me the best way to take a log so I can better see were it is going wrong.
Cheers
romdroid. said:
will u upgrade bmm to be compatible with cm 10.1 from hashcode? thanks. if yes, will it be possible to install cm 10.1 as stock rom?
Click to expand...
Click to collapse
I believe it was caused by this commit :
https://github.com/STS-Dev-Team/android_system_core/commit/e15eebac61d22edbe8d4aee1e794176acc4cf526
Code:
#ifndef NO_DEVFS_SETUP
mkdir("/dev", 0755);
mkdir("/proc", 0755);
mkdir("/sys", 0755);
mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755");
mkdir("/dev/pts", 0755);
mkdir("/dev/socket", 0755);
mount("devpts", "/dev/pts", "devpts", 0, NULL);
mount("proc", "/proc", "proc", 0, NULL);
mount("sysfs", "/sys", "sysfs", 0, NULL);
/* indicate that booting is in progress to background fw loaders, etc */
close(open("/dev/.booting", O_WRONLY | O_CREAT, 0000));
/* We must have some place other than / to create the
* device nodes for kmsg and null, otherwise we won't
* be able to remount / read-only later on.
* Now that tmpfs is mounted on /dev, we can actually
* talk to the outside world.
*/
open_devnull_stdio();
klog_init();
#endif
BMM always clean all tmpfs partition before 2nd-init, so that init can do a fresh start.
But since this commit, some devfs is not recreated, thus ROM can't be booted.
If you want to boot newer build, you have to build your own init. (undefine BOARD_USE_NO_DEVFS_SETUP)
or take init binary from 24012013 build. (Not recommended)
Attached is init binary taken from 24012013 build for testing.
Flash this zip after flashing STS CM zip file.
Why we have to skip devfs creation??? anybody????
Should I fix this in BMM boot script???
Help on system 3
Thanks for this great project
Whirleyes I'm having trouble extracting the log from BMM I hit report error but cant see where it is saved.
Anyway I viewed the flash log in recovery mode after doing a backup and got these errors. It sounds like its an issue with the wrong directory being mounted or something.
W: failed to mount /dev/block/mmcblk1p25 (no such file or directory)
No /into/.android_secure found skipping backup of applications on external storage.
I'm assuming this is also why I'm having travel restoring the backups.
Cheers
Sent from my Nexus 7 using Tapatalk 2
I'm not sure if this is caused by BMM, but I'm going to explain, just in case.
It's the second time that I habe a "boot failure flash" problem, as described here
http://forum.xda-developers.com/showthread.php?t=1893347
The first time it happened I was trying to come back from JB kernel, but now I just reboot from a completely working ROM (JellyWiz) and it went to that AP boot failure flash.
It seems like webtop partition gets corrupted or something, because I'm always able to fix it flashing a webtop image, as described here http://forum.xda-developers.com/showthread.php?t=1792955, in "Fastboot for the webtop_signed"
As BMM uses webtop partition, maybe it can be related to the problem...
I'm sorry I don't have more precise or technical information but I don't have much knowledge, also that problem appeared in two different situations, apparently it was not related to a specific situation.
blackhawk_LA said:
I'm not sure if this is caused by BMM, but I'm going to explain, just in case.
It's the second time that I habe a "boot failure flash" problem, as described here
http://forum.xda-developers.com/showthread.php?t=1893347
The first time it happened I was trying to come back from JB kernel, but now I just reboot from a completely working ROM (JellyWiz) and it went to that AP boot failure flash.
It seems like webtop partition gets corrupted or something, because I'm always able to fix it flashing a webtop image, as described here http://forum.xda-developers.com/showthread.php?t=1792955, in "Fastboot for the webtop_signed"
As BMM uses webtop partition, maybe it can be related to the problem...
I'm sorry I don't have more precise or technical information but I don't have much knowledge, also that problem appeared in two different situations, apparently it was not related to a specific situation.
Click to expand...
Click to collapse
Because BMM 0.3.4 format webtop partition without asking cdt for safe region.
It should be no problem with 0A7* bootloader... but not everybody is using it. [Lesson learned]
Here's a bootloader updater tools. (razr_bl_mbm_*.zip)
http://dl.projectlense.com/download.php?file=spyder/razr_bl_mbm_0a77.zip
Thanks! It worked perfectly but I had to copy AdbWinApi.dll to the tools folder. :good:
whirleyes said:
Attached is init binary taken from 24012013 build for testing.
Flash this zip after flashing STS CM zip file.
Why we have to skip devfs creation??? anybody????
Should I fix this in BMM boot script???
Click to expand...
Click to collapse
confirmed as working, also with newer build versions.
thanks whirley! if its not too much hassle for you it would be nice to have it added to bmm, but then again its just flashing one more zip file...doesn't really hurt much
i just think integrating the ability to flash these new roms would take away the one last reason to use ss3 and not bmm^^ so you would probably win over a few more users that are not switching because they want to test the newer cm10.1 roms.
btw whats up with project kaizen? im still interested in checking that out
also i'm glad to see you back on xda!!!
Maybe I'm a stupid boy but it's possible to speak with Hashcode to solve this problem?
hello, I have a problem. When I open my BMM 0.2.6, it said Application Corrupted and It need redownload from Google Play.
And when I want to uninstall it, the installation was unsuccessful. How to uninstall the corrupted BMM?
pseudoheld said:
confirmed as working, also with newer build versions.
thanks whirley! if its not too much hassle for you it would be nice to have it added to bmm, but then again its just flashing one more zip file...doesn't really hurt much
i just think integrating the ability to flash these new roms would take away the one last reason to use ss3 and not bmm^^ so you would probably win over a few more users that are not switching because they want to test the newer cm10.1 roms.
btw whats up with project kaizen? im still interested in checking that out
also i'm glad to see you back on xda!!!
Click to expand...
Click to collapse
thanks, does stock flashing also work?:fingers-crossed:
romdroid. said:
thanks, does stock flashing also work?:fingers-crossed:
Click to expand...
Click to collapse
What do you mean? Flashing to the first (stock) system has always worked on bmm!
txdvil said:
hello, I have a problem. When I open my BMM 0.2.6, it said Application Corrupted and It need redownload from Google Play.
And when I want to uninstall it, the installation was unsuccessful. How to uninstall the corrupted BMM?
Click to expand...
Click to collapse
It's outdated. Just download the latest available version (current is 034).
I want to remove all older BMM file from download server soon.
pseudoheld said:
ss3 and not bmm^^ so you would probably win over a few more users that are not switching because they want to test the newer cm10.1 roms.
Click to expand...
Click to collapse
It's not about lose or win. No benefit at all. I just want something that works for me.
For efficiency, I think I won't add support for CM10.1 (with skip devfs on)
(extra code for ROM detection = extra boot delay)
pseudoheld said:
btw whats up with project kaizen? im still interested in checking that out
Click to expand...
Click to collapse
It's only good for personal use. Don't count on me.
I've noticed using 0.3.4 with bootloader 0A7 that I cannot backup my CID. I did it with terminal emulator. Erase it was possible. Maybe it's not related with hmm, but I've tried many times, also I've installed it a few times to be sure.
It is something that I did wrong?
Also thanks A LOT for this
pseudoheld said:
What do you mean? Flashing to the first (stock) system has always worked on bmm!
Click to expand...
Click to collapse
yes, I was refering to installing cm10.1 to stock system. thanks for the answer :good:
After many requests, I finally sat down and whipped up a UNIVERSAL MIUI installer for both CDMA and GSM versions of the Evo 3D.
The ROM itself is directly based on official weekly builds for CDMA and GSM editions. I have made a few changes to the filesystem (fixed HOSTS from blocking certain sites), added the original camera.apk that was included in initial releases of v5, and threw in a whole bunch of tweaks and extras.
Now, as CDMA is my native device, it will be a little more difficult to test and provide support for GSM. However, official releases have been rock-solid for quite a while now, so there shouldn't be any significant issues.
Below is the link to my CDMA thread. You will find weekly releases and changelogs here. If you require support, please post questions there. It's just easier for me.
Enjoy.
http://forum.xda-developers.com/showthread.php?t=2047911
Reserved
Super .. Good
Thanks.
Sent from my HTC EVO 3D X515m using xda premium
whoa thanks man! i'm definitely going to try your work :victory:
I tried to install this on my evo 3D gsm but it won't boot... I'm stuck in bootloader so I had to restore my old rom
Domac5 said:
I tried to install this on my evo 3D gsm but it won't boot... I'm stuck in bootloader so I had to restore my old rom
Click to expand...
Click to collapse
Hmmm...and herein lies the difficulty of porting for a device you don't have.
So, it's one of several things. On my end, I either borked one of the partitions somewhere (GSM and CDMA use different layouts) or I maybe missed a file difference.
It could also be a hboot/firmware issue. Again, I don't know much about the GSM stuff, but this is based on AOSP JB 4.1.2, so whatever hboot and firmware config works for that should work for this.
I apologize...I will go over the installer again and see if I missed something. If anybody else who's tried this could please report back with your results, it might help me in narrowing down the issue.
Edit: Also updated the OP info to reflect that this needs work yet.
I'll try this built in the morning .Love MIUI and this is big surprise
problem could be in aroma installer... at the end aroma should ask me do I want reboot but that part show about half second than just disappear and I have to manually reboot from 4ext recovery... I'm using hboot 1.49007 and I was on Yoda's rom before installing MIUI
After some updater-script hackery I got it booting,but every app force closes at the initial setup
Pc wouldn't see the device so didn't grab a logcat
So...is it too soon to download? Or will it boot?
B3!CrAZy said:
So...is it too soon to download? Or will it boot?
Click to expand...
Click to collapse
Yes it's too soon. It'll take you as far as bootloader only. Even if you make it past that, according to heli, apps fc's at initial setup. This is a WIP according to the op so we'll have to wait until he can fix the issue :good:
helicopter88 said:
After some updater-script hackery I got it booting,but every app force closes at the initial setup
Pc wouldn't see the device so didn't grab a logcat
Click to expand...
Click to collapse
What was the problem in updater-script? I just sat down at the computer today...gonna start going through it in a second here.
digitalhigh + helicopter88 = Perfect MIUI Jellybean
WellP, I just went over the files with a fine tooth comb (in this case, the comb being a 3-way folder compare utility), and found a few places where there were libs and configs either doubled up, or missing entirely. Sure this doesn't help with apps running.
Downloading Cool ICS GSM right now, gonna check out the updater-script/aroma in that and see if I can get some clues as to what I missed. I think between the file fixes and Aroma, this should be working shortly.
Okay, found three errors in the updater-script that definitely won't help. Fixed those, plus the changes to the filesystem(s). Uploading to goooooo now, will update this post and my OP in CDMA with the link when it's done uploading.
Waiting Waiting
digitalhigh said:
What was the problem in updater-script? I just sat down at the computer today...gonna start going through it in a second here.
Click to expand...
Click to collapse
I took META-INF from a random rom of mine,edited updater-script to flash also /data,and unpacked the contents of DH/gsm into system
helicopter88 said:
I took META-INF from a random rom of mine,edited updater-script to flash also /data,and unpacked the contents of DH/gsm into system
Click to expand...
Click to collapse
Well, I found two points where I had two calls to the FS optimizations one above the other, and I changed the partition number for the first line but didn't see it in the second. That prolly messed all kinds of stuff up. I also excluded the first part of the app selection menu, which was the cause of the customize.prop not being present. The new upload should be done in about 20 minutes...
http://goo.im/devs/digitalhigh/miuiv5/MIUI_3.6.29_SHOOTERS_DH.zip
If anybody would like to test-flash this and post results, I would appreciate it. Might be advisable to save the install log as well as grab a logcat...providing it installs fully and gets past bootloader. Thanks.
Hello,
No matter what I do, I have always status 4 error when trying to install my own update.zip, however - no error when installing 3rd party updates. What means this status code in cwm?
My updater-srcipt (very basic to test things):
Code:
show_progress(0.500000, 0);
ui_print("****TEST****");
ui_print("***********OK!***********");
show_progress(0.100000, 0);
Why this throws status 4 error ??
giaur said:
Hello,
No matter what I do, I have always status 4 error when trying to install my own update.zip, however - no error when installing 3rd party updates. What means this status code in cwm?
My updater-srcipt (very basic to test things):
Code:
show_progress(0.500000, 0);
ui_print("****TEST****");
ui_print("***********OK!***********");
show_progress(0.100000, 0);
Why this throws status 4 error ??
Click to expand...
Click to collapse
Maybe something wrong with your updater-script. What's the setting of your editor (e.g., Notepad++)?
I figured it out... there was updater-script misspelled - I had 'updater-srcipt' instead of 'updater-script'. Very stupid mistake and my fault...
Btw - where can I find all cwm status codes with explanation? Because status codes only don't say anything if I don't know their meaning. For example, in my case message like "updater-srcipt not found" would be better. But usually cwm throws only status code errors without helpful error message.
giaur said:
I figured it out... there was updater-script misspelled - I had 'updater-srcipt' instead of 'updater-script'. Very stupid mistake and my fault...
Btw - where can I find all cwm status codes with explanation? Because status codes only don't say anything if I don't know their meaning. For example, in my case message like "updater-srcipt not found" would be better. But usually cwm throws only status code errors without helpful error message.
Click to expand...
Click to collapse
There is a thread on that forum,specially for cwm errors: http://forum.xda-developers.com/showthread.php?t=2230733.
And I saw familiar thread on 4pda.ru-I think it more informative than xda thread.
Sorry for my bad English.
B.B.N. said:
There is a thread on that forum,specially for cwm errors: http://forum.xda-developers.com/showthread.php?t=2230733.
Click to expand...
Click to collapse
Very nice, but I can't see (for example) error status 4 meaning. So it's not complete error list?
giaur said:
Very nice, but I can't see (for example) error status 4 meaning. So it's not complete error list?
Click to expand...
Click to collapse
Yes,there are most often errors.
Sent from my MT27i using XDA Free mobile app