It sounds like the "/system/bin/app_process" has been modified and so it doesn't match the signature required. There are 2 ways to fix this, either get a copy of the stock file from another phone/rom or flash the factory image for 4.3
Edit: After reading "update 2" it sounds like you want the factory image option detailed below.
In short, if you want to flash KitKat Android 4.4, you'll have to upgrade to a version of CWM greater than v18.104.22.168. Or, use an alternate bootloader. For the Galaxy Tab 2 GT-P5113 or GT-p5110 you can find the instructions here.
It does this in order to break up large .tar files into chunks of 1000000000 bytes (or 1 GB):
-rwxrwx--- root sdcard_r 0 2014-03-19 14:31 data.ext4.tar
-rwxrwx--- root sdcard_r 1000000000 2014-03-19 14:33 data.ext4.tar.a
-rwxrwx--- root sdcard_r 1000000000 2014-03-19 14:36 data.ext4.tar.b
-rwxrwx--- root sdcard_r 1000000000 2014-03-...
Inside Heimdall zip there is a driver folder.
Run the zadig.exe
click options - List All Devices
Choose your phone from the drop down list (on my pc it was "MSM8960"
I could not get it to work correctly on my PC, onece plugged into laptop "SAMSUNG Mobile USB CDC Composite Device")
Go through the drivers (WinUSB, Libusb0, Libusbk) and clikc Place drive ...
It was removed because
It's total placebo these days. I wrote it for dealing with the silly things that happen when we used to put apps on SD before Android supported it. Since then, it's been something of a sugar pill that magically fixes all problems without actually doing anything.
(Taken from the commit history, posted by Steve Kondik)
A zip package that contains a firmware update always includes two files in META-INF/com/google/android: updater-script and update-binary. updater-script is a text file containing commands required to install the update. update-binary translates the commands into binary code.
In Android 4.4 KitKat, Google has changed the interface that updater-script uses ...
According to: https://wiki.cyanogenmod.org/w/ClockWorkMod_Instructions#Making_a_backup
ClockworkMod's backup/restore feature will generally only back up the
/system, /data, /cache, /sd-ext, and /dalvik-cache areas. Other
partitions such as /emmc, /sdcard, and /media won't be backed up.
fact, the backed up system will typically be saved to ...
Wipe data will wipe everything on your /data partition (hence the name). A factory reset will wipe the same (additionally also cache and Dalvik cache), and put your device back to a virgin state. Usually, this doesn't touch the (external) SDCard, and AFAIK should not touch the internal SDCard either.
I don't know on which partition your mentioned folder ...
In addition to the well-known Titanium Backup app (for which you must purchase the Pro key to unlock the CWM/TWRP nandroid backup support), there is another app now: Nandroid Manager, which according to its description can restore apps from nandroid backups even with the free version (there is a Pro key too, but it is required if you want to restore special ...
Assuming your device adheres to some Android standards, you'd want to run fastboot oem device-info.
Often you can also run fastboot reboot-bootloader to get into the bootloader which often says right there on screen whether it's locked or not.
Different devices can display the lock state differently.
fastboot is located in %ANDROID_SDK_DIR%\platform-tools,...
Try doing what it suggests... run e2fsck -b 8193 /dev/block/platform/msm_sdcc.1/by-name/userdata. If that doesn't work, try running mke2fs /dev/block/platform/msm_sdcc.1/by-name/userdata.
You can also boot into fastboot mode and run fastboot erase userdata.
If none of these work, please elaborate on this "long story". How did you mess up your data ...
Some stock ROM's may replace the custom recovery with the stock recovery. To solve it you should install the custom recovery with fastboot and reboot to recovery and don't reboot to system. That will prevent the stock ROM from replacing the custom recovery.
To add to other answer, your back up has ALL the information in your back up image as the phone has when you took back up
/system refers to your ROM
/data refers to your data created by apps both that came with phone and user installed apps (/data/data)
/data/cache (the cache) refers to app data stored for quick access
/data/dalvik-cache (the Dalvik cache) ...
This suggestion assumes familiarity with connecting to the phone via ADB
I had a similar situation on my previous phone. I was able to pull the important stuff over ADB when the phone was in recovery. In my case I had to mount some of the filesystems to access everything I wanted to retrieve.
I'm not sure if it is dependent on the phone whether the ADB ...
Sony Xperia Devices use a recovery-in-boot arrangement. While you can't simply flash a version of TWRP or CWM, you can flash a kernel that includes what you need.
For the Xperia L, you can flash the Phanton Kernel, which includes CWM.
There is no other way to do get CWM or TWRP without flashing a new kernel.
The "device not supported" message means that you probably downloaded the recovery image for a different device (AT&T's LG G2 "d802", or International LG G2 "d800".) You can override this check, but it's not recommended, as the devices might be different enough that you could cause irreparable damage to it (a.k.a. "bricking".)
The most current TWRP ...
A nandroid backup is a full device backup – so you could ask the same question about a full backup of your PC: After restoring the backup, you'd be at exactly the state the device was in when you performed that backup – all changes done between making the backup and restoring it are lost.
Reading between the lines of your question, you're rather asking how ...
I tested this, and your concern is valid.
I added a dummy file to /system and then did a nandroid restore. The dummy file survived. Repeated the same test on /data with same result. So I don't know why CWM doesn't wipe those partitions first.
The CWM author probably made an assumption it doesn't matter or there may be a valid reason they don't get wiped....
I checked that myself.
I installed CWM 22.214.171.124 on my Galaxy Tab P5100, then I tried to restore the TWRP backup that I already had, and It didn't work.
Maybe it needs a little more technical work. But with a normal procedure, it doesn't work.
It looks like the CyanogenMod installation instructions for M7 are missing a section for flashing ClockworkMod recovery onto the phone. Right after you unlock the bootloader, you need to do the following:
Download and install Android SDK Tools from here (expand the "Download for Other Platforms", and it should be under the "SDK Tools Only" section.)
After scouring the net, I've learned this can be determined by entering your device's fastboot mode (from your device's boot menu selection, select AP Fastboot) and about four or five lines down from the top, you should see either Device is LOCKED or Device is UNLOCKED.
Unfortunately I only discovered this after attempting to flash the custom recovery while ...
You didn't specify which device you own, but by the tag I assume it is a Nexus 5.
Flashing TWRP is pretty easy, especially on Nexus devices.
Download the newest .img file here:
Turn off your device. Turn on the device and keep holding volume down until a menu shows up. ...
Samsung devices can usually be forced into download mode using a JIG. They are pretty simple and cheap to make. If your device has been soft-bricked this will almost always work.
Personally, I am a Nexus user. But having repaired a friend's international variant S3 before, I do know some things about Samsung. And since you don't have custom recovery, you cannot access /data (the partition where data is stored). So the way I know of will use a custom recovery to backup/restore data. This voids your warranty.
I am assuming you already ...
Until Android version 4.4.2 the CWM backups are stored in /data/media/clockworkmod/backup Reason for this as per the Reddit Post (see source below)
In Android 4.2, backups are placed in a secure directory, inaccessible to other apps
Whether it is TWRP / CWM / Philz recovery, clearing "internal storage", does not wipe this folder, unless explicitly ...
The problem was that the ext3/ext4 filesystem on /dev/lvpool/system, normally mounted at /system, had a corrupt superblock. The fix was to connect to the phone with adb and run e2fsck manually, like so:
# ./adb shell
# e2fsck /dev/lvpool/system
e2fsck 1.41.11 (14-Mar-2010)
e2fsck: Superblock invalid, trying backup blocks...
Backing up journal inode block ...