Related
I've seen a number of requests for this functionality and recently it became necessary for one user who had a disabled Home Key to clear cache and data without the use of ClockworkMod. I have reserached two methods to address this issue. These instructions require some familiarity of android, computer and tablet terminology and usage. Feel free to ask for clarifications in comments. Here we go...
Method I - Stock Recovery Command File
Technical: Stock Recovery command file can be used to perform a few additional functions as well as to alter the path to update files. These commands will execute with all privileges available to recovery mode.
Advantages: Very easy to use. Very little technical knowledge required. No third party software is required for use.
Prerequisites: You will need a MicroSD card formatted FAT32 and a method for transferring files from your computer to the MicroSD.
Usage:
1) Prepare a text file named "command" (no file extension) with one of the following commands on a single line. The wipe data command will wipe both data and cache. Wipe cache will wipe cache only.
--wipe_data
--wipe_cache
2) Place the file in a folder named "recovery" in the root directory of your MicroSD card.
3) From a powered down state, insert the MicroSD card into your tablet and boot into recovery by powering it on while holding down the Volume Up key.
4) Allow the command to execute completely then the tablet should reboot (this may not occur automatically depending on firmware installed).
Method II - Updater Script
Technical: The attached "Updater Scripts" perform delete commands (recursively if necessary) on the named directory or file(s). The directories are mounted automatically by the system before the script executes but it could be easily revised to include that step if necessary. The partitioning, formatting and directory structure are left untouched. Only files are deleted.
Advantages: No third party software is necessary for execution. Relatively easy to modify for more surgical precision (i.e. leaving installed apps but clearing possibly corrupted system data). Included example: "Clear Battery Stats"
Prerequisites: You will need a MicroSD card formatted FAT32 and a method for transferring files from your computer to the MicroSD.
Usage:
1) Download the attached archive (ClearData.zip) to your computer.
2) Extract the files to your computer. You should then have a folder named "recovery" (which contains a file named "command") and an additional archive named "update.zip"
3) Place the recovery folder and the update.zip in the root directory of the MicroSD card.
4) From a powered down state, insert the MicroSD card into your tablet and boot into recovery by powering it on while holding down the Volume Up key.
5) Allow the script to execute completely then reboot the tablet (this may occur automatically depending on firmware installed).
This will become handy someday.
Thanks for sharing your knowledge.
You're welcome. One quick note... the new stock recovery adds a menu simiilar to ClockworkMod. These methods will still work since the recovery folder/command file are checked first but it really isn't as necessary any more.
Need Help
Tried both methods above but either way I get to the viewsonic splash with the message "Booting recovery kernel image" in the upper left and it just stays there, stuck there, I left it for a long time to see and it never leaves that screen.
Any ideas?
Me too
I can't get into clockworkmod either. My machine is running faster. I almost hate to mess it more.
lrgche said:
Tried both methods above but either way I get to the viewsonic splash with the message "Booting recovery kernel image" in the upper left and it just stays there, stuck there, I left it for a long time to see and it never leaves that screen.
Any ideas?
Click to expand...
Click to collapse
That's an indication that you may have more serious problems. nvflash will be required. http://forum.xda-developers.com/showthread.php?t=861950
Once done you will likely need to install ClockworkMod and repartition your internal storage.
Loukoebel said:
I can't get into clockworkmod either. My machine is running faster. I almost hate to mess it more.
Click to expand...
Click to collapse
If your tablet boots properly but you can't get into CWM then it probably isn't installed properly (or at all). http://forum.xda-developers.com/showthread.php?t=865245
Keep in mind that CWM is NOT compatible with all ROMs. Make sure the developer for your chosen ROM recommends it before installing it.
Does your method in opening post have to be run from external micro sdcard?
Both methods are performed with an external MicroSD card. They will work from internal also but it is a little more difficult to get the files in place if your tablet is not booting properly.
K J Rad said:
Both methods are performed with an external MicroSD card. They will work from internal also but it is a little more difficult to get the files in place if your tablet is not booting properly.
Click to expand...
Click to collapse
so your method is a simple way to replace one of the main uses of Clockword MOD?--Plus you stay stock more or less.
That is correct. Method II can also be modified to be less intrusive (leave user apps installed) or embedded into update scripts to perform a wipe during new ROM installs.
K J Rad said:
That is correct. Method II can also be modified to be less intrusive (leave user apps installed) or embedded into update scripts to perform a wipe during new ROM installs.
Click to expand...
Click to collapse
Wipe data does what--remove the apps installed?
And the partitions?
Your post is very interesting. It implies that you have a knowledge of the g-tabs partition structure. I have played with Linux off and on for the last 10+ years. When I began, I used Slackware and when you set it up you had to manually create partition tables using fdisk. You were only required to create two - the data partition and a swap partition but it was often recommended that you create several others - one to contain the home directory to prevent users from using all the disk space (in the days of small disks) for example. It appears that there are a lot of partition on the g-tab. Up to now, I have used various wiping tools like clockwork or calkulins wipe all on faith. I would really like to know what all the partitions are and what is in them. I have used terminal to get to the root folder and tried to do an fdisk to display the partitions but try as I might everything remains hidden. It would seem that a script like yours could be adapted to do many things but I would certainly want to understand the structure a little better before I did anything. I have searched and been unable to find that information. Can you point a way for the curious to learn more about the partition structure on the g-tab?
Wish I had a direction I could point you in. What I've found so far has mostly been stumbled upon while looking for something else. What I can tell you is this...
1) When using fdisk in Android you must specify the device to look at. Try something like: fdisk /dev/block/mccblk3 That should list the current partitions as defined by CWM or whatever was used originally.
2) Within one of those partitions in the list generated above are sub-partitions holding the bootloader, system, data, etc partitions. You can see how they're described in the .cfg files in the nvflash restores that are lying about.
lsu205 said:
Wipe data does what--remove the apps installed?
Click to expand...
Click to collapse
Removes user apps and their associated data as well as system related data and settings.
K J Rad - any idea if the partition size can be set with these methods (2048 & 0) in case I can't get clockwork installed?
CodeNamePapa said:
K J Rad - any idea if the partition size can be set with these methods (2048 & 0) in case I can't get clockwork installed?
Click to expand...
Click to collapse
I'm looking for a solution to that problem. Unfortunately these methods still require the ability to get into recovery mode which likely won't work if you're having trouble getting CWM installed.
If, however, you can get into recovery... then it is theoretically possible to create a script that would accomplish that. As soon as I have one I'll be adding it to the mix ;-)
Edit: I've found something I think will work. Will do some testing tonight. It will still require access to recovery.
I wasn't sure if you saw my other post but I am seeing no partition 0 when I NVFlash with a verifypartition.
http://forum.xda-developers.com/showpost.php?p=13059520&postcount=57
I haven't yet but I will. Let's try to keep this thread on topic. Thanks.
More thoughts:
because I went w/ cyan7 is it possible i have a "bad" kernel and that the stock bekit-1105 or the roebeet-3588 files are crashing w/ the kernel in place already?
I know custom ROMs can have a custom kernel applied separately, but I have no idea whether cyan7 loads it's own kernel...
I have yet to try the nvflash_gtablet_46 version, as I see the img files w/in are different from the original 1105 .zip
Also:
read on another thread that part 2 and part 3 aren't loading for other users when doing nvflash - I did notice that it pauses, runs some stuff, then starts loading part 4 through to the last part, then success. - do part 2 and 3 run for you?
edit: I see a 4349 downgrade.zip in another thread for those who got the OTA update but want to go back to stock 3588 prior to jumping off somewhere else - I can't expect that would help me as I can't do squat w/ recovery yet, but could that possibly "reset" any bad kernel problems? - again, I'm just thinking out loud.
This is well outside the scope of this thread but I find some of what you mention interesting so I'll address it and then end any further off topic discussions.
I did not build nor have I ever used Cyan7 so I have no basis for an opinion on the matter other than this... Each ROM comes with a kernel installed so if properly done an nvflash should overwrite any "bad" kernel.
Part2 and Part3 do indeed load, they are just displayed differently than the other Parts. Just minutes ago I flashed down from Mountain Laurel (4349 based with the new bootloader and recovery) with absolutely no trouble. I can, and have, read back those partitions after an nvflash to prove that point.
The 4349 downgrade will only work for you if recovery is working. Having never used it I don't know that it would "reset" the kernel but any subsequent flashing of a new ROM image would.
I am working on a stock recovery solution for partitioning but it isn't likely to help anyone who is stuck in an APX loop. I do have some ideas on what might help for that condition but I haven't been able to get my hands on one for testing and trying to help people here is like being a consulting mechanic for a car repair that's in someone else's shop having work done on it that you're not being told about.
I'll be happy to address any further comments or questions regarding your specific issue in an appropriate thread or via PM. Thanks.
Hi
I've done a bit of searching but can't find anything too specific to what I'm trying to do. Basically we have 10 Android tablets, and I want to make them all standardised e.g. have the same Apps on, configured in the same way (e.g. enterprise wireless network added).
Now the thing is if anyone messes around with them I want a really easy way to restore them to the original config which I've done.
One way I thought was to configure one fully, install Titanium Backup on it, do a full backup of apps/system data etc, and put the backup onto an SD card. Then I already have the base ROM on an SD card so if theres any problems, I can just flash the ROM over it again, install TB, and restore all the data. Would this be suitable to do to duplicate the data onto 10 tablets, and also restore the data if required?
The other thing I looked into was customising a ROM myself, don't want to do anything too tricky it'll just be a case of removing all the preinstalled crap I don't want, preloading the Apps we do want, and if possible preloading the wireless key and getting rid of the first boot initial set up wizard.
PS I've looked at installing CWM and doing whole image backups, but supposedly the tablet isnt supported (its an Ainol Novo 7 Elf 2)
Any advice would be great, hopefully theres some fairly straight forward way of managing this
Thanks
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
kuisma said:
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
Click to expand...
Click to collapse
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
fro5tie said:
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
Click to expand...
Click to collapse
Ok, I see. Compile the image to you likings (boot image and system partition), and then flash it using fastboot onto you devices.
Hi
Does anyone have any more thoughts on this?
I have experimented with Titanium Backup and this seems to work quite well. I have installed a ROM, and customised it e.g. installed the apps I need and configured the apps, wireless settings and home screens etc. Then I do a full apps + system backup in TB to my SD card.
Then the plan is, I can reflash the ROM onto the other device, install TB and then restore this backup. This saves my user state and wireless settings etc.
Only problems is when I flash the ROM, I have to go through all the initial set up again and also remove some preinstalled apps which I dont want. Any ways around this?
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
kuisma said:
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
Click to expand...
Click to collapse
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
fro5tie said:
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
Click to expand...
Click to collapse
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
kuisma said:
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
Click to expand...
Click to collapse
Hi
Thanks for the quick reply, much appreciated.
Unfortunately you've lost me a bit here!
Yes the device is rooted, I dont have a linux machine though.
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
fro5tie said:
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
Click to expand...
Click to collapse
I can provide you specific answers to specific questions, but I have no experience of the tablet in question, so you'll have to do some digging yourself first. Make sure it supports fastboot, investigate what the proprietary bootloader is capable of, see how/if you can obtain an original image etc.
One maybe easier solution, especially if you plan to restore the tablets on a regular basis, is to only make a new boot image to reflash the devices with. The only modification done is that you change the /init.rc script to mount /data and /system from the SDcard instead of from the internal nand disk device.
Once this is done, you'll power up and run the installation wizard and everything on your master tablet. Then power it down, and clone the SDcard. This SDcard now contains everything, so you'll simply restore a device by replacing its SDcard with a copy of this master card. I guess it's easier to clone a SDcard than reflashing several internal partitions. Easier to make the master as well - you don't need to dd or tar them, they are already in "image" format. If you can get hold of the original firmware, this should be quite easy without the need to preserving data from the device itself.
fro5tie said:
Any chance you'd be able to provide some more specific instructions?
Click to expand...
Click to collapse
Issue the commands "cat /proc/mtd" and "mount" on your device at command prompt (e.g. via "adb shell" or the "ConnectBot" terminal app). This shows you if the device allows you to copy the boot image from it. Paste in the output into this thread. If you believe the "clone the tablet via the SDcard" is a good solution for you, the process is in short terms something as below;
Copy the boot image to the sdcard:
# dd if=/dev/mtd/mtd2ro of=/mnt/sdcard/boot.img bs=2048 (device dependent of contents of /proc/mtd)
Remove the sdcard, insert into a computer, split the boot image info kernel + initramfs. Read http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images for instructions about how to work with the boot.img file. I really recommend a GNU/Linux environment for this.
Then edit /init.rc replacing the "mount yaffs2 [email protected] /system" with "mount ext3 /dev/block/mmcblk0p2 /system" for system and data (use p3 for data partition, the device name may be different on your tablet, see mount output).
Create an SDcard with three partitions: #1 vfat (standard), #2 and #3 ext3. Insert into you device and boot it up again.
# mount -t ext3 /dev/block/mmcblk0p2 /root
# cd /system
# tar cf - . | (cd /root ; tar xf - )
# umount /root
# mount -t ext3 /dev/block/mmcblk0p3 /root
# cd /data
# tar cf - . | (cd /root ; tar xf - )
# umount /root
This copies your partitions to the SDcard. Shutdown the tablet again.
Make a new boot.img using the instructions in the link above, using the edited init.rc script.
Now you can non-destrutive give this a try.
Place you tablet in fastboot mode (often vol-up (or vol-down) during power on).
$ fastboot devices
This vill verify the tablet is in fastboot mode. It should be listed. Then:
$ fastboot boot boot.img
Note here, only BOOT the tablet, do NOT use the "flash" keyword. This in case of the image isn't working, you'll just have to restart you tablet, and no harm's done.
Look around. Do a "mount" command. Everything works? Mount shows /data and /system from sdcard? Perfect. Now you can reflash it. Shutdown and flash:
$ fastboot flash boot boot.img
Now the device will use /data and /system from the SDcard every time. Customize your device, and then clone your SDcard and try it in tablet #2 you'll booting with your new boot.img and the cloned SDcard. Verify that #tablet #2 is a perfect clone of tablet #1. It is? Now you can flash the boot,img into all your tablets.
--------------------
But don't forget, there may be other solutions as well, maybe more suitable. This you'll have to investigate yourself.
And the usual disclaimer - you can probably not follow above by the letter. There sure is some obstacle you'll have to overcome, something non-standard, etc.
Also keep the original boot.img file for safekeeping in the case you want to restore the device's boot image some day.
Wow! Thanks for the info! This is really helpful, I need to set aside a bit of time to work through this and have a look. Thanks again its really appreciated, I'll be back with info once I've had chance to give it a go!
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
tweeny80 said:
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
Click to expand...
Click to collapse
Hi
Yes that was my first thought as well, tablets are rooted yes but there is no CWM for the tablet. Its an obscure Chinese branded tablet.
Unless there is another way to do nandroid backups?
hmm tricky situation. Catch 22 ! From what I know, your best bet is to backup all possible things through Titanium Backup given that you don't have the use of Nandroid backups. You can include wifi settings, messages etc but it's modular & not systemic.
I did a quick google search with no luck - time to upgrade your fleet dude :-0
Best of luck.
I would like to know what will happend if i will flash the rainbowmod 2.1 rom on my Lumia 800 with the One key flashing tool.
Does it work ? or it is necessary to flash the partition 3 files under linux.
It would be easyer for me to do it under windows; not having eny experience with ubuntu.
As it says on the rainbowmod instructions;
Before flashing this custom ROM you must flash this file to sdb3 partition (thx biktor_gj)
Thank you,
Hi there,
as far as i know, RainboMod 2.1 will only work with updated files on partition 3.
The actual files for partition 3 (in the first post) are not up-to-date and will only work for RainbowMod 2.0.1.
We still have to wait until lucifer puts his 2.1 version back online, with the updated files for partition 3 i posted on page 12 of the thread.
For now, you can only use 2.0.1 version.
You can try if the rom works, if you only flash partition 9 using nokia lumia downloader in windows.
If it does not work, you have to flash the files of partition 3, which can only be done in linux.
It's very simple, i can help you when you need help.
cheers
help needed
Hello,
So i would gladly use your help,
I just finished installing ubuntu.
As i understand the procedure should be the same for my lumia800 as in these instructions for the lumia 700.
http://forum.xda-developers.com/showthread.php?t=1626317 (100%noob instructions). Am i right?
only thing missing there is the 3rd partition instructions, but if im not wrong the commands should be the same, only have to flash the 3rd partition.Yes?
(6.4: Now using the partition we obtained in step 4 (In my case: sdc9) use this command to flash your phone with the unlocked firmware:
Code:
dd if=os-new.nb of=/dev/sdX9
Replace X with your partition letter (In my case it's c)
so in my case I would enter:
Code:
dd if=os-new.nb of=/dev/sdc9)
Thanks in advance Lordmaxey
hi there,
yes, first, check your drive letter using
sudo fdisk -l
this will show you if your phone is sda, sdb, sdc etc...
for flashing partition 3 it's the same as flashing partition 9 ( dd if=os-new.nb of=/dev/sdc9 )
of course you have to replace 9 with 3 and the input file (if), so it will be: dd if=partition_3_file of=/dev/sdc3
cheers
CAUTION:
Before flashing anything i strongly recommend you backing up every single partition.
eg. sudo dd if=/etc/sdX1 of=backup_partition_1
sudo dd if=/etc/sdX2 of=backup_partition_2
...
repeat for every drive letter
...
sudo dd if=/etc/sdX9 of=backup_partition_9
Thank you lordmaxey,,
i will try..
Done,,
Feeling good.
Thank you again lordmaxey.
So now i checked around a little bit, and i like it allot, especially file explorer, what i was missing . Only one app what i miss is the nokia drive,
i used it allot. Is it possible to deploy this or is this complicated.
whitenegga said:
Done,,
Feeling good.
Thank you again lordmaxey.
So now i checked around a little bit, and i like it allot, especially file explorer, what i was missing . Only one app what i miss is the nokia drive,
i used it allot. Is it possible to deploy this or is this complicated.
Click to expand...
Click to collapse
No worries, you're welcome
You're missing Nokia Drive? Then simply install it via Marketplace
cheers
Ok tried that,but incountered a small problemo, live id key.
searched the forum for eny useful information, . Found some, but aint very shore, how to obtain the live id key asked by microsoft.
so if you have some useful informatipn, i would appreciate it,
hope i wont bother you after this, at least for a while,
Tnx Lmaxey,
did you make a backup of all partitions as i recommended?
if yes, you can use DPPImplant to "extract" your activation code from your backup file.
you'll find dppimplant here: http://forum.xda-developers.com/showpost.php?p=25126572&postcount=642
no worries, that's what we're here for: helping
So i have to tell you the whole story. (you can laugh on my stupidity, no harm don )
Wanted to unlock my lumia by TP. So i ordered the atf box, cables and everything. Not beeing the best solderer in the world i managed to destroy a resistor, but fortunatly the phone still works(only not giving the tp connection). Im no quitter , so i bought a used phone with a brocken LCD.
So now;
1. i have my old phone with DLOAD where should be my Live ID. (is it possible to exctract the key under linux from dload?)
2. And the TP unlocked used phone what i flashed with some old rom, dowloaded when i was searching information about the TP unlock .
After that i managed to flash the rainbowmod by your help.
And yes , i didnt make partition backups,
because I THOUGHT :good: that if i allready flashed it with the older rom , this live id info would be owerwritten.
so it wouldn be eny use for me to backup a custom rom partitions.
And maybe this used phone had somebody elses ID, what i couldnt have used enyway.
This all has to happend to me.
what are my chances?
Wow... holy sh**
whitenegga said:
And yes , i didnt make partition backups,
because I THOUGHT :good: that if i allready flashed it with the older rom , this live id info would be owerwritten.
so it wouldn be eny use for me to backup a custom rom partitions.
And maybe this used phone had somebody elses ID, what i couldnt have used enyway.
Click to expand...
Click to collapse
Yes, the live ID was overwritten anyway, so you're right
Of course i didn't know this situation, that's why i told you to make a backup.
What you can do now:
- TP unlock your resistor-broken DLOAD Lumia, backup and do the DppImplant thing i posted above
- use the avtivation code posted in this thread: http://forum.xda-developers.com/showpost.php?p=32700983&postcount=7
but note: this is not your activation code, so i don't know what happens if you're using it.
hello again
I'm back,
Succeeded with everything. Most of it thanks to you lordmaxey.
So now I have another question.
As it is all new to me, can you explane to me how to use the wm device center to connect it with PC.
So I could see the folders in my computer.
Thx.
whitenegga said:
I'm back,
Succeeded with everything. Most of it thanks to you lordmaxey.
So now I have another question.
As it is all new to me, can you explane to me how to use the wm device center to connect it with PC.
So I could see the folders in my computer.
Thx.
Click to expand...
Click to collapse
Yeah, sure
you have to install Wmdc on your pc, and you have to install the wmdc launcher on your phone.
- then open the application on your phone, select "launch" (click launch to run windows mobile device center phone client)
- then swipe right and selcet all 3 boxes (start wmdc automatically, start debugger automatically, use vs debugger from pc)
- connect your phone to your pc
if wmdc is not starting automatically on your pc, open it.
you should now see your phone.
strange, its not connecting.
I have tried with the zune running in the background, and viceversa.
Allso in the device manager it shows prtable devices-lumia 800 ---This device is working properly.
Eny ideas,
All the best,
We are a large urban school district located in southern California that will be soon be distributing approximately 11,000 android tablets to our first grade classrooms. The biggest challenge we’ve had with this project so far is coming up with a way to quickly and reliably clone the devices with all the apps and settings. The approach we’ve been attempting to take is the same as how we would handle PC’s by creating a master image that then gets copied to all the other devices.
Our first attempt at doing this was by using adb backup/restore. This process was less than ideal as it didn’t copy all the settings/preferences that we wanted and still required a lot of manual configuration to get the devices in to our ideal state. The bigger problem we had here was that sometimes it would just hang during the restore. Most of the time it did work but we’ve run in to this restore problem enough that we need something more reliable.
So our current cloning method is using Clockworkmod Recovery. Basically we flash CWM on to the device, make our backup, copy that backup to the destination devices and restore it with CWM. Seems to work great. And it copies everything on the devices so there’s virtually no manual configuration that needs to be done.
However there’s a few caveats with this process. At first we found that it was also cloning the MAC address which of course caused havoc on our wireless network. Through a whole lot of trial and error I found that if I delete /data/nvram/RestoreFlag from the data backup tar the MAC address no longer gets cloned. Thought we were good, but…
The next problem we found when attempting to enroll the devices in to our MDM system. They end up replacing each other because they all show the same UDID and GUID. The MDM app is installed in the backup image but we are waiting until after it is restored to complete the enrollment. I’m not sure if the UDID and GUID is something specific to the MDM or if that’s a global Android thing.
So does anyone know if there something else I can delete from the backup to prevent this? This also raises the question, are there any other items in a CWM backup that should not be copied between devices? Or is there a better method we could use to clones the devices?
The device we are currently using is a Lenovo A1000 (MTK MT8317). After creating the backup I’ve been removing the system and cache tars entirely and only the file mentioned above from within the data tar. So the only parts that get restored are data and boot. Any suggestions are welcome.
ttttttttttttttttt said:
We are a large urban school district located in southern California that will be soon be distributing approximately 11,000 android tablets to our first grade classrooms. The biggest challenge we’ve had with this project so far is coming up with a way to quickly and reliably clone the devices with all the apps and settings. The approach we’ve been attempting to take is the same as how we would handle PC’s by creating a master image that then gets copied to all the other devices.
Our first attempt at doing this was by using adb backup/restore. This process was less than ideal as it didn’t copy all the settings/preferences that we wanted and still required a lot of manual configuration to get the devices in to our ideal state. The bigger problem we had here was that sometimes it would just hang during the restore. Most of the time it did work but we’ve run in to this restore problem enough that we need something more reliable.
So our current cloning method is using Clockworkmod Recovery. Basically we flash CWM on to the device, make our backup, copy that backup to the destination devices and restore it with CWM. Seems to work great. And it copies everything on the devices so there’s virtually no manual configuration that needs to be done.
However there’s a few caveats with this process. At first we found that it was also cloning the MAC address which of course caused havoc on our wireless network. Through a whole lot of trial and error I found that if I delete /data/nvram/RestoreFlag from the data backup tar the MAC address no longer gets cloned. Thought we were good, but…
The next problem we found when attempting to enroll the devices in to our MDM system. They end up replacing each other because they all show the same UDID and GUID. The MDM app is installed in the backup image but we are waiting until after it is restored to complete the enrollment. I’m not sure if the UDID and GUID is something specific to the MDM or if that’s a global Android thing.
So does anyone know if there something else I can delete from the backup to prevent this? This also raises the question, are there any other items in a CWM backup that should not be copied between devices? Or is there a better method we could use to clones the devices?
The device we are currently using is a Lenovo A1000 (MTK MT8317). After creating the backup I’ve been removing the system and cache tars entirely and only the file mentioned above from within the data tar. So the only parts that get restored are data and boot. Any suggestions are welcome.
Click to expand...
Click to collapse
You can try use adb from Android SDK but this method needs root
We did initially try adb but it was inconsistent during the restore phase. Sometimes it would just stop in the middle and never complete. Didn’t try it on a rooted device. So maybe that would have helped…
Anyhow I found the solution to my immediate problem. Figured out what our MDM vendor refers to as the UDID is really the Android_ID. So by deleting that row from the settings database in our master backup image it’ll generate a new one the first time the OS starts after restoring with CWM.
I’m still a little concerned we’re going to find other issues cause by this cloning method later on but I guess we’ll just have to roll with the punches as they come.
In case someone else ever needs to clone devices like this and in the interest of sharing here’s the basic steps we’re following.
1.) Setup the master device as you like with all the apps and settings.
2.) Install Clockworkmod Recovery on to the master device
3.) Boot into CWM Recovery
4.) Mount /data and connect to adb
5.) Delete /data/nvram/RestoreFlag (this step prevents duplication of MAC address)
6.) Using sqlite open the database (this prevents duplication of Android_ID): \data\data\com.android.providers.settings\databases\settings.db
execute: delete from secure where name='android_id';
7.) unmount /data
8.) Create a backup
9.) Boot the device back in to normal mode and copy the clockworkmod folder to your computer. This the backup image you’ll restore on the other devices.
10.) [OPTIONAL] I deleted the system and cache backup files from this folder and also removed them from the nandroid file. There didn’t seem to be anything in these we cared about so removing those speeds up the restore process.
Once you have the backup image here’s how to restore it on the other devices:
1.) Install CWM Recovery
2.) Copy the clockworkmod folder from your computer on to the device
3.) Boot in to CWM Recovery
4.) Restore the backup
5.) Reboot the device back in to normal mode
6.) [OPTIONAL] Complete MDM enrollment
Sorry for the thread grave dig, but thanks for posting info on how to do this. I have attempted cloning in the past and ran into similar issues. My question - is this process the same for Android Lollipop 5.0/5.1? I have some Lenovo K3 Notes I'd like to deploy and cloning would save a lot of time.
Haven’t had the need to do any devices running 5.x versions so can’t say for sure. I would imagine a similar process would work.
But I will provide a bit of an update. Our initial deployment of 11,000 Lenovo A1000 devices have been out in the field since February/March of 2014 and no trouble has come to light using this cloning method. These devices run 4.1.2
Sometime around May 2014 we did another round that was about 300 Lenovo A3000 devices. Don’t have one of these handy and I don’t remember the exact Android version but it was 4.x something.
Then starting in October 2014 we put out another 9000 or so Lenovo A3500 devices. These run 4.4.2
All around so far so good.
For the A3000 and A3500 there were two changes to the process. For step 5 in creating the backup I had to clear the entire nvram directory instead of just the one file. I don’t remember what exactly but there was something undesirable getting copied over. The result of clearing this directory is the first boot after the restore takes a little longer as each app runs through the “update” process at startup. The second change was I could not get CWM to backup and restore to/from the internal memory so instead did it from a micro-sd card. This ended up speeding up the restore process since we didn’t have to copy the backup to each device and instead just moved the sd card with the files already there.
this should be pinned in android dev
also sorry for grave digging? except this should be a maintained topic. why isnt this an ongoing thread?
WARNING - THESE TOOLS WRITE TO THE DEVICE PARTITIONS DIRECTLY
If you don't know what that means...
THIS CAN REALLY SCREW UP YOUR ---
I HAVE ONLY TESTED THESE ON THE A2020U (NON-5G) - I CANNOT SAY THEY ARE SAFE ON ANY OTHER VERSION OF THE PHONE (YET)(If you want to test it on a specific model you own, send a PM or post and I can tell you to run a few (safe) things from these tools to make them compatible your phone.)
See my next post down for some more "beginner friendly" general tips and tricks for this phone, including some fixes for common problems and a quick guide for installing Magisk!
If you can't afford to brick your phone, these tools aren't made for you.
There aren't really any protections from doing damage. I made them for myself because doing them on a command line constantly is a pain. I'm just sharing them for two reasons:
1) So myself or other people have tools available to make it easier when advising someone on how to fix their phone.
2) For tinkerers who are okay taking the risk that they'll mess something up.
Thanks to @djkuz / @Unjustified Dev for the EDL tool. These scripts really just expand the use of fh_loader commands in that tool. If you are able to read C++ and want to understand fh_loader I suggest searching on google, the source code is available and from that you can better understand what the tool does / what the command line options do. Feel free to ask here too, I'll do my best to share what I know.
Anyway - below I'll go into plenty of detail of what each "tool" does and some helpful information about using them.
I write in a kind of permanent verbose mode, so if you're impatient and need a TL;DR for these... tough. =)
CURRENT VERSION: Version 1.1d
Changelog:
Version 1.1d:
- Fixed reset scripts
Version 1.1c:
- Fixed a typo in backup_GPT ¯\_(ツ)_/¯
Version 1.1b:
- Fixed errors in GPT_Tools - apparently these existed since v1.0 DO NOT USE PREVIOUS VERSIONS
- Removed the v1.1a download (use 1.1b)
Version 1.1a:
- Added script to find the COM port automatically
- Updated all scripts to use the COM port in the file COMPort (created by the above script)
- Added the missing AB Partition manipulation files (accidentally left out of v1.0)
- Added script to run the phone reset EDL command
- Fixed all the filename inconsistency in the XML files - HOPEFULLY. Please post any errors you find. Unfortunately this will make this version incompatible with v1.0 backups without some work - either rename your backup files to match the new format or use the old XML files included.
-- Especially fixed the XML typo of "uefi_sec.mbn" being backed up from both A and B to the same file (overwriting the A copy with B during an ALL backup).
- Added support for installing firmware packages created for this tool. Put them in the Firmware_Package_Restore directory and use the scripts included with them.
Basic Instructions:
1) Download zip (See attachment at the bottom, or here - Download from AndroidFileHost)
2) Unpack zip
3) Move folder to the root directory, or inside any chain of directories that do NOT have spaces in any of the names
4) Right-click on scripts and select "Run with Powershell" to run
5) If running scripts fails due to permissions, see these instructions: https://superuser.com/questions/106360/how-to-enable-execution-of-powershell-scripts
Make a "Complete Backup" (minus userdata):
1) Run Load Programmer
2) Run "backup_all"
3) Check the backup directory and verify the files were backed up and sizes make sense - a full backup should be 10,387,202,048 bytes / 39 files for the critical files and 1,626,697,728 bytes / 64 files for the non-critical (Don't include the port_trace log file when checking size)
Note: You will see a lot of "warnings" before the files begin to download, the program checking if the files already exist.
How to Use These Tools:
Important:
When the scripts run there will be a lot of information dumped to the console. It's not necessary to read all of that BUT - IF YOU DO NOT SEE THE ASCII ART "DONE" AT THE END of running any of these scripts it is likely the script encountered a serious issue. "WARNING" art is normal for some scripts, but "ERROR" means something went wrong.
None of these find the COM port automatically. It is possible (the EDL tool does) but it's just extra work I'm not paid to do =P
You will need to edit each program and change the variable at the top (usually $COMPort = "6") to whatever port number your phone shows up on.
Sorry that's inconvenient, but it should just be once per script - my port number never changes so it wasn't worth implementing automatic port finding.
This is no longer needed after v1.1a.
1. Load Programmer
This is a simple but extremely important tool! You need to run this before running anything else. This script will open a window that runs a command to open a connection to the phone (when it is in EDL / "9008" mode). The window will stay open until you close it. When working on backups I often need to re-connect the programmer, so this makes that easy - just alt-tab to it and hit enter. If you look at the script, it's fairly straightforward - just read the instructions on the screen after running it. The "secret sauce" for this is really the firehose protocol for our chipset that Unjustified Dev provided in the EDL tool.
2. Backup / Restore:
backup_all: This will backup everything on the phone EXCEPT for the huge userdata partition. It will create a backup in two directories, which I'll explain.."critical" / "non-critical": You can see that I have scripts to run these two "types" of backups. Non-critical DOES NOT MEAN NOT IMPORTANT. It means that it is not critical TO ME to back up those files EVERY time I do a backup, because they rarely change. They're EXTREMELY important to have at least one backup of for your phone. The "critical" backup files are files that change often, although some of them are extreme non-critical (cache for example). Use a different name than "critical" if you like, but the point is that only with BOTH backups run (which is what backup_all does) will you have a complete backup.restore_all: This will restore a full (both critical and non-critical) backup set. The backup files have to be in the "restore_critical" and "restore_non-critical" directories respectively. If you didn't make the backup you're trying to restore with this tool CHECK THE FILENAMES, e.g. if you used Unjustified's EDL tool you have to rename the "abl.elf" file his backup generates to "abl_a.elf" for mine. I put _a and _b on every partition that has an a/b version because I got tired of getting them confused. Of course you can always install a backup to either slot.Files moved to the "restore_" directories won't be changed at all by the restore process so you can cut/paste the files from your backup into the directory instead of copying them.
3. A/B Partition Manipulation
These are no more complicated than the backup/restore tools. But they are written to make manipulations of the A/B partitions easier.My main use for these is when I know I have a good, working ROM setup on slot A, I run A2B copy. Then no matter which slot I end up booting I'm sure it will work. (That is, if you have a working, booting slot, copying all the files from that slot to the other slot using this tool will make both slots the same.)Backup/Copy:run_AB-partition-backup: As it says, it will backup both the A/B partition files - WARNING this is NOT a full backup of the phone.run_AB-partition-swap: This will backup all the A/B partition files, then it will write the B files to A and A to B, effectively swapping the partitions and leaving you with a backup in case it screwed up. This backup is ONLY OF THE A/B FILES.. NOT the whole device!run_A2B-partition-copy (and run_B2A-partition-copy): These will do a backup of both A/B partition files, then write the A partition onto the B partition (A2B) or vice versa (B2A), effectively mirroring that partition.
Write/Restore:All the restore scripts try to find their files in the "restore_Partitions" directory - place the files from one of the backups to be restored there.restore_AB-partition-backup: Restore a backup of both the A and B partition files.restore_A-partition-backup (and B): Restore just the backup of one partition to the same partition it was taken from (A to A and B to B).restore_A2B-partition-backup (and B2A): These write from one partition backup to the other partition as the name suggests.
4. GPT Tools
These are some basic tools to directly interact with the partition tables - these are not going to be of any use to 99% of people, so just ignore them if you don't know what they do.run_fixGPT: This issues the --fixgpt command to each of the LUNs. USE AT YOUR OWN RISK. As I understand it, this will use the onboard device configuration information from each LUN (e.g. logical size) and try to rebuild the GPTs. It's similar to running patch XMLs, it can clean up flashing messes. It isn't magic and won't fix everything.Rarely will anyone need it unless they've been messing around with the flash tools recklessly... I certainly don't know anyone who would do something that dumb backup_GPT: Backup all of the header and footer (main/backup) GPTs for all the partitions (lun 0-5). I am not aware of whether any other models of the phone have more LUNs, so be careful if you're using this on a non A2020U phone.restore_GPT: Simply write an entire GPT backup set (both main and backup 0-5) onto the phone. The backups must be in the restore_GPT folder. This DOES NOT BACKUP before it runs so make sure you did your backup.
6. Set Bootable Partition:
Alright this one is important for everyone. There are two scripts here - one for slot A and one for slot B. These just run a simple command, but they will fix a common problem I (and probably others) have - when the ROM active-slot information does NOT match the partition (hard drive) bootable flag, the phone will bootloop EVEN THOUGH EVERYTHING IS GOOD.So when you flash an EDL backup (depending on which files you flash, I believe this happens because of either the bootloader or the GPT files) there is a chance the backup you're flashing was originally from a different slot than the one you're restoring it to. The config thinks it should be on slot A while the hardware thinks slot B should be booting.This will result in a fast ~3 second bootloop as the two disagree and reset.This tool changes which partition is expecting to boot - "1" for slot A and "2" for slot B.This does NOT change the active slot - the phone will continue to boot the same slot it's trying to boot. You just need to make the partition that it is trying to boot has a bootable flag.AFAIK there is no way to change the active slot (the one XBL (I think) is trying to boot), except through fastboot or when the phone fails to load the OS 8 times in a row (note - if it fail to load the OS - if the phone bootloops before "boot" is called it won't ever switch slots on its own).This was a common cause of fast bootloops for me before I figured this fix out.
It does no harm to try this as you can always switch again. If neither one works for you, then it's something wrong with the files you're flashing. If you know which slot the phone is trying to boot (the one it was on last), run the script that matches that slot.
7. Write "Unlocked" Bootloader and FRP:
Just like the original EDL tool, these very simply overwrite your existing (probably stock) bootloader (abl) files with the fastboot enabled version, and/or your FRP with the "unlocked" flag on (see description below). This will allow you to enter the bootloader menu (Vol+/- on booting) and use fastboot to unlock the bootloader.backup_FRP-and-bootloaders: As it says, this will make backups of both the FRP file and current bootloader files (ABLs).run_all: Literally just runs both of the below scripts *shrug*write_UD-bootloader: This automatically backs up both your existing A/B bootloaders before overwriting them (BOTH) with the unlocked/fastboot bootloader.WARNING - an unfortunate fact is that if you're using the stock ROM and you have this bootloader installed, it borks the USB mode so it's stuck in charge only. There's a way to fix it temporarily, I'll post it in my "tips" thread, but you have to do it every time you boot, very annoying. I can't fix it permanently because I don't know how the bootloader file was built!WARNING 2 - Android 10 will NOT BOOT with this bootloader installed. You can still install it, trying to boot will bootloop, but you can get into the bootloader menu and use fastboot - but there are no recoveries I know of that work with Android 10 right now, so there's very limited use to having fastboot right now. Hopefully we can get a port of TWRP 3.4 going for this phone..write_unlock-frp: This is also in the EDL tool, but maybe poorly explained - the FRP file holds the flag you change in the OS Developer Options to designate "allow bootloader unlock". If you FORGOT to switch that flag on and unlock, as I understand it, you get bootlooped. This can fix that for you without having to go through all the work of undoing that mess.WARNING - I have only tested this with a brand new factory reset OS WITHOUT any fingerprint/code set. It may not work if you set one. I warn against using this if you are not ready to lose your data. It's convenient if you just forgot, but if you set a pattern/fingerprint security and encrypted the filesystem overwriting the FRP might remove your ability to decrypt which would force you to factory reset. Again, I haven't tested it for that so it may work, but be careful.If you already screwed up and ran this to set the flag - the script runs a quick backup of your old FRP just in case. So you can try to restore that FRP and pray lol)
8. Specific Files:
This is just a generic program to backup/write(restore) "specific files".I include a "Reference.XML" which has a full <program> line for every partition you might want to write/read on the phone. To use this, you need to copy the lines from the reference XML into "rawprogram-specific-files.xml" for the files you want to read/write.As an example I already set up "rawprogram-specific-files.xml" with the two lines for "abl_a" and "abl_b" in it. So the script will backup or restore those files (provided you put the abl's you want to restore in the restore_files directory).I personally use this template a lot - I have one for ABLs, one for AOPs, one for BOOTs, and so on. If you are trying to fix a specific file(s) it's convenient.
9. Userdata Backup:
I put this last because, to be honest, I'm not sure how good of an idea including this even is.VERY IMPORTANT - DO NOT USE THIS USERDATA TOOL IF YOUR PHONE IS NOT THE 256GB VERSION!!!!!I will need someone with the 128GB version to send me their GPT files if they want me to make an XML that works for them. Because the userdata size for SURE depends on your phone version.Also, I wrote a script that breaks up the file into download slices (and can be written back to the phone in slices, of course) - one, to see if I could do it and if it would work (it does)... and two, so that in the horrible case that something goes wrong during the... nearly 2hrs of transfer time, for my 256gb image ... that I can at least not have to start all over. If something happens, you should be able to remove the entries in the XML for what you already have and start again.Finally - is it even worth doing? Is backing up the userdata even useful?I don't know yet.For an unecrypted pre-A10 phone I do know it works to fully flash ALL the files on the phone + the userdata all at the same time to return the phone to the exact "state" it was backed up in - all the apps and settings and everything, exactly as they were.But A10 is encryption enabled always, and it uses file encryption which sounds even worse for this idea.. and I don't know if the crypto keys change and when. So flashing an entire encrypted partition might just leave you unable to decrypt all, some, or none and you lose everything.OR it might just work - you throw the whole image on there and the decrypt key is the same, boom, easy backup.If anyone tries it, let me know how it goes (or doesn't). I'll update with any results I find.Update 1: I have confirmed that for the 256gb A2020U backing up the full phone and userdata allows you to restore the phone to that exact state. Doesn't matter if it's encrypted, password set or not, etc. If you backup the entire userdata image and reflash it that is where the phone will be. In most cases you also need all the other partitions too, but if they have not changed they don't have to be reflashed. (I confirmed going from encrypted with password -> encrypted with no password -> back up encrypted with password.. This is on Android 10 with its more complicated encryption).Another nice thing to note - of course the image of the phone will be the size of the partition (ie. 256gb for mine, 128gb for others). But if your phone storage is largely empty, you compress the backup using something like 7z once the image has been backed up. It won't take up so much space then. How much less? My 256gb image compressed is 4.5gb. lol.... it makes sense, the phone is new and there's basically no information on the userdata. Many of the pieces of my userdata backup have the same exacty hashes - meaning they are literally just all 0's... 260gb of zeros. Unfortunately you can't get away with just backing up part of the image as data could be anywhere. And over time as the sectors get written to, it will get more difficult to compress.Anyway, if anyone has a 128GB version they want to donate to science (kidding - I just need backups of the GPT) I can make the XML file to use for backing those up too.
Extra Note: All the programs automatically build a log of the console window, so if something goes by too fast just check the log. The fh_loader also creates a log and dumps it somewhat randomly about... lol.. the filename is port_trace.txt. This tends to get deleted and overwritten easily so if you want to keep it, move it when the script finishes,. it does often contain more information than the console shows - it can be useful understanding what's going on.
Extra Note 2: You'll notice a script "Create Hash List" in practically every directory. That's to strongly hint that using that script is super useful. All the files backed up through these tools, by definition, have the exact same size. If you hash your files though, you can tell if they have changed at all. This is extremely useful in troubleshooting problems.
How to install an EDL firmware package:
Note: This tool is specifically made for the firmware packages I posted. It won't work with any other package (although it can, with a little work).
1. Install the EDL tools
2. Run a backup of your phone! Even if it isn't booting.
3. Download a firmware package from this thread: [ROM][STOCK] Stock Firmware Packages (For Expanded EDL Tools)
4. Unpack the firmware archive into the tool directory "Firmware_Package_Restore"
5. Put phone in EDL mode and run Load Programmer
6. Run whichever "Write Firmware vX to Y.ps1" you want (X = firmware version, Y = A or B partition) (If you don't know which partition is currently booting, just install both.)
7. Wait for the install to finish ("done"), then reset the phone with either the power button or the reset tool
8. You might see a few bootloops and then the phone ask you to do a factory reset / system wipe.
9. Done.
PLEASE POST IN THE FIRMWARE THREAD _NOT HERE_ IF YOU RUN INTO ANY ISSUES!
Enjoy!
Also, while I'm here... some other helpful notes for this phone:
-------------------------------
General Information:
As of right now there are a lot of working options for Android 9 and quickly expanding thanks to work @Unjustified Dev did and work @rafyvitto is continuing to do! Check out some of his sGSI ROMs, lots of options!
Thanks to Unjustified LOS 16 is available for Android 9 also, and is the base install for most ROMs. See his threads for that. I may write up an install guide here that's a little more in depth than his.. not today though.
Upgrading to Android 10 with the bootloader unlocked is possible but requires a workaround:
You must unlock on Android 9 then use recovery to side-load the Android 10 update available from ZTE USA (HERE).
This will remove the fastboot enabled bootloader and requires a complete system wipe.
You will retain bootloader unlock.
Once you have updated to A10 you can run OTA updates to get up to the latest version.
Downsides to A10 include - NO RECOVERY (yet), NO CUSTOM ROMs (yet), and if you flash the fastboot enabled bootloader you CAN use fastboot, but you cannot boot- the phone will be in a bootloop until you restore the stock A10 bootloader.
-------------------------------
Resetting the phone manually:
In EDL Loop - Hold power for 20 seconds
In EDL Not-Looped - Hold power for 5 seconds
In System (booted after ZTE logo) - Hold power for 10 seconds
----------------------------------
Entering Modes:
All of these start by using reset above, THEN the button(s) below - in all except one case (EDL), when the phone resets it will vibrate and then show the blue ZTE logo.
When you feel the vibration you want to immediately release the power button and press the mode buttons.
This can be confusing and tricky - most people say "hold power + button" - that is incorrect. Most cases if you hold any button other than power the phone will not finish resetting until you release that button.
What you want to do is right before or as the phone vibrates, then you hold the button. Once the ZTE screen is up it is probably too late if you missed it. So hold power for your reset and be ready to push the button you want when you feel the vibration.
The one exception - EDL mode. For EDL mode you can (and must) hold the key combo just before/during the restart.
Recovery Mode: Vol+ Button
Factory Test Mode: Vol- Button
Bootloader/Fastboot Mode: Vol+/- Button (both) when phone is NOT plugged into USB (if you are too early pressing the combo, even with the USB unplugged, you will get EDL mode)
Emergency Download Mode: Vol+/- Button (both) when phone IS plugged into USB
--------------------------------
EDL Flash Errors (esp. when EDL looped):
There is NO indication the phone is even ON when you are EDL stuck/looped. Other than when you plug into the computer with the right drivers it shows up as a 9008 device (9008 mode is EDL for Qualcomm).
Even when you can see the phone on your computer, it can often "freeze" in EDL if it is left idle for too long (not connected to and being used by a Sahara programmer).
If you try the EDL tool or another flash tool and they give you errors related to the Sahara programmer not loading or no "hello", do this:
Reset the phone - use a clock to count if you need, has to be accurate since there's no indication of when it resets. Press down Vol+/- and the power button, count to 20sec, then release JUST the power button. Keep holding both of the volumes for another 5 sec, then release them. That will get you back into a fresh EDL. You can watch your Device Manager to see the phone disconnect as an indicator when to let go of the power button. If you mess up the timing, wait a bit before trying again so the phone isn't in the middle of rebooting.
Easiest way to tell if you're in EDL is to watch the Device Manager while you do it. Otherwise there is just a lot of guess work, since there's no logo or vibration when you get it right, phone just appears off.
--------------------------------
USB Mode Stuck After Unlocking:
Something about the fastboot/"unlocked" bootloader causes the USB mode when you boot in the OS to be stuck on "Charge Only" mode.
Luckily I found @meow sir 's comment tucked away in this thread, and he knew a way to fix it (thanks!):
1. Open the phone dialer
2. Dial in "*#*#DEBUG#*#*" (debug = 33284)
(Sometimes takes a little bit to open, but a debugger menu will open)
3. Select the 2nd option for USB
4. Pick the only option - this will unset some strange "testing" mode and you can use MPT again.
Unfortunately this fix doesn't stick, you have to do it every time unless you switch back to the stock ABL. =(
--------------------------------
Installing Magisk, Quick Guide:
- You must have your bootloader unlocked already! This works on both A9 and A10.
1. Use this tool to create a full backup! (backup_all)
2. Go into the "critical" directory created by the backup and find the files for boot_a.img and boot_b.img - rename them to boot_a_bak.img and boot_b_bak.img and keep that window open, need them in a second
2. Boot into the OS. Download the Magisk Manager APK from HERE
3. Copy the APK and both of those boot files to your phone, open a file manager and install the APK
4. Open Magisk Manager and click on "Install" for Magisk (upper right)
5. Select "Patch Boot ROM" (or whatever it says.. something like that..)
6. Navigate to boot_a_bak.img and patch it.
7. Go to your Downloads directory (where Magisk dumps the patched file) and rename it to boot_a_magisk
8. Go back to Magisk and repeat those steps for boot_b
9. Copy the two patched Magisk boot files to your computer, into the folder with your "critical" files backup.
10. Rename the Magisk files to "boot_a.img" and "boot_b.img"
11. Move all the files from the "Backup\backup_all-critical-(...)" directory to the "Restore\restore_critical" directory in my tools
12. Finally, reboot into EDL.. almost there!
13. Run "restore_all-critical" (don't forget to run Load Programmer first..)
14. It will restore all you files, kinda a waste of time - if you know how to use the "Specific Files" tool this is a perfect time to use it to flash JUST the boot files. But anyway - this will get it done.
15. When done flashing, reboot the phone and open Magisk Manager to confirm it is installed!
The Magisk team recommend you DO NOT FLASH your stock boot files back to uninstall it, instead they say you should run their uninstaller.zip. However, I am not sure how to uninstall it if you're on A10 since we don't have a recovery that can flash zips? (Unless the stock recovery works for that, I don't think it would..)
I suspect (but have not tried) that on our phone flashing the boot files back over Magisk will not really be a problem since the recovery and ramdisk are all wrapped up into the boot image. But I don't recommend trying it if you value your data! Fair warning.
---------------------------
Alright that's everything. Good luck!
This will be useful for a lot of folks on here, thanks for taking the time to look for a work around.
rafyvitto said:
This will be useful for a lot of folks on here, thanks for taking the time to look for a work around.
Click to expand...
Click to collapse
Glad to be helpful! Usually I lurk the forums getting information I need to unlock/root/etc lol.. but I saw I actually could contribute something to this forum so hopefully it encourages people to get interested in this phone. It's looking pretty sweet now that I'm not spending days fighting with bootloops!
Indeed,on the note of attracting more users. im going to be releasing something for the pixel lovers very soon ?
Thanks Bob!
I'm on A10 with unlocked bootloader. I made all EDL tool backups when on A9 but these were done before correcting the typos as suggested. So I am not confident of successfully flashing back to A9 (preference).
Therefore I will likely flash the magisk-patched boot files to attempt root and report my experience...
Sent from my ZTE A2020U Pro using Tapatalk
big thx, glad to see some life to this almost dev-dead device
Hey thanks for the post. I'm thinking about buying the phone but have a quick question. Can I update to the latest version of Android 9 before unlocking or will the OTA be Android 10. How would I go about updating to the latest version version of Android 9 and not go to Android 10. Can I download the Android 9 OTA from somewhere and flash that one? Thanks in advance for the help!
Crackass said:
Hey thanks for the post. I'm thinking about buying the phone but have a quick question. Can I update to the latest version of Android 9 before unlocking or will the OTA be Android 10. How would I go about updating to the latest version version of Android 9 and not go to Android 10. Can I download the Android 9 OTA from somewhere and flash that one? Thanks in advance for the help!
Click to expand...
Click to collapse
:good: I think your question borderlines on needing its own thread in the Q&A section but I'll answer you anyway...
Currently as long as you are on A9 when you get the phone you can just do OTA updates from firmware version 1.10 to 1.11 to 1.13 (not sure what android security update that is), after 1.13 it goes to A10.
There is an A10 firmware available from ZTE to SD card sideload. Once installed it has to be updated to the latest A10 via a couple OTA updates.
Going directly from A9 to A10 via OTA goes directly to the latest version.
You cannot flash the A9 OTA... because flashing an OTA is an oxymoron... but I guess you mean can you download the A9 firmware and flash them. The answer is... maybe. ZTE does not offer official downloads any A9 firmware for A2002U (USA version), only A10.
They do offer A9 firmware for A2020G (european) and I think other foreign versions (RU, CN). These cannot be interchanged, if you have the US or EU or CN phone you need to use that firmware... from what I have read. I could be wrong, I don't have those phones.
But there is an unofficial stock A9 firmware for the A2020U here on the forums, uploaded by @rafyvitto . That will get you to.. I forget.. 1.11? That can be flashed using the original EDL tool or, with a little modification, the EDL tools in this thread.
Additionally.. if I ever get around to it... I plan to upload all three A9 firmware packages for the US version which can be flashed with the EDL tools in this thread. Not sure if it's really necessary, but I have them.. it's just a matter of figuring out hosting them and spending the time to upload them.
bobthenormal said:
:good: I think your question borderlines on needing its own thread in the Q&A section but I'll answer you anyway...
Currently as long as you are on A9 when you get the phone you can just do OTA updates from firmware version 1.10 to 1.11 to 1.13 (not sure what android security update that is), after 1.13 it goes to A10.
There is an A10 firmware available from ZTE to SD card sideload. Once installed it has to be updated to the latest A10 via a couple OTA updates.
Going directly from A9 to A10 via OTA goes directly to the latest version.
You cannot flash the A9 OTA... because flashing an OTA is an oxymoron... but I guess you mean can you download the A9 firmware and flash them. The answer is... maybe. ZTE does not offer official downloads any A9 firmware for A2002U (USA version), only A10.
They do offer A9 firmware for A2020G (european) and I think other foreign versions (RU, CN). These cannot be interchanged, if you have the US or EU or CN phone you need to use that firmware... from what I have read. I could be wrong, I don't have those phones.
But there is an unofficial stock A9 firmware for the A2020U here on the forums, uploaded by @rafyvitto . That will get you to.. I forget.. 1.11? That can be flashed using the original EDL tool or, with a little modification, the EDL tools in this thread.
Additionally.. if I ever get around to it... I plan to upload all three A9 firmware packages for the US version which can be flashed with the EDL tools in this thread. Not sure if it's really necessary, but I have them.. it's just a matter of figuring out hosting them and spending the time to upload them.
Click to expand...
Click to collapse
Just wanted to chime in, interchanging firmware between each model is possible, you would only need to reflash your model/nonhos/tz partitions to the ones of your variant to have working ril/fod fp/sensors.
Ok Bob I gave it a go and successfully rooted my A2020U running stock A10 v2.09. This is my experience...
Firstly, my A2020U could not connect so I used the @Unjustified Dev Tool ("original tool") to easily determine my com port (i.e. 3). I edited the your scripts accordingly (using Notepad++) and got connected.
I'd rather not fiddle with the hardware buttons to change modes so I used the CLI to "adb reboot edl" to get into EDL mode.
I executed the backup_all.ps1 script.
It echoed several "warnings" indicating that it could not find files. However, the created backup folders did in fact include those files.
I noted that none of the "A" slot files include the "_a" postfix; the "B" slot files did include "_b".
Now I needed to transfer those boot files to my device by first rebooting my device and connecting via MTP.
I noted that the original tool offered a reboot menu option (but sadly only after executing a successful operation). So, not wanting to fiddle, I used the original tool to backup my boot files, then used the menu option to reboot; On my device I then manually selected it to connect via MTP.
After transferring the "boot.img" and "boot_b.img" files to my device, and installing Magisk Manager. I patched them and transferred them back to my PC.
To "flash" (restore) the patched files I decided to cut 'n' paste the two lines regarding them from your Reference.xml file into your rawprogram-specific-files.xml file, replacing your example lines.
I executed your run_write-files.ps1 script and it completed successfully.
Not wanting to fiddle again with the hardware buttons (just so that I can get the reboot option), I backed up the patched files using the original tool and rebooted. Now my device is successfully rooted.
Thank you!
Additional notes and suggestions:
1. Can you please investigate the "false" warnings? See my (redacted) log file attached;
2. It would be great if you could create/duplicate a script within your expanded tool set (or main program) to determine and set the appropriate COMPort (and teach us non-coders the actual commands);
3. Would you also consider investigating and including a reboot device script? (It looks like the original tool calls reset.xml);
4. Note that, at the time of reporting this, the latest versions for the Manager and Magsk are 8.02 (307) and 21.0 (21000) respectively, and that I had to switch the update channel to "beta" for the patched files to pass SafetyNet;
5. Because rooting is a likely use of your tool I am attaching my modified rawprogram-specific-files.xml file which targets the boot files for convenience.
bobthenormal said:
...
Additionally.. if I ever get around to it... I plan to upload all three A9 firmware packages for the US version which can be flashed with the EDL tools in this thread....
Click to expand...
Click to collapse
If this can help me get my A10 device to a state where I can install a custom recovery and cutom ROMs, I would appreciate it!
eKeith said:
Ok Bob I gave it a go and successfully rooted my A2020U running stock A10 v2.09. This is my experience...
Firstly, my A2020U could not connect so I used the @Unjustified Dev Tool ("original tool") to easily determine my com port (i.e. 3). I edited the your scripts accordingly (using Notepad++) and got connected.
I'd rather not fiddle with the hardware buttons to change modes so I used the CLI to "adb reboot edl" to get into EDL mode.
I executed the backup_all.ps1 script.
It echoed several "warnings" indicating that it could not find files. However, the created backup folders did in fact include those files.
I noted that none of the "A" slot files include the "_a" postfix; the "B" slot files did include "_b".
Now I needed to transfer those boot files to my device by first rebooting my device and connecting via MTP.
I noted that the original tool offered a reboot menu option (but sadly only after executing a successful operation). So, not wanting to fiddle, I used the original tool to backup my boot files, then used the menu option to reboot; On my device I then manually selected it to connect via MTP.
After transferring the "boot.img" and "boot_b.img" files to my device, and installing Magisk Manager. I patched them and transferred them back to my PC.
To "flash" (restore) the patched files I decided to cut 'n' paste the two lines regarding them from your Reference.xml file into your rawprogram-specific-files.xml file, replacing your example lines.
I executed your run_write-files.ps1 script and it completed successfully.
Not wanting to fiddle again with the hardware buttons (just so that I can get the reboot option), I backed up the patched files using the original tool and rebooted. Now my device is successfully rooted.
Thank you!
Additional notes and suggestions:
1. Can you please investigate the "false" warnings? See my (redacted) log file attached;
2. It would be great if you could create/duplicate a script within your expanded tool set (or main program) to determine and set the appropriate COMPort (and teach us non-coders the actual commands);
3. Would you also consider investigating and including a reboot device script? (It looks like the original tool calls reset.xml);
4. Note that, at the time of reporting this, the latest versions for the Manager and Magsk are 8.02 (307) and 21.0 (21000) respectively, and that I had to switch the update channel to "beta" for the patched files to pass SafetyNet;
5. Because rooting is a likely use of your tool I am attaching my modified rawprogram-specific-files.xml file which targets the boot files for convenience.
Click to expand...
Click to collapse
Nice! :good:
For the questions..
0. Thanks for the heads up on filenames! I completely missed that the _a files don't have the labels... As you probably noticed all the files are backed up correctly still (no missing/overwritten files), but I removed the _a from all the A slot files. That was my original "fix", so I guess I started building this package before I got annoyed by not having the _a/_b consistency. I'll update the correct XML file and upload it as a new version.
1. Don't worry about those! They're part of using the fh_loader interface. Warnings are usually just fine, ERRORS are bad. I'll add a note to the post when I get a chance so people don't get scared by that.
It's only when you do a backup the program is really only designed in the "writing" sense, for backups you literally run an identical XML to writing but you send a flag that reverses the process. So it weirdly checks if the files it is going to copy (which of course don't exist) exist, and it throws the standard warning, but then it just creates them (of course).
I can't turn those off without lowering the verbosity setting for that tool. I decided to leave it set to high because if someone has a problem and they post their log file (like so!) it's very useful to troubleshoot.
2. I'll think about it / try. Not very hard to program but a little time consuming.
I'll throw a copy of lsusb.exe in the next version. Windows port of the linux command. People can simply run that on a command prompt and it will list all the active COM ports/devices. If you're not familiar with it - you can also find out by clicking on the windows start bar or pressing the windows key and typing in "Device Manager". In the hardware list there is a category for COM ports where it lists them.
3. Yeah that's very easy I'll put one in the next version as well.
4. Helpful to know. Interesting that you needed beta to pass... I didn't think to mention I use the canary builds (not really recommended... the current one crashes when I try to hide Magisk Manager lol)
5. Thanks! Maybe I should make a directory specific to boot backup/write... but I do think anyone not comfortable doing the change you did might not want to be flashing their boot files anyway haha.. things to consider I guess.
As for getting you back from A10, definitely. I'll figure out how to upload them to one of those file sharing sites in a week or two.
In the mean time, with a backup from this tool you're safe (as far as bricking goes, you'll have to system wipe) to try rafy's EDL backup to revert to A9. I'll find the actual post... I should have been less lazy and linked it in my post lol... HERE - rafyvitto's EDL.
If flashing his backup doesn't boot right away try the tool I included to fix the bootable partition. If it still doesn't work after that (maybe mention here what happened) then just restore your backup.
Do you have the 128gb phone by chance?
Thanks much, especially for your detailed clarifications and convenient link!
I have the 8/256GB (P855A03_NA) model.
PS
I want to spend more time on ensuring I have a complete device backup before nuking with another EDL; will dedicate some time this week...
Sent from my ZTE A2020U Pro using Tapatalk
eKeith said:
Thanks much, especially for your detailed clarifications and convenient link!
I have the 8/256GB (P855A03_NA) model.
PS
I want to spend more time on ensuring I have a complete device backup before nuking with another EDL; will dedicate some time this week...
Sent from my ZTE A2020U Pro using Tapatalk
Click to expand...
Click to collapse
Oh nice, with the 256gb model you're good to use the userdata backup program too. Sounds ideal for you since, like me, you want a really bulletproof backup. If you run a full backup and then run the userdata backup you literally have a "phone state" so you can return your phone back to exactly where it was, not have to wipe system or anything.
Of course I'd hate to be wrong so as usual, do at your own risk! Lol. But I am using that method and it has worked great. The downside being over an hour of waiting for the userdata to download or upload... and having to store 256gb (for long term storage you can compress it down to literally a few gb).
I've been kinda busy, but working on getting some of those things from my last post done hopefully this week.
bobthenormal said:
Oh nice, with the 256gb model you're good to use the userdata backup program too. Sounds ideal for you since, like me, you want a really bulletproof backup. If you run a full backup and then run the userdata backup you literally have a "phone state" so you can return your phone back to exactly where it was, not have to wipe system or anything.
Of course I'd hate to be wrong so as usual, do at your own risk! Lol. But I am using that method and it has worked great. The downside being over an hour of waiting for the userdata to download or upload... and having to store 256gb (for long term storage you can compress it down to literally a few gb).
I've been kinda busy, but working on getting some of those things from my last post done hopefully this week.
Click to expand...
Click to collapse
That's great to know! Your user data backup option has simplified my life.
I will wait for your next revision to do a full backup plus user data before nuking.
I am looking forward to moving on from ZTE's A10 to one of Ray's ROMs...
Sent from my PH-1 using Tapatalk
Updated to 1.1a - kind of had to rush on some things so keep an eye out for mistakes, especially in the XML files, and let me know if you find any.
Should have an 1.09 (A9) firmware package up "Soon(TM)", just have to make the xml files then upload the file somewhere.
EDIT: Already needed to update to 1.1b - I found that the GPT_Tools had a big error that probably was there since 1.0 and no one noticed! Backups of the GPT should now actually work...
Thank you @bobthenormal !
Looking forward to your A9 EDL backup...
Sent from my PH-1 using Tapatalk
eKeith said:
Thank you @bobthenormal !
Looking forward to your A9 EDL backup...
Sent from my PH-1 using Tapatalk
Click to expand...
Click to collapse
It's up -- see the new thread.
I didn't have time to test it so make sure you backup but I'm 99,99% sure it will work. I tested it several times in the past, but to make the firmware package I took out all the (I hope) unnecessary files.
There's one thing I'm not sure of - whether you'll need to use the Fix Bootable tool after installing it. IF you need to, then I believe you will have to install it to partition B and then run fix bootable B. (The 1.10 backup was taken originally from the B partition).
If you find that it works without having to do that, let me know... it may not be necessary if wherever that bootable flag is stored didn't get included in the firmware package.
bobthenormal said:
It's up -- see the new thread.
I didn't have time to test it so make sure you backup but I'm 99,99% sure it will work. I tested it several times in the past, but to make the firmware package I took out all the (I hope) unnecessary files.
There's one thing I'm not sure of - whether you'll need to use the Fix Bootable tool after installing it. IF you need to, then I believe you will have to install it to partition B and then run fix bootable B. (The 1.10 backup was taken originally from the B partition).
If you find that it works without having to do that, let me know... it may not be necessary if wherever that bootable flag is stored didn't get included in the firmware package.
Click to expand...
Click to collapse
Thank you @bobthenormal !
I should be able to give it a go this weekend and inform...
Sent from my PH-1 using Tapatalk