[Android Software Development] Phil3759:
FAQ

1- what happens if I wipe/format/factory reset my data/media device?

format /data:

only data is wiped, exclude /data/media:

cd /data ; for f in $(ls -a | grep -v ^media$); do rm -rf $f; done

format /sdcard

: only /data/media or /data/media/0 (depending on setting you choose in Advanced menu) is wiped

rm -rf /sdcard/*
rm -rf /sdcard/.*

format /data and /data/media:

will issue a true format on /data volume, obviously killing /data/media

Factory reset:

will also preserve /data/media (rm -rf)

Clean to Install a New ROM:

will do a factory reset (format /data, /cache, /datadata and sd-ext) + format /system +/- /preload. Your system will not boot until you install a new ROM

2- I backed up my data and I cannot find it when I boot into phone

Stock CWM and CM Updater app are using a non conventional linking for internal storage: internal storage is linked as /sdcard/0

PhilZ touch supports true /sdcard paths by linking it to either /data/media or /data/media/0

/sdcard/0 has no meaning in PhilZ Touch unless you set it to /data/media

By default, if a folder /data/media/0 exists, PhilZ Touch will default /sdcard to it, else it will use /data/media.

The advantage is for all stock +4.2 users: they can directly access their backups from /sdcard, while in main system and see them on PC in MTP mode.

You can override that setting in Advanced Menu and force it to /data/media or revert to /data/media/0

I recommend moving all your old cwm path to /data/media/0/clockworkmod and set sdcard to /data/media/0 unless you are switching between stock CWM and this mod or you need CM Updater app

To sum it up: for stock +4.2 rom users, keep default (/data/media/0). For CM users, if you frequently use CM Updater to flash in recovery, force /data/media

3- I come from stock CWM/TWRP and PhilZ Touch cannot see my backups

Read Answer 2

4- Aroma file manager doesn't start when I double tap screen

Read the guide to install aroma file manager.

Path changed in v5!

Read the /data/media/0 faq 2

5- CMUpdater cannot flash downlaoded files

If you get a /sdcard/0 error, it means you have /sdcard set as /data/media/0 in recovery

The reason is that CM app doesn't support /data/media/0 and is faking recovery with a /sdcard/0 implementation

You still can alter the setting and force it to /data/media in Advanced menu. This will give full compatibility with cwm, CM roms and CM Updater

6- How to flash a boot.img or recovery.img file?

- Put your boot.img or/and recovery.img files under a subfolder in

clockworkmod/backup

on sdcards

exp: /sdcard/clockworkmod/backup/cm-10.1-nightly_20130713/boot.img

- Navigate to Backup and Restore / Custom Backup and Restore / Custom Restore Job

- Unselect all partitions except boot and/or recovery

- Select >> Start Custom Backup Job <<

- Browse to your backup location until your cm-10.1-nightly_20130713, and select any file inside it

- You are done

7- My backups take a long time to complete

First, make sure you set compression to fast or low. Low compression setting gives around 30% compression with quiet no impact on speed. Rising compression value makes backups extremely slow with very little gain on space.

Stock CWM uses exfat fuse but without any buffering of writes. The end of it is a non usable thing for any backup because of an incredibly slow write speed.

TWRP uses exfat fuse binary to do the backups + caches tar writes to improve speed. This could cause data corruption on some devices.

PhilZ Touch uses patched kernel with native exfat support (static mode) for Samsung devices and soon other brands. This is supposed to be the faster and safest way.

However, it seems to struggle on some devices because of the logging mode used by CWM

Solutions

:

- hide progress bar in Nandroid Settings menu: this will dramatically improve speed for many devices

- do not use exfat

- change exfat card to another brand. Ask in forum what people are using with good speed

- some users reported a real slow down when card/device is hot. Let your phone rest from intensive read/writes before starting a backup

- switch to another recovery like twrp if you cannot live with it. PhilZ Touch is compatible with TWRP and can backup/restore twrp format

8- You think you found a bug?

- Make sure your issue is recovery related

- All external sdcard issues: first format in PC with primary partition, tons of people are formatting as logical and come cry

- Reproduce your issue and while in recovery:

- Go to Advanced / Report Error

- Copy the /sdcard/clockworkmod/philz_recovery.log file and attach it here

- Give detailed info about your issues

- Without these, there is little chance I can help you, so, do not get mad if I do not answer

9- Loki things

Locked bootloader? How to lokify before flashing:

In Advanced Menu / Toggle Loki Support : enable auto loki

Flash the zip file and you are done

PhilZ Touch recoveries that come in a zip file format AND released after v6.01.2 have a script in the zip to lokify the recovery image during flash even if you are coming from older recoveries or TWRP (thanks [MENTION=4709667]Wootever[/MENTION])

The included recovery.img in the zip is not lokified, it will be lokified during flash

If you are using a new CWM or PhilZ Touch with auto-loki enabled, please disable it before flashing my zip files to avoid any issue with double lokifying, if ever possible!

Unlocked bootloader users can still extract the recovery.img file and restore it from inside recovery:

put recovery.img in /sdcard/clockworkmod/backup/philz_update/recovery.img

In Custom Backup and Restore menu, unselect all except recovery

validate to browse to the update recovery.img

done

10- Assert error 7 on device name when installing roms and updates

Start of v6.02.2, recoveries are based on cm-11.0 (KitKat) device tree.

In all zip installers, you have a file called update-binary. It is the executable that will process and interpret all commands in updater-script, which will do all actions.

Older update-binary files cannot access system assert props on kitkat based kernels.

Fixes:

- edit your updater-script in zip file and remove all assert lines checking for device name. Use notepad++ or a linux editor

- manually change your update-binary in the zip with a new one you take from a cm-11.0 release

- revert to an older recovery before 6.02.2

- ask your rom releaser to update his update-binary

Note: start of 6.09.6, this error is fixed. However, you can end up with error in FAQ 11

11- various status 7 errors: format() expects 5 args, got 4 - set_permissions errors...

First read FAQ 10

Start of 6.09.6, recovery will analyze the update-binary that comes with your zip package. If it detects an outdated version, it will be automatically replaced during flash.

This will fix all assert getprop errors discussed in FAQ 10 (often used to check if the zip is meant to be flashed on your device)

However, doing so, can expose you to a bunch of new errors if the update-binary is +2 years old. In that case, the updater-script code used could not match the new update-binary:

The error "format() expects 5 args, got 4" is caused by not using the below new format command in updater-script:

exp:

format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");

The error due to failure on set_perm is caused by using 2 years old update-binary

New ones will abort installation when setting permission fails on any file, while it was previously allowed to continue

Fixes:

- start of 6.15.4, PhilZ Touch added an option to force using the update-binary that comes in your zip. It will make it work except for the assert for device name error. However, that error is very easy to fix by any one (see FAQ 10). The option doesn't stick on reboot, you have to manually set it when you flash such files. It is done on purpose to keep you warned about potential risks using such bad scripts often coming from a copy paste procedure

- hammer your ROM maker to keep up to his time, and look closer at his scripting and update-binary engine used

12- Time fix for Qualcom Chips and other devices

On many Qualcom devices, setting the time is disabled on different levels, depending on the device

New PhilZ Touch versions added a workaround to this limitation. The fixes do not modify in anyway the RTC flags in kernel, as it is not recommended by Qualcom

-

Qualcom Time Daemon

:

This is the recommended option. It will load the time daemon from /system and will keep your recovery time in sync with ROM.

However, many CM/AOKP/Custom Roms do not have a proper implementation of the daemon. Ask your ROM dev to properly implement Qualcom proprietary binaries and RTC permissions.

-

Use RTC Time Offset

:

This is the second workaround, recommended for ROMs without proper time daemon. You have to enable the option. After that, it will ask you to setup the actual time/date manually. Do it AND Validate your choice to apply the actual time. Enabling the offset mode without manually setting correct time AND validating your option has no effect!

-

Try Force Persist on Reboot

:

This is your last choice, if all other options failed. Disable previous 2 options and enable this one. You will need to setup time/date manually AND validate your choice. Else, it won't have any effect.

-

Normal/manual mode

: Non Qualcom based devices, can just use the default mode to set time/date manually

13- My ROM maker advises another recovery

If an installer script cannot run on PhilZ Touch, it won't run on CWM. PhilZ Touch is just a CWM mod in that regard. Installer is not modified

Rule of thumb: If a ROM cooker says "YOU MUST USE A GIVEN RECOVERY", be sure there are bugs in his work

A properly formatted updater-script, shell child scripts or aroma scripts should be able to run on any recovery as it should call real blk device paths and not "pre-defined" mount points

Mount points WILL vary from recovery to another and maybe from a version to another. Relying on them is a bad idea

Also, many do miss proper edify scripting rules:

- /sdcard is a symlink, not a folder since years now (/data/media)

- you cannot extract without mounting first

- you must create your paths. Installer won't be verifying you did so

- you cannot mount vold paths (sdcard, usb storage...) by calling the mount point in a shell script. Look at your fstab under recovery to understand why

If a rom maker has issues to understand this, he can ask for help here or in an edify scripting thread

14- F2FS <-> EXT4 format migration

Under "mounts and storage" menu, if "toggle f2fs <-> ext4 migration" is enabled, whenever we try to format an ext4 or f2fs partition, we get a prompt to convert between f2fs/ext4

To convert /data on /data/media devices, we must as always select the "/data and /data/media" menu

Nandroid implementation to migrate your data/ROM from ext4 to f2fs:

- backup your existing data

- in "mounts and storage", format the partitions you want to convert to f2fs

- restore your data

- on restore, if both backup image and target partition has different fstype and fstype is either ext4 or f2fs, we favour target devise fsytpe (data migration)​