4 ms·

Granted we understand "brick" to mean the device cannot boot, but this comes pretty damn close on some phones, it seems. > "After setting the image in question

Granted we understand "brick" to mean the device cannot boot, but this comes pretty damn close on some phones, it seems. > "After setting the image in question as a wallpaper, the phone immediately crashed. It attempted to reboot, but the screen would constantly turn on and off, making it impossible to pass the security screen," he noted. > Restarting the device in safe mode (by holding down the volume button during boot-up) did not fix the issue." If restarting doesn't fix it, and not even safe mode will allow you to change the wallpaper to get around it, what method of recovery is left for the affected user? Factory reset from recovery mode?

el_programmador 6y ago
Perhaps the only way to fix it would be get into fastboot mode and enable USB debugging, then look for that arcane settings file on the file-system which your OEM decided to use for configuring wall-papers and fix that file. I see no other way.
- zozbot234 6y ago
  Wouldn't that settings file be on the user data partition, which is encrypted and thus not normally accessible in recovery mode?
zozbot234 6y ago
It depends. If the bootloader is unlocked, they could boot a custom recovery and alter the system image to try and insert a workaround (such as deleting the buggy library and dealing with the resulting breakage). If the data partition is fully unencrypted, they can even delete the offending file straight from recovery. On a bootloader-locked, fully encrypted device (the default nowadays) they'd be SOL and have to use the stock recovery or bootloader to force a factory reset - not only would that involve obvious data loss, but they would even have to deal with FRP afterwards.
- f1refly 6y ago
  You can also delete the offending file with a fully encrypted main storage, since twrp supports decrypting and mounting the storage on demand.
  - zozbot234 6y ago
    > since twrp supports decrypting and mounting the storage on demand. It advertises that support, but I've never really seen it work. It seems that modern FDE on Android is such that you can only really "decrypt" from the system environment itself, not from different code - and it's not clear how to fix this.
    - gruez 6y ago
      >It advertises that support, but I've never really seen it work works for me. it really depends on whether your TWRP distribution implemented it properly. AFAIK android phones don't have a mechanism to bind encryption keys to a system state (similar to sealing keys to PCRs for TPMs on PCs), so I don't think your theory is correct.
dang 6y ago
(We detached this subthread from https://news.ycombinator.com/item?id=23404703 https://news.ycombinator.com/item?id=23404703, since that was just a terminological dispute and we changed the title to defuse it, but this subthread contains more information)
Polylactic_acid 6y ago
Last time I checked it was possible to factory reset the device from the bootloader menu thing. It causes the device to go in to an anti theft mode where you have to log in to the last google account the device was used with but it should be able to solve this issue.

el_programmador 6y ago

Perhaps the only way to fix it would be get into fastboot mode and enable USB debugging, then look for that arcane settings file on the file-system which your OEM decided to use for configuring wall-papers and fix that file. I see no other way.

zozbot234 6y ago
Wouldn't that settings file be on the user data partition, which is encrypted and thus not normally accessible in recovery mode?

zozbot234 6y ago

It depends. If the bootloader is unlocked, they could boot a custom recovery and alter the system image to try and insert a workaround (such as deleting the buggy library and dealing with the resulting breakage). If the data partition is fully unencrypted, they can even delete the offending file straight from recovery. On a bootloader-locked, fully encrypted device (the default nowadays) they'd be SOL and have to use the stock recovery or bootloader to force a factory reset - not only would that involve obvious data loss, but they would even have to deal with FRP afterwards.

f1refly 6y ago
You can also delete the offending file with a fully encrypted main storage, since twrp supports decrypting and mounting the storage on demand.
- zozbot234 6y ago
  > since twrp supports decrypting and mounting the storage on demand. It advertises that support, but I've never really seen it work. It seems that modern FDE on Android is such that you can only really "decrypt" from the system environment itself, not from different code - and it's not clear how to fix this.
  - gruez 6y ago
    >It advertises that support, but I've never really seen it work works for me. it really depends on whether your TWRP distribution implemented it properly. AFAIK android phones don't have a mechanism to bind encryption keys to a system state (similar to sealing keys to PCRs for TPMs on PCs), so I don't think your theory is correct.

dang 6y ago

(We detached this subthread from https://news.ycombinator.com/item?id=23404703 https://news.ycombinator.com/item?id=23404703, since that was just a terminological dispute and we changed the title to defuse it, but this subthread contains more information)

Polylactic_acid 6y ago

Last time I checked it was possible to factory reset the device from the bootloader menu thing. It causes the device to go in to an anti theft mode where you have to log in to the last google account the device was used with but it should be able to solve this issue.