2

In short: I used SecondScreen app and changed the screen resolution to a bad one. The app autostarts and changes my resolution automatically. This causes a boot loop. What can I do?

In detail: This is what I did on my non-rooted Poco F1:

  1. installed Second Screen
  2. I gave it the permissions it needed, using ADB via my PC, and other permissions it asked via UI .
  3. I chose some big resolution.
  4. I shut down the PC, before disconnecting the phone from PC.
  5. The phone was stuck in the weird resolution, so I restarted it.
  6. it is now in an infinite boot loop. :(

It starts booting normally, but than the screen resolution becomes bad (see the photo), and, before finishing the booting, it restarts again :(

At last, the recovery menu is reached and it gives me 3 options.

  1. Reboot (this is the restarting loop that brings me back to the same menu)
  2. Access via MI PC Suite: I cannot access the device this way; the device is not detected. It never sees the device, except in Fastboot it says: "Try connect in normal mode first then switch", but I cannot enter "normal" mode.
  3. Wipe the data (if at all possible, I would prefer to avoid losing the data).

What I know:

Codename:       beryllium
Bootloader:     locked
Anti version:       1

I can get my phone into FASTBOOT and adb sideload modes, but unfortunately not in the "normal" adb mode. Can I uninstall the app somehow, stop it from autostart, undo its damage, or anything to fix the phone without losing the data?

A non boot-loop fix was done by typing:

From adb shell, type:
wm size reset
wm density reset

but I cannot find out how to do that from FASTBOOT or sideload....

this is what I see before the phone restarts again

16
  • you mentioned adb is enabled therefore you should be able to access via adb while device is booting
    – alecxs
    Mar 11 at 15:50
  • alas, only adb "sideloaded". Not the full list of commands :(. It says: error:closed, when I try e.g. adb shell wm size reset. ... adb push seems to work, so I might be able to do this, but I am not sure how: "You talking about scripts made me think of the build.prop! I changed the density down to 220 using adb push so the phone was low res but functional, and then created a tasker task that changed the resolution back to normal, and changed the DPI back to 480" EDIT: do you mean I can do some stuff in the half a second when the booting animation is shown?
    – Mil
    Mar 11 at 15:58
  • 1
    adb sideload is active e.g. when you are in recovery, but alecxs suggested to use adb while your device is booting and before the boot-loop happens. At that stage for a short time adb should be available. Therefore pack these commands in a script and try to execute them while your device is booting.
    – Robert
    Mar 11 at 16:04
  • I tried putting this in myScript.bat: adb shell wm size reset adb shell wm density reset adb shell wm overscan reset and then repeatedly reentering myScript.bat while my phone is restarting and attached to the USB. It does not seem to reach the normal adb :(
    – Mil
    Mar 11 at 16:31
  • 1
    Fixed! Starting the phone from discharged enabled ADB access! I imagine the phone does a fuller/slower reset when discharged. I did have USB debugging after all, but the boot loop was too fast to allow ADB access. At one point in the "good" bootloop it shows a nice round (loading) circle, and that is when I got ADB access. There is little time before "bad" bootloop is resumed. Prep: adb devices 1st: uninstalled the app adb shell pm list packages | grep second Uninstall the app: pm uninstall -k --user 0 nameOfTheApp 2nd: adb shell wm size reset adb shell wm density reset
    – Mil
    Mar 15 at 15:02
2

I fixed it* by letting the phone bootloop until fully discharged. I then plugged the phone into the computer and turned the phone on as soon as it charged enough to allow me this. At that point there is a brief window where full ADB access is possible, but only because I did have USB debugging enabled after all, but the bootloop was too fast to allow full ADB access at any point.

I imagine the phone does a fuller/slower reset when discharged. At one point in the "good" bootloop it shows a nice, round, "loading" circle, and that is when I got ADB access. There is little time before "bad" bootloop is resumed.

  1. This is what I kept entering in command line during the "loading" circle boot phase, until it finally indicated that I have the full ADB access by showing the alphanumeric ID of the phone and "device" after it:

    adb devices
    

List of devices attached

    03464364da54  device
  1. Uninstall the culprit app called SecondScreen, by first finding its proper name, and then uninstalling it via adb:

    adb shell pm list packages | grep second 
    
    pm uninstall -k --user 0 nameOfTheAppReturnedByTheAboveCommand 
    
  2. This was not enough, and the phone entered the "bad" bootloop again, so I discharged it again and reset the screen size and density (DPI I believe):

    adb shell wm size reset
    
    adb shell wm density reset
    

It works like new now.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.