If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Quick encryption guide (and more)
I won't go deep into useless details as everything has already been described about Android phone protection somewhere on the internet. I will just give some meaningful links and tips by illustrating how I have protected my phone. Really nothing new or innovative, just a compilation of a few hints that I have put in practice to protect the numerous pieces of information that are on my phone.
Step 0: awareness
----------------------------
Why bother with phone security?
In short, I am clearly paranoid. Well, in fact, I don’t really feel at ease when I know all the information, both personal and professional I have on my phone. Over the month, my Androphone has become a real digital Swiss-knife and personal secretary. This includes:
Personal and professional contacts
Personal and professional agendas
Personal and professional digital exchanges (SMS and email)
Personal and professional photos
Banking account information
Trails where I run
Etc… etc…
Don't want someone looks at them. Not you?
Fist step: on-line protection
----------------------------------------
The first step in protecting your data consists in making hard to access indirectly the data that lay on your phone memory. This access consists in using the system when the phone is on, either via the GUI and the phone controls, or remotely (essentially by network connections, or phone basic functionalities like sms). So, basically, you need to lock efficiently your phone from preventing someone else to unlock the user interface that allows interactions with the system, and protect all communication channels.
To lock efficiently your phone, you must use a pin code of at least 4 digits (6 is better) or a pass-phrase. The latter is much less practical without improving online security that much. Above all, you must avoid those silly locking solutions like face recognition unlocking, or pattern lock. Those are toys for naive young boys. Not for those concerned seriously by security.
For protecting remote access to your phone, I would suggest:
1) Double check that USB debugging is disabled. This a major security hole.
2) Turn on data connections (bluetooth, wifi and 2/G/3G/4G) only when required (email checking, web-surfing session, data synchronising), and off rest of the time.
3) Avoid install cracked unofficial apks, or applications that asks for permission far beyond their obvious and principal utility
4) Install a software security app, if possible, open source and recognised by xda members. Once an adept of Droiwall, I have switched to Avast mobile security because of its extra features. But it is not opensource and it is a question of taste. But do this carefully, see that for instance before making a choice: http://download.cnet.com/8301-2007_4-57391170-12/dont-get-faked-by-android-antivirus-apps/ and http://www.av-test.org/fileadmin/pdf/avtest_2012-02_android_anti-malware_report_english.pdf.
But, you must be rooted (which is in itself a security hole if not mastered) and one must have a kernel with netfilter functionalities activated. This is the case with the stock kernel of the phone I use at the present time (Lenovo A789). But was not the case of 2 Samsung phones I used before. You have to either install a custom kernel adapted to your phone, or make your own if you have access to its sources (see tutorials as: http://forum.xda-developers.com/showpost.php?p=22941057&postcount=1)
5) Personally, I would feel more at ease if I could find an easy to use firewall solution that could close, and better, make stealth all the local ports of my phone, especially when I am not behind a wifi router. But I haven’t found one yet. Droidwall, nor Avast, addresses this functionality, whereas it would be fairly easy to implement it with the netfilter system layer underneath.
Second step: offline protection
-------------------------------------------
Here we are. Now your phone is protected when it is on. But, what if you switch it off, or remove its sdcard? The data lay on the internal memory, unprotected (at best obfuscated). Really easy to find a custom recovery for almost all phones, write a script to dump /data on a sdcard and then make whatever you want with the copy.
Don’t like that? The only solution to prevent /data from being read by someone else is to encrypt the /data partition. To do that, your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. So beware, if you want encryption you need to buy a device that answers this requirement. This is not always true and almost never documented. Notes on the implementation of Android encryption are there: http://source.android.com/tech/encryption/android_crypto_implementation.html
Now, as me, if you are reading these lines, you are certainly looking for extra information about your Android device and probably extra functionalities.
Certainly, the most frequent way to install extra functionalities and custom ROMs to your phone is to use an update zip file. With stock recovery, this zip file needs to be signed, otherwise it is rejected. For maximum flexibility and ease of use, alternative boot recovery have been developed, of which CWRP is certainly the most famous.
Usually, for 99% of users and operations, CWRP operates great. Sometimes, as nothing is perfect, a bug may occur. This is the case for built in ICS encryption process. As Cybermaus indicates in the first post, to be able to perform this encryption the /data filesystem must be slightly smaller than the underlying partition. But CWRP, at least up to the version 5.5, formats all the corresponding partition leaving no place for Android to store the required information to be able to start the encryption process. This is clearly described in the following links: http://forum.xda-developers.com/showthread.php?t=1792101 and http://rootzwiki.com/topic/25652-fixing-galaxy-tab-2-encryption/
I have discovered that by using aLogcat to track down the origin of the failure. The interesting part revealed to be: E/Cryptfs ( 87): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
To circumvent this problem, you will find in Cybermaus first post, two CWM update zip files that will do the trick in a simple and secure way. After flashing your ROM and wiping data with CWM, apply them, go to system encryption as described here:http://support.google.com/android/bin/answer.py?hl=en&answer=1663755, and after waiting one or two minutes (not more), the system should restart automagically to encrypt your /data partition.
Third step: making your phone even more secure and practical at the same time
-------------------------------------------------------------------------------------------------------------------
Android built-in encryption is in fact more or less Linux LUKS (http://en.wikipedia.org/wiki/Linux_Unified_Key_Setup). Plus, it is open-source so that everyone with the required skills can make an audit of the code to see if no security hole is present in the Android implementation. The underlying mechanism is strong and secure, as long as you use a strong password. I mean by strong, at least 12 characters that includes at the same time lower-case letters, upper-case letters, numbers and symbols. And it must be something impossible to guess for others while easy to remember for yourself. You will find a lot of resources on the internet on how to create such a password. For instance: https://help.ubuntu.com/community/StrongPasswords .
The problem with Android, in its attempt to keep the system not too complicated to use, is that the GUI (I insist: only the GUI, not the system) does not distinguish between the PIN or passphrase that you use to lock your phone when it is on, and the password used to encrypt the data that lay physically on your phone storage. So the casual user is in front of a paradigm: either he chooses a strong password for its data, but this will rapidly become tedious to type at least 12 characters to unlock his device several times a day; or he decides to use a PIN code, which is more practical to unlock the phone, and consequently uses a really weak password to encrypt its data which contains only digits, and thus may be cracked in a breath by any PC.
Fortunately, this paradigm is addressed and solved by small tools like EncPassChanger or Cryptfs Password (both requiring that your phone be rooted, which is by the way, paradoxically, a security hole if not used with caution ). See: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html for complete notes about that. So for me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time.
Fourth step: increase security, without sacrifying practicability
-----------------------------------------------------------------------------------------
As I am paranoid, but at the same time don’t want my phone to become a source of annoyances, the previous “basic” steps were not enough for me.
So I decided to improve security in two ways:
1) By following the following tip, which I find great and is itself self-explaining: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2
2) By encrypting the photos I take with my phone, because these are linked with my private life and I won’t like that somebody gain access to them.
3) By encrypting documents I scan with CamScanner, for home and work, which may be sensitive.
4) By automating the action that disables USB debugging in case I forget to put it off after using it .
For point 2 and 3, documents lay on your sd card uncrypted. Android built-in encryption does not deal with both internal and external sdcard (just to be clear, by sdcards I mean partitions mounted as /mnt/scard or /mnt/scard2). To encrypt them you have to use once again an external tool. As I am an opensource fanatic for all that deal with security, I would recommend to use LUKS Manager (https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&feature=search_result and http://forum.xda-developers.com/showthread.php?t=1141467) which is based on dm-crypt module (yes, the same that Android uses for its build-in encryption), or Cryptonite (https://play.google.com/store/apps/details?id=csh.cryptonite&feature=search_result) which is completely open-source and implements the rock-solid Linux encfs on Android.
The latter is my personal choice. I do not use Crytonite in itself, except for creating the initial .encfs6.xml file. For everyday use, I use directly the Android port of the binary file encfs that comes with Cryptonite, and embed it into shell scripts. Up to now, no flaw, no problem. The password to open my encfs encrypted volumes is stored in a text file located on the /data partition. It is thus encrypted by Android and made accessible on boot when you decrypt this partition. So nothing more to remember.
To make things usable and practical, I use Tasker to automate the following things:
- Mount encfs volumes on start-up, by reading directly the password in the file located on /data
- Umount encfs volumes when usb is plugged
- Copy photos on a regular basis from the unencrypted /mnt/sdcard/DCIM to the safe place I created with encfs, delete AND wipe the original ones
Fifth step: be coherent about security
-----------------------------------------------------
Some people, torn apart by the paradigm described in Third step, by negligence or by lack of knowledge, strongly secure one part of the system, but make other parts big security holes.
Concretely, I am thinking about two examples: mixing encryption with pattern lock (or, even worse, with face unlock), or mixing encryption with usb debugging. Face recognition is just a jock. It is not reliable and fails very often. Moreover it is really easy to crack, with a photo for example. One of my colleague even achieved to unlock my phone with its own face, just because we are morphologically close enough. Pattern lock is not much better. (See: http://forum.xda-developers.com/showpost.php?p=37649447&postcount=6 and https://www.google.fr/search?q=smudge+attack).
So always ponder over (two times rather than one) each action you take that may touch system security.
Thanks lolo
I'm trying to use this on my VZW Galaxy S3 16Gb and this is what I'm seeing in TWRP v2.2.0:
Mounting System
Extracting system fixes
Update script starting...
Update script started
Disk /dev/block/mmcblk0p15: 13.1GB, 13140754432
4 heads, 10 sectors/track, 401024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
ERROR: unlikely size of KB
aborting operation!
Update script ended
Unmounting system...
Update Complete
Click to expand...
Click to collapse
edit: The same thing happens with both scripts.
I need to enable device encryption because my employer requires it for email and other Google Apps for Business apps. Thank you for your help!
Anyone know why full disk encryption isn't available on some (if not most roms)? Is it something that needs to be added with intent aside in the building process, or dependent on how the stock rom was set-up to work with?
I was hoping this would help get encryption working on an EVO ics rom which has encryption available, but when you click "encrypt phone" it just hangs on an android screen and doesn't actually do anything.
i was really happy to find your solution to enable encryption on my HTC desire S (ICS, rooted), but unfotunately it doesn't work. the same thing happen to me as it happened to mushu13, only different numbers in lines 5 and 6. same result whichever script i choose. please help, i really need system encryption.
thanky you very much!
First thing you should know, I am not an Android Guru. And unfortunately, if your phone is not an A789, I won't be able to help you deep in technical details. Cybermaus is the most skilled of the two of us, technically speaking, and he may lack time to answer correctly every request he is regurlarly faced with.
Okay, I do not know your phones and don't own them. So, distant debugging is much harder in these conditions. But the first things you should check, before applying Cybermaus' patches, are :
1) if encryption works with stock rom
2) follow thoroughly all steps I described in "Second step: offline protection" of the second post of this thread :
- your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. If you don't have this information from the manufacturer, install Terminal Emulator from the Play Store and type 'mount' in it. You should see lines beginning with /[email protected] and /[email protected] If this is not the case, I fear encryption won't be able to work on your device.
- use aLogcat to track down the origin of the failure (see resources on the internet to learn how to use it, and links I have put in the second post)
3) Be sure that required modules are built into the kernel you use, especially dm-crypt
4) Post your results and cross your fingers that either this is a problem I have already encountered (in this case I may help you further), or Cybermaus see your posts.
While this script did allow me to encrypt my phone, it also shrunk my /data partition to roughly 1.1 GB.
Any ideas on how to expand it back to a reasonable size? I supposedly have 4 GB of ROM, and I assume more than 1 GB ought to be available for data.
Sent from my HTC Sensation using xda app-developers app
Thank you for your nice guide.
Only one thing is missing: baseband security.
Attacks on the baseband system requires very skilled people. Such as government agencies. It is believed they use baseband attacks to break into almost every mobile device. And there is only little you can do. Some vendors like Cryptophone have mobile devices with a hardened Android system. All others have no way to protect their device against baseband attacks.
Is this patch and reasoning still valid for newer android releases.
I am running a custom kitkat rom and twrp on a note 3 and can't encrypt so im looking for a fix.
I have been looking around for fixes but different posts blame different things.
Sometimes its the fact its a custom recovery, sometimes its that root is on the device and then there is this reasoning
Is there a way to find out the cause and fix for kitkat?
Virus
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
u2funker said:
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
Click to expand...
Click to collapse
Maybe false alarm.
Lossyx said:
Maybe false alarm.
Click to expand...
Click to collapse
no, but if you search for these file, you will find some which work and which are without viruses. Check the link..it is not an zip file..it is an exe file
@cybermaus: just tried flashing the two *.zips on my Galaxy S 4 Mini running CM 12 (Android Lollipop) because my logcat tells me I'm getting the described cryptfs error. It seems my /data partition doesn't have that 1 MB of unused space needed for encryption. Now I would love to encrypt my phone using CM's integrated function without having to completely format the internal storage (because that's the other workaround I found: flash stock rom, wipe data (factory reset), flash Custom Recovery, flash CM again)
Do you have the time and device to update your script so it works with Android Lollipop as well? I see a lot of people come across this issue recently so there would be definetly use for such a nice script like yours!
Thanks for sharing this with us!
-Teutone
no available for download any mirror ?
Or write the script on the thread.
Thanks
Can you post the scripts? links are dead!
---------- Post added at 16:33 ---------- Previous post was at 16:32 ----------
cybermaus said:
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Click to expand...
Click to collapse
links are dead. Can you post the scripts?
Hi all,
First of all - forgive me if the subject has been up before - I did a bit of searching, but could't really find much about the subject.
I'm generally very pleased with the Mi A1 (my 4th "main" android phone after HTC Desire, SGS3 & OPO) but one thing that is giving me a bit of grief is this thing with access to my sd card, more precisely with copying content to the card by using different apps like root explorer, dropbox, dropsync pro etc.
Two very common actions in my usage are:
- Start an ftp-server on the phone and push new episodes of whatever tv-series I'm watching for the moment from computer to phone
- Open root explorer in my phone and copy stuff from my Dropbox folder to my phone (and back)
Neither of these actions can be done in my A1 (stock Oreo). The phone actually give the appearance of giving me the option to choose the sd-card but when trying to actually transfer something there it get's stuck before finishing or just return an error when trying.
So my question is - to get back to actually having rights to transfer stuff to my SD card without any problems, which of the below options would be the "easiest":
1. Does this work if I downgrade to Nougat?
2. Would rooting be enough if I stay on Oreo?
3. Can I transfer more freely with LOS 15.x?
4. Other options?
I actually found one thread mentioning this as a problem in stock Oreo so I know I'm not alone with the problem.
Thanks in advance,
/gosa
Hi,
Found this when searching Google for solutions this problem.
At the moment my only way of getting files onto the memory card is to download them to the internal storage and then using "Stock" file manager to copy them to the memory card... A bit to many steps if you ask me.
I was thinking that rooting might solve it but haven't gotten around to it yet.
hi
gosa said:
Hi all,
First of all - forgive me if the subject has been up before - I did a bit of searching, but could't really find much about the subject.
I'm generally very pleased with the Mi A1 (my 4th "main" android phone after HTC Desire, SGS3 & OPO) but one thing that is giving me a bit of grief is this thing with access to my sd card, more precisely with copying content to the card by using different apps like root explorer, dropbox, dropsync pro etc.
Two very common actions in my usage are:
- Start an ftp-server on the phone and push new episodes of whatever tv-series I'm watching for the moment from computer to phone
- Open root explorer in my phone and copy stuff from my Dropbox folder to my phone (and back)
Neither of these actions can be done in my A1 (stock Oreo). The phone actually give the appearance of giving me the option to choose the sd-card but when trying to actually transfer something there it get's stuck before finishing or just return an error when trying.
So my question is - to get back to actually having rights to transfer stuff to my SD card without any problems, which of the below options would be the "easiest":
1. Does this work if I downgrade to Nougat?
2. Would rooting be enough if I stay on Oreo?
3. Can I transfer more freely with LOS 15.x?
4. Other options?
I actually found one thread mentioning this as a problem in stock Oreo so I know I'm not alone with the problem.
Thanks in advance,
/gosa
Click to expand...
Click to collapse
Here one more with the same problem. I have the My A1 in ROM Stock Oreo 8 with root via magisk, and it is tedious and annoying not to be able to write to the external SD. I use ADM, apps for downloads Torrent, Solid Explorer.
Having Root I had the opportunity to try several possible solutions. Here some of them (note: none worked, nor resolved) I expose them in case someone else wants to try, possibly something will work for them.
Root ??????
SDFix: KitKat Writable MicroSD. (Developed by NextApp)
Magisk Modules??????
App Systemizer
ExSDCard Access Enabler
Xposed ??????
Marshmallow SD fix
KitKat SD Card Full Access (Caution: gives many errors in OS)
Handle External Storage
One way to take it with Solid Explore (it's more visual than the Stock Explorer):
* Solid Explorer, to paste or write to SD, always go to Root / mnt / media_RW / SD Card
As I mentioned. None of the above worked for me.
The only way to solve the problem momentarily is to download and use the apps all in the internal memory, with the stock file explorer moving the files to the external SD in a step later.
If someone can give light to this problem or a possible solution I will be very grateful.
*(sorry for my English)
Have you tried binding folder/creating softlink
Could you explain how it is done? Or inform about the subject.
Just got 8.1 and the problem is gone.
The following is the latest version of TWRP compiled for the T-mobile V10 Model H901.
https://androidfilehost.com/?fid=818070582850501883
MD5SUM: b89d341cd61da31a5348d8f6b3c75c97
The heavy lifting was done by the twrpbuilder project who were generous enough to compile TWRP for our device. They also provide their services to see TWRP is available for devices that don't yet have it. I've personally used this version to do a backup and restore but can't guarantee there won't be issues. If there are while you are still in twrp you should go to the advanced section and copy the log to your external sd card. This log will help them diagnose any issues.
The project is located at: https://twrpbuilder.github.io
Their XDA thread is located here: https://forum.xda-developers.com/android/apps-games/twrpbuilder-t3744253
If you already have TWRP installed installation is as follows: Click Install, choose Image file, navigate to where the TWRP img file is located on your external sdcard and flash that img to the recovery partition. Back out to the root dir and you can select reboot then recovery...it should bounce you right back into recovery and you should see the new version loaded. If you have root in the rom and run into issues the app "flashify" can reflash TWRP 3.0 so make sure you also have it's img available.
This is pretty much only for folks who already have twrp to update to the latest. If you are on nougat you are still stuck until an exploit is released that works for nougat the way dirtycow did for marshmallow and below. *update* an exploit to give root to nougat users is now available thanks to @runningnak3d here: https://forum.xda-developers.com/tmobile-lg-v10/general/root-h901-nougat-t3773942
Reserved Post #1
Reserved Post #2
famewolf said:
The following is the latest version of TWRP compiled for the T-mobile V10 Model H901.
https://www.androidfilehost.com/?fid=8180705828505018
MD5SUM: b89d341cd61da31a5348d8f6b3c75c97
Click to expand...
Click to collapse
Looks to me like that URL should read
https://androidfilehost.com/?fid=818070582850501883
[ EDIT ] Yup, confirmed.. The URL I listed works fine.
Thanks for the file!
:laugh::silly:
NYLimited said:
Looks to me like that URL should read
https://androidfilehost.com/?fid=818070582850501883
[ EDIT ] Yup, confirmed.. The URL I listed works fine.
Thanks for the file!
:laugh::silly:
Click to expand...
Click to collapse
You are correct. For some reason a few characters got truncated. I've corrected the url in post #1.
famewolf said:
The following is the latest version of TWRP compiled for the T-mobile V10 Model H901.
https://androidfilehost.com/?fid=818070582850501883
MD5SUM: b89d341cd61da31a5348d8f6b3c75c97
The heavy lifting was done by the twrpbuilder project who were generous enough to compile TWRP for our device. They also provide their services to see TWRP is available for devices that don't yet have it.
Click to expand...
Click to collapse
Just as an aside, this version seems to correct (mostly) the date issue of previous TWRP versions for the V10. Versions before this one used to generate a default date (folder name) for the backup dating back to the 1970s as I recall.
This one has the correct month and day and time and the year is only 1 off - it showed 2017 on my very quick attempt to play with it.
One additional note to those installing it via TWRP itself - after selecting image flash , MAKE SURE you specify RECOVERY partition, not BOOT! Specifying BOOT will most likely have some less than desirable results.. :laugh:
NYLimited said:
Just as an aside, this version seems to correct (mostly) the date issue of previous TWRP versions for the V10. Versions before this one used to generate a default date (folder name) for the backup dating back to the 1970s as I recall.
This one has the correct month and day and time and the year is only 1 off - it showed 2017 on my very quick attempt to play with it.
One additional note to those installing it via TWRP itself - after selecting image flash , MAKE SURE you specify RECOVERY partition, not BOOT! Specifying BOOT will most likely have some less than desirable results.. :laugh:
Click to expand...
Click to collapse
I've passed on the date issue. Uncertain if he'll generate another build though.
famewolf said:
I've passed on the date issue. Uncertain if he'll generate another build though.
Click to expand...
Click to collapse
Seems that either nobody is using this version or nobody knows about it or they just have nothing to say..
Anyway, as you know, I have spent a fair amount of time recently working with this and installing it. A couple of observations that may be worth noting..
I double checked and I did set a screen timeout on TWRP. Previous versions would first, dim the screen, followed by turning it off completely. If you had the device near you on a desk while backing up the screen lighting up again when TWRP completed was a sure signal that it was finished.
This version of TWRP dims the screen but the screen is never turned off completely. A minor annoyance I suppose but something is different from previous versions.
During the /data partition backup I noted a (to me) new display in yellow: "Backups of data do not include any files in internal storage such as pictures or downloads"
Seriously? Is this something new? Certainly the display is but I always kinda relied on all that being backed up with /data and having the ability to restore them. This is a more serious issue for me which may make me consider going backward..
Thoughts?
NYLimited said:
Seems that either nobody is using this version or nobody knows about it or they just have nothing to say..
Anyway, as you know, I have spent a fair amount of time recently working with this and installing it. A couple of observations that may be worth noting..
I double checked and I did set a screen timeout on TWRP. Previous versions would first, dim the screen, followed by turning it off completely. If you had the device near you on a desk while backing up the screen lighting up again when TWRP completed was a sure signal that it was finished.
This version of TWRP dims the screen but the screen is never turned off completely. A minor annoyance I suppose but something is different from previous versions.
During the /data partition backup I noted a (to me) new display in yellow: "Backups of data do not include any files in internal storage such as pictures or downloads"
Seriously? Is this something new? Certainly the display is but I always kinda relied on all that being backed up with /data and having the ability to restore them. This is a more serious issue for me which may make me consider going backward..
Thoughts?
Click to expand...
Click to collapse
I use my v10 as my backup phone now. On my HTC U11 life when I make a nandroid it shows that it is not backing up files on internal storage. I think this is normal now on the latest version of twrp.
NYLimited said:
Seems that either nobody is using this version or nobody knows about it or they just have nothing to say..
Anyway, as you know, I have spent a fair amount of time recently working with this and installing it. A couple of observations that may be worth noting..
I double checked and I did set a screen timeout on TWRP. Previous versions would first, dim the screen, followed by turning it off completely. If you had the device near you on a desk while backing up the screen lighting up again when TWRP completed was a sure signal that it was finished.
This version of TWRP dims the screen but the screen is never turned off completely. A minor annoyance I suppose but something is different from previous versions.
During the /data partition backup I noted a (to me) new display in yellow: "Backups of data do not include any files in internal storage such as pictures or downloads"
Seriously? Is this something new? Certainly the display is but I always kinda relied on all that being backed up with /data and having the ability to restore them. This is a more serious issue for me which may make me consider going backward..
Thoughts?
Click to expand...
Click to collapse
On your last issue this is business as usual...twrp has NEVER backed up the internal SDCARD unless you selected the sdcard entry in the list of sections to be backed up. DCIM (pictures) and the Downloads folder/dir have never been included.
As to the dimming, you can check in settings to see if something can be configured however each person compiling twrp can set their own options as to how they want it to function. There is no guarantee or expectation that Person B is going to use the same options as Person A. You are of course free to compile your own copy configured the way you would prefer it to behave but the process was enough of a pain in the butt I just requested twrpbuilder to generate one as I kept getting errors. The process to compile it also appears poorly documented.
sabresfan said:
I use my v10 as my backup phone now. On my HTC U11 life when I make a nandroid it shows that it is not backing up files on internal storage. I think this is normal now on the latest version of twrp.
Click to expand...
Click to collapse
I kinda suspected that but that is, at best, a questionable choice since I don't even have the option to check or uncheck a selection for it. Not happy..
famewolf said:
On your last issue this is business as usual...twrp has NEVER backed up the internal SDCARD unless you selected the sdcard entry in the list of sections to be backed up. DCIM (pictures) and the Downloads folder/dir have never been included.
Click to expand...
Click to collapse
Not quite. INTERNAL is not the SD Card. Internal is emulated sd on /0. In TWRP if you tap select storage, for example, you can pick "internal" or "SD" for backup destination, as one example.
I keep a fair number of things in /Download - things I grab in my travels, things I save there for later use.. whatever. I'll have to device a Tasker module or something for copying all those to the actual SD card...
NYLimited said:
I kinda suspected that but that is, at best, a questionable choice since I don't even have the option to check or uncheck a selection for it. Not happy..
Not quite. INTERNAL is not the SD Card. Internal is emulated sd on /0. In TWRP if you tap select storage, for example, you can pick "internal" or "SD" for backup destination, as one example.
I keep a fair number of things in /Download - things I grab in my travels, things I save there for later use.. whatever. I'll have to device a Tasker module or something for copying all those to the actual SD card...
Click to expand...
Click to collapse
A fairly recent app/utility created by @kdrag0n called Tipatch brings a long-needed resolution to the table regarding "full backups" of Data using TWRP. In a nutshell, Tipatch installs to your Android device as a basic APK. Within the simple GUI, once root permissions are granted (In-Place Patching) Tipatch will decompile, patch, recompile and flash the patched TWRP to /recovery, effectively patching your TWRP build to backup the contents of Internal Storage (emulated SD card) as part of Data itself, so that backups will now include those Internal Storage contents such as downloads, photos, videos, game data, and other various files. I've tried it on this particular build of TWRP and it works without any issues. There are options to patch TWRP without root permissions as well. There are Windows, Mac & Linux versions available too. If you are patching TWRP on a device with an A/B partitioning scheme, the patched TWRP can be installed on both A & B using a one-click option. Of course, one insurmountable caveat to patching TWRP with Tipatch is that wiping Data now will also wipe Internal Storage (emulated SD card). In short, the utility works on pretty well all device types and chipset platforms (Exynos, Kirin, Snapdragon, MediaTek, etc.). The latest Tipatch update, v1.6, includes support for TWRP builds that use LZMA compression, and removes the now-misleading notification previously listed when backing up Data -- that Internal Storage (/data/media/ path / emulated SD card) contents are not backed up. Anyway guys, here is a link to the Tipatch Discussion & Support thread: https://forum.xda-developers.com/android/apps-games/app-twrp-tipatch-backup-internal-t3831217
The latest Tipatch v1.6 app is also available on the Play Store and many other app & apk repos for Android. Versions for Windows, Mac and Linux can be downloaded using the above link.