UT Installer packages

[stanwood]

Hi,
Just a question regarding UT Installer.
I read daily here several support requests from people who're not able to install UT correctly using the installer.
Most of the time they just forgot to read documentation... Installer says: "Dont worry it's easy"
However, it seems that people do mostly not proceed to the following steps:

. Activate developer mode
. Enable USB debugging
. Install ADB drivers
. Install fastboot

As result, UT image is not installed correctly (mostly locked on bootloader), and morevover it's than pretty hard to reset the phone to it's initial state.

So would it be possible to optimise UT installer integrating by default ADB and Fasboot packages as it's a snap software?

And as for Mac / Windows version, add links to download those elements?
Than we could add a few steps in the installation guide such as:
Did you activate developer mode? NEXT -> ADB + Fastboot packages are required to install UT on your device, please click here to install.... NEXT-> Please reboot your device in bootloader.... Next ->

So the main goal is to simplify as much as possible in an "all in one".
Does this idea make any sens?

Thank you for your feedbacks.

[libremax]

@stanwood May be a good question for next Q&A

[doniks]

I like your suggestion @stanwood!

I guess the packaging of the binaries would be "just work" (not saying it's trivial). Separate snap would be overkill, you could just stick the binaries into the installer. And for Mac/Win test whether communication is ok, otherwise provide a link for the user to download&install.

But the developer mode and usb debugging ... I wonder how to solve this. Maybe like this?! (Just thinking out loud)

User selects which OS they are currently running: UT or Android and based on that choice you get some pictures and instructions that show you how to configure it and at the end the installer tests with adb shell whether the connection works (and maybe try to detect the OS as a confirmation). Alternatively, I guess the user should be able to just skip that OS story and proceed with manually booted recovery or bootloader.

[UniSuperBox]

This question seemed interesting to me, because the installer should include these binaries. Maybe something else was going on? So I tested it out on Windows.

For this test, I installed the factory image on my Nexus 5 then issued fastboot oem lock to lock its bootloader. I also installed Windows on a brand new VM. This will give me the best chance to see the real installation process for a newcomer.

When starting the installer, you are presented with a prompt to install the Universal ADB driver. You need to go to the website, download and install the binary.

Now the adb binary is available at C:\Program Files (x86)\ClockworkMod\Universal Adb Driver\.

Trying to run adb in a command prompt, I recieve "adb is not recognized as an internal or external command...". The installer is also still asking me to install the Universal ADB driver. Maybe a reboot will solve that?

Nope, still asking me to install the driver myself. adb is still not available in a command prompt. However, looking at my AppData\Local folder, I find an interesting thing:

PS C:\Users\Dalton\AppData\Local\Temp\...\resources\app.asar.unpacked\platform-tools\win> dir
...
-a---- 4/3/2020 7:05 AM 2644992 adb.exe

And if I run this binary:

PS > .\adb devices
* daemon not running; starting now at tcp:5037

Looks like the installer does, indeed, include the adb binary. However, plugging in my device with USB debugging enabled and running the binary again reveals...

PS > .\adb devices
List of devices attached

PS >

Even though my device is attached and recognized in Device Manager as "Google Nexus ADB Interface," adb can't find it. Boy do I love Windows... Maybe I'll try a different driver. I'll remove the clockworkmod drivers and try again.

PS > .\adb devices
List of devices attached
[device id]	unauthorized

Oh, that was easier than I thought. Turns out Windows includes the adb drivers already, and installing another driver breaks them. I'll turn off debug mode and start the installer.

The first thing the installer asks you to do is enable developer mode on your device, so I'll do that.

At that point, I get a prompt to allow USB debugging for my computer on the phone. I tap "OK" to allow the process to continue.

Unfortunately, at this point I hit a known bug. Since debugging was not authorized, my device will not be detected. To fix this, I'll restart the installer.

I got an error from adb kill-server in the installer. Ugh. I'll reboot the PC and try again.

After the reboot, the installer detected my Nexus 5 connected with USB debugging enabled. Time to go through the installer with all defaults selected.

Since the device is bootloader locked, the installer asks if I would like to unlock it. I confirm the dialog. Once unlocked, the installer continues.

Strangely, the device boots with the "Installing Update" screen rather than the UBports Installer main menu. After a few seconds of this, the installer stopped due to the error mounting .../cache on /cache failed: Invalid argument. The device then rebooted to the Google logo.

After holding down the power and volume down buttons, then clicking "Recovery mode", I arrived at the correct screen. I'll click "Try again" on the installer.

This time, the installer asked me to reboot to bootloader and installed the recovery again. Once that was finished, the device rebooted to the UBports Recovery main menu like it was supposed to and the installer continued.

Device rebooted and started installing the update. We're done. Installation successful.

Some takeaways from this experience:

• The Nexus 5 appears to have problems with booting the recovery right after the bootloader is unlocked. We may want to reboot the bootloader before continuing in the future. This will prevent errant commands from reaching recovery. (ninja edit: It doesn't matter if the recovery bootloader is rebooted. The recovery will always try to format partitions or something after oem unlock is issued, causing the reboot to the blank logo)
• Installing any ADB drivers is unnecessary on the newest version of Windows 10. We should stop recommending people do this.

[stanwood]

@UniSuperBox Thank you for this complete report. Awesome! By reproducing the whole process we do better understand the pain that new (and newbie) users can encountering.

[doniks]

@UniSuperBox said in UT Installer packages:

ninja edit: It doesn't matter if the recovery is rebooted. The recovery will always try to format partitions or something after oem unlock is issued, causing the reboot to the blank logo

does it make a difference whether you fastboot boot recovery.img instead of fastboot flash recovery recovery.img && fastboot reboot-recovery?

[UniSuperBox]

@doniks

Nope, it's all the same.

[flohack]

@UniSuperBox On Windows 7 for example you still need to install the USB drivers. adb comes with the installer, but the Android USB drivers are needed. Dont know how Windows 10 is doing with that.

Also being Adminsitrator or not might contribute to a lot of issues. Using the installer in Windows can be really apinful, but there is rarely a better idea and we cannot ship the drivers easily. Except that we write our own

[UniSuperBox]

@Flohack, Windows 7 is out of support. I think it's fair for us to say "if you're still using it, you need to figure out which ADB drivers will work with your device and setup."