MOTOACTV ROMs
- Thread starter CEnnis91
- Start date
For some reason I can't post link from my phone.
Hit me up on gtalk bdaman80 at gmail
Sent from my DeathStar disabled device
Hit me up on gtalk bdaman80 at gmail
Sent from my DeathStar disabled device
Serial Number Found !!!
Wow have I ripped my watch apart :-D
It seems Big M has done a good job hiding the device ID number necessary for future updates/upgrades.
A simple "adb get-serialno" will return the board's (OMAP) serial number. This is useless and probably used for debugging purposes only. Big M does not use this serial number as it has no control over OMAP SOCs productions.
But what Big M does not want you to know, is that they have hidden their own traceable serial number in a hidden partition... The PDS partition.
Yep that's right folks... our traceable serial numbers are hidden in the PDS partition.
To access that partition you will need to dump the PDS partition:
adb shell dd if=/dev/block/mmcblk1p6 of=/sdcard/pds.img bs=1024
Then you will need to pull the dumped img to your pc:
adb pull /sdcard/pds.img
Once you have the pds.img file on your PC, use "Explor2fs" to open the IMG file. This will show you the full the directory structure within pds.img.
On your left, browse to the "device_id" folder, and you should see a "id_file" on your right.
Right click "id_file" and select the "export file" option to export the file to your PC.
Attached is a screenshot for reference.
Use the notepad to view the exported file and see your unique device ID no.
The "id_file" contains your valuable device ID used for verification during firmware upgrades and OTA updates. Interestingly, init.rc calls the PDS partition for serial no verification during the boot initialization process.
It is possible to corrupt your PDS partition rendering your watch un-upgradeable. Be careful when tampering around.
Wow have I ripped my watch apart :-D
It seems Big M has done a good job hiding the device ID number necessary for future updates/upgrades.
A simple "adb get-serialno" will return the board's (OMAP) serial number. This is useless and probably used for debugging purposes only. Big M does not use this serial number as it has no control over OMAP SOCs productions.
But what Big M does not want you to know, is that they have hidden their own traceable serial number in a hidden partition... The PDS partition.
Yep that's right folks... our traceable serial numbers are hidden in the PDS partition.
To access that partition you will need to dump the PDS partition:
adb shell dd if=/dev/block/mmcblk1p6 of=/sdcard/pds.img bs=1024
Then you will need to pull the dumped img to your pc:
adb pull /sdcard/pds.img
Once you have the pds.img file on your PC, use "Explor2fs" to open the IMG file. This will show you the full the directory structure within pds.img.
On your left, browse to the "device_id" folder, and you should see a "id_file" on your right.
Right click "id_file" and select the "export file" option to export the file to your PC.
Attached is a screenshot for reference.
Use the notepad to view the exported file and see your unique device ID no.
The "id_file" contains your valuable device ID used for verification during firmware upgrades and OTA updates. Interestingly, init.rc calls the PDS partition for serial no verification during the boot initialization process.
It is possible to corrupt your PDS partition rendering your watch un-upgradeable. Be careful when tampering around.
Attachments
Last edited:
Wait, so when we rooted our motoactvs, we flashed over the PDS partition? In that case, we should backup the id_file from our stock watch and then we should be able to update from there on out right?
I cannot confirm that. I do not believe our update methods tamper with the PDS partition. Further testing needs to be carried out to confirm failure of upgrades.
It doesn't tan. We only flash the boot.img, that's all. Then copy over the root binaries, superuser, recovery, and supporting files.
That partition is not touched.
My guess is it's a mismatched build.prop; as there is one in the boot image as well as one in /system. We need to match those before it will let us update, but I'm not sure how to pull the one from a boot.img, otherwise I'd just match it in the "return to stock" button of the root tool and everyone would be able to update. The ones there now are from 2 different devices, so the serials and such don't match. Little help?
That partition is not touched.
My guess is it's a mismatched build.prop; as there is one in the boot image as well as one in /system. We need to match those before it will let us update, but I'm not sure how to pull the one from a boot.img, otherwise I'd just match it in the "return to stock" button of the root tool and everyone would be able to update. The ones there now are from 2 different devices, so the serials and such don't match. Little help?
Test kernel seems fine, but I need some testers on same as me, and different versions than both of mine. I'm on 4.55.78
Sent from my DeathStar disabled device
Sent from my DeathStar disabled device
Attachments
Last edited:
It doesn't tan. We only flash the boot.img, that's all. Then copy over the root binaries, superuser, recovery, and supporting files.
That partition is not touched.
My guess is it's a mismatched build.prop; as there is one in the boot image as well as one in /system. We need to match those before it will let us update, but I'm not sure how to pull the one from a boot.img, otherwise I'd just match it in the "return to stock" button of the root tool and everyone would be able to update. The ones there now are from 2 different devices, so the serials and such don't match. Little help?
I do not believe so... I cannot find any reference to another Device ID number in Boot img. Just checked and can confirm that boot only requests it from the PDS partition. I do not believe that Big M injects your ID inside your update before pushing it to you. Honestly, that would sound suicidal for Big M's engineers
The Build prop is programmed to be overwritten at every boot regardless of what you put in your system folder. I have even been able to isolate the code and stop it from doing so on reboot
I dunno if this helps anyone. However my friend just got an 8gb active and he's running the 4.55.97 update. He then decided to root using the root tool and replaced the boot.img file and then used the root step. He has all the features of the latest version (ie percent on battery). And he is able to install zeam launcher and custom apps and whatnot.
Can he run
adb pull /system system
then zip the system folder that's created and send it to me?
I can build from that, hopefully.
Next rom update will use bda's latest kernel, pending stability.
adb pull /system system
then zip the system folder that's created and send it to me?
I can build from that, hopefully.
Next rom update will use bda's latest kernel, pending stability.
Can he run
adb pull /system system
then zip the system folder that's created and send it to me?
I can build from that, hopefully.
Next rom update will use bda's latest kernel, pending stability.
I'll see what I can get from him and get back to you.
Finally got boot to flash from updater script !!!
I have to say... This was one hell of a b**ch !!! The reason boot flashing has been failing is because of the faulty recovery we have, hence the Beta status of our recovery.
For this to work, you will need busybox installed on your system folder.
Meaning... Make sure busybox libraries are present in /system/xbin.
If you are flashing a new ROM, run package_extract_dir first to dump system first.
Then place the following code at the very end of the updater script to flash boot.img :
ui_print("");
ui_print("Test - Boot - Flasher");
ui_print("Mounting System");
mount("ext3", "MMC", "/dev/block/mmcblk1p18", "/system");
ui_print("");
ui_print("Stage 1... Extracting");
package_extract_dir("bootimg", "/tmp");
ui_print("Stage 2... Setting Perms");
set_perm(0, 0, 0777, "/tmp/boot.img");
ui_print("Stage 3... Flashing Boot");
run_program("/system/xbin/busybox", "dd", "if=/tmp/boot.img", "of=/dev/block/mmcblk1p12", "bs=1024");
ui_print("Unmounting System");
unmount("/system");
ui_print("");
ui_print("Flash Successful");
ui_print("");
Note:
- No need to mount system again if you've done that in the beginning of the script.
- I've placed boot.img in a separate folder named bootimg within the zip file.
- Remember to set /tmp/boot.img permissions to give busybox access to boot.img
I have tested this and can confirm that it is working 100%.
Enjoy
I have to say... This was one hell of a b**ch !!! The reason boot flashing has been failing is because of the faulty recovery we have, hence the Beta status of our recovery.
For this to work, you will need busybox installed on your system folder.
Meaning... Make sure busybox libraries are present in /system/xbin.
If you are flashing a new ROM, run package_extract_dir first to dump system first.
Then place the following code at the very end of the updater script to flash boot.img :
ui_print("");
ui_print("Test - Boot - Flasher");
ui_print("Mounting System");
mount("ext3", "MMC", "/dev/block/mmcblk1p18", "/system");
ui_print("");
ui_print("Stage 1... Extracting");
package_extract_dir("bootimg", "/tmp");
ui_print("Stage 2... Setting Perms");
set_perm(0, 0, 0777, "/tmp/boot.img");
ui_print("Stage 3... Flashing Boot");
run_program("/system/xbin/busybox", "dd", "if=/tmp/boot.img", "of=/dev/block/mmcblk1p12", "bs=1024");
ui_print("Unmounting System");
unmount("/system");
ui_print("");
ui_print("Flash Successful");
ui_print("");
Note:
- No need to mount system again if you've done that in the beginning of the script.
- I've placed boot.img in a separate folder named bootimg within the zip file.
- Remember to set /tmp/boot.img permissions to give busybox access to boot.img
I have tested this and can confirm that it is working 100%.
Enjoy
Last edited:
The 4.55.97 files are up for real this time (no one really needs 4.55.78 at this point), sorry for the delay, thanks for all the help, and enjoy. =)
*crosses fingers*
*crosses fingers*
5.6.0!
Sorry guys for another update; hopefully you can forgive me. 5.6.0 stock and rooted are now available (I said it would be easy once we got all the kinks out). There also might be some more good news: because I obtained a completely stock system.img (thanks embeem), it's possible that updating will again be possible via motocast if you flash the stock-5.6.0-update.zip. We won't know for sure until the next update however.
Sorry guys for another update; hopefully you can forgive me. 5.6.0 stock and rooted are now available (I said it would be easy once we got all the kinks out). There also might be some more good news: because I obtained a completely stock system.img (thanks embeem), it's possible that updating will again be possible via motocast if you flash the stock-5.6.0-update.zip. We won't know for sure until the next update however.
HOW?
How 'd you do it? Overclocking1000MHZ？
---------- Post added at 02:42 AM ---------- Previous post was at 02:24 AM ----------
Look forward to update for a long time, Alway staying at the4.55.78
How 'd you do it? Overclocking1000MHZ？
---------- Post added at 02:42 AM ---------- Previous post was at 02:24 AM ----------
Look forward to update for a long time, Alway staying at the4.55.78
I got this one.
OMAP3 Processor, same one used in the Droid 2; Droid 2 has it running at 1 Ghz, so why shouldn't we? They toned ours down for the watch, presumably to save battery power.
OMAP3 Processor, same one used in the Droid 2; Droid 2 has it running at 1 Ghz, so why shouldn't we? They toned ours down for the watch, presumably to save battery power.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
33Rooting and updating your MotoActv is about to get significantly easier! No more waiting games for developers to update their ROMs or tools when Motorola pushes a new OTA; now you can do it yourself! I honestly have not seen these types of files ANYWHERE else, so I had to create these myself (with quite a bit of help from [mbm]). But enough blabbing, here are the files and how to use them:
(Note: all these methods assume we have full fastboot access! -- Which we still have at this point)
- Stock Images:
These are not just mere update.zips that you might be accustomed to elsewhere in Android. Nor are these mere fxzs that you might be accustomed to elsewhere with newer Motorola devices. They are in fact both and more. There are 3 main ways to flash these files onto your device, giving you options based on what OS you run and how comfortable you are flashing files to your device.
1) FXZ:
- Operating System: Windows
- Requires: RSD Lite with FXZ Support
- Instructions: Simply load up the file as any standard fxz (it is very straight-forward)
2) Recovery:
- Operating System: Anything that can mount your device
- Requires: The ability to get into recovery
- Instructions: Place the file on the sdcard, boot into recovery, flash as normal
- Note: Recovery does not wipe your device, it is suggested that you do so before flashing stock images
3) Fastboot:
- Operating System: Windows/Linux/Mac
- Instructions (Windows): Unpack the zip, run flash-all.bat (if it fails, run as administrator)
- Instructions (Linux/Mac): Unpack the zip, run flash-all.sh (it should already have proper permissions)
Miscellaneous Images:
These miscellaneous images are nothing you haven't seen before at this point, but their purposes are new, so they too require explanation.
1) AnyRoot:
AnyRoot is based on koush's AnyKernel in the sense that it unpacks and repacks the boot.img on the fly. However, as the name suggests, AnyKernel is meant for kernels, while AnyRoot, actually roots the device on the fly. This will work on any MotoActv device. It is flashed as a normal update.zip and everything is done in the background so you won't noticed much. However, for ease of access, the stock and rooted boot.img is exported to your sdcard in /sdcard/recovery/. Also note, that if you happen to flash AnyRoot over an already rooted device, nothing will happen as it has built-in error checking.
2) rebootRecovery:
rebootRecovery is another fxz type zip, the same as the stock and rooted images, except it can't be flashed in recovery (would be a little redundant don't you think?). This flashes a specially made misc.img by [mbm] that tells the device to reboot into recovery from boot. This means you can flash AnyRoot on any stock device.
How Tos / FAQs:
Now that you know what the files do, I can explain in short steps how to use these files to get what you want:
1) How to Return the Device to Stock?
- flash a stock image using any of the 3 methods
- you can now update via Motocast if you so wish
2) How to Root a Stock Device?
- update your device via Motocast to the latest version (suggested)
- place AnyRoot on your sdcard
- boot into fastboot, and flash rebootRecovery using either of the 2 methods
- flash AnyRoot in recovery
- reboot
3) How do I update my Rooted Device?
- flash a stock image using any of the 3 methods
- update your device via Motocast to the latest version
- place AnyRoot on your sdcard
- boot into fastboot, and flash rebootRecovery using either of the 2 methods
- flash AnyRoot in recovery
- reboot
Q: After using rebootRecovery I can't get out of recovery!?
A: You are using an old recovery that doesn't clear the 'reboot-recovery' command; use the newer recovery: https://dl.dropbox.com/u/5849675/android/f100/CWMR5x_F100_recoveryB2.img
Q: What do these ROM offer over other custom ROMs?
A: Nothing, they are simply stock images, but you can upgrade with them.
Q: How much battery should I have when I flash?
A: Performing any kind of these flashes will drain at least 10% of your battery, I wouldn't suggest you flash below 60% ESPECIALLY IF YOU FLASH rebootRecovery!
Q: What happens if I flash a 16gb zip on my 8gb or visa-versa?
A: Don't freak, it will still boot, but it's not the best thing in the world to do, just go back and flash the correct model zip.
Q: Can I extract the images from your zips and flash them my own way?
A: yep (couldn't really think of anything else to say)
Q: I manually flashed the stock-boot.img from AnyRoot, and now I can't update. Why?!
A: The boot.imgs need to be truncated before they can be flashed to correctly work with Motorola's updates, just use the stock images.
Q: What's next?
A: HyprActv -- What's this?
Stock Images (w/ md5sums):
8gb-NA: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_8GB_NA.zip (5e228bf56a67aced012c8cbb2d7f7c76)
16gb-NA: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_16GB_NA.zip (21b067dc629f7ccd18b43799d8d5fb17)
8gb-EU: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_8GB_EU.zip (5b79a46d87728303fc2c920eec71c2e8)
Miscellaneous Images (w/ md5sums:
AnyRoot: https://dl.dropbox.com/u/5849675/android/f100/MA_AnyRoot.zip (2f867b006da42865ef861094db0eb6e6)
Reboot Recovery: https://dl.dropbox.com/u/5849675/android/f100/MA_RebootRecovery.zip (1623c9c61462db9bb20b55bc8f1144aa)
Mirror (thanks Iownox!): http://www.androtransfer.com/?developer=lownox&folder=MotoACTV3
I have been heavily working on the bluetooth stack in MotoACTV. The blues stack supports low energy devices. The BT hardware chipset supports v4.0 LE devices. This was all confirmed via JTAGing the watch. I am in the final stages of modifying the stack to support the following profiles:
- DUN
- PAN
- HID INPUT
- SINK
- AUTO
with no restrictions whatsoever.
Tested a BT mouse and keyboard, worked perfectly.
Once this is done and posted, I will start working on getting USB HOST & OTG support enabled on MotoACTV as well.2Will be working on this tonight. I just found out how to make the flash script clear cache and dalvik for you, pre-install. That'll probably save some headache, but it works only in edify format. Not sure what the stock recovery uses...
Anyways, I'm home!
All recoveries will now use edify, amend is old and depreciated, you will only find that on old devices.
