[Sony Xperia XZ1 Compact Guides, News, & Discussion] raphidae:
That was probably my problem, but where are you getting 6.2.1 RR for lilac and the corresponding encrypted boot.img anyway? You're the second person referring to it, but Androidfilehost dot com only has 6.2.0 and the latest bootRRencrypt.img's date on there corresponds to 6.1.0. Both links in the first post are dead (404). There's no downloads for the ZX1 Compact on the Resurrection Remix OS website at all. Can you tell me where to find it, or wetransfer me the 6.2.1 zip & encrypted boot.img at r@phid.ae please? I've been searching for this version to no avail :(

I changed the boot.img in the 6.2.0 zip with Android Image Kitchen (changed "encryptable" to "fileencryption=ice" in fstab.lilac) and got it to work, FINALLY. However now another problem: camera only makes solid green pictures.

As the opening post says this can be caused by old firmware, am I probably correct in thinking that this is can also be caused by NEW sony firmware? Because I tried out the Android Pie (47.2) Sony Experia firmware and I figure the 6.2.0 RR build is expecting some version of 47.1? So what now, re-flash a 47.1 version? Where to get this? XperiFirm only offers 47.2 for my region, and should region/customisation not matter then there are several versions of 47.1.... Which one to flash? What version corresponds to the "blobs" used in RR 6.2.0? I now do have encryption, but no camera :(

---------- Post added at 03:09 PM ---------- Previous post was at 02:41 PM ----------

BTW, regarding encryption:

What I am wondering is, why not fix the bug that is preventing the phone from encrypting via the option in settings, completely preventing any need for messing with different boot.img files? According to logcat the problem with the current fstab flag "encryptable=ice" in the RR build (and thus the fact that encrypting the phone from UI is hangs at 00:00 and then after restarts ends in a bootloop that keeps asking you to factory reset, but that also doesn't work) is the fact that it can't write the volume encryption footer for Full Disk Encryption, which it is assuming is a file called "ice". In the source the parameter to "encryptable" is checked for a starting /, and if it has none throws an error.

The error from logcat is: 11-28 15:28:33.393 672 3129 E Cryptfs : Unexpected value for crypto key location (I looked in the source, and its expecting a parameter, so encryptable=/location/to/footer

I actually prefer FDE over the newer File-Based-Encryption/FBE (which fileencryption=ice) because it's easier for me to check that it's working and maybe audit it (it's based on LUKS, which I am familiar with), a possible recovery is a LOT easier later and more importantly: Using the CLI I can set a very long/strong passphrase for bootup and thus the encryption, but keep a relatively simple PIN for the lock screen (which is limited to 16 chars anyway). I won't boot the phone often, but will enter the PIN all day long. Brute forcing even a 8 digit PIN is much easier than brute forcing a much longer and more complex password.

I have business information on my phone, so it's important that it can't be extracted if I lose it or it it's stolen, so I think encryption at rest is very important.

There is an option "encryptable=footer", which should write the encryption key footer at the first 16kb of the filesystem (which may also be the default if there is no parameter). But this doesn't work either, because at the point the encryption is started the /dev/block/bootdevice/by-name/userdata partition does not have the required 16kb free, so it errors out with an error (something like: Cryptfs: footer overlaps with existing filesystem, in-place encryption is not possible, I didn't save it) and just restarts. So at least this may be a better option to put in the fstab.lilac for unencrypted builds, as it does not result in a boot loop when an user tries to encrypt the phone. It will just fail and restart the UI and leave the phone unchanged. So no more boot loop at least :)

To make the "encryptable=footer" option work, I would need to make the ext4 filesystem 16kb smaller than the /dev/block/bootdevice/by-name/userdata partition (leave 16kb unused in front or at the rear, I forget which), now the ext4 filesystem fills the entire /dev/block/bootdevice/by-name/userdata partition.

Now, this encryption footer is not sensitive data, so it can be stored anywhere. I've seen older Sony ASOP source that still used FDE use "encryptable=/dev/block/bootdevice/by-name/encryption", but I haven't tried that, because I would guess that this partition does not exist anymore in newer versions. Does anyone know where the filesystem partitions and their sizes are defined? Somewhere there should be a specification on how the internal memory is partitioned where I can either shorten the ext4 on /dev/block/bootdevice/by-name/userdata filesystem by the needed 16kb so the footer can be written, or shrink any filesystem (probably still userdata) that can miss a 16kb and create a new 16k /dev/block/bootdevice/by-name/encryption to store the encryption footer on.

Anyone have tips where to find the internal storage geometry? I would be happy to figure out how to get this to work and share the details with russell5 so that people that want can choose to encrypt their phone in a future build, and those that don't only lose 16kb of userdata.