Upgrading Nexus 4 to Android 4.4 on Linux
Probably, I'm not alone in my unwillingness to wait for the OTA update of the phone. It is interesting to see what's new in the version of Android 4.4. Below I will try to describe in as much detail as possible the process of updating the firmware in Linux systems. I hope this can be useful to someone, since most of the instructions are almost exclusively for Windows. I will also try to describe the unobvious rake for some revisions of the Nexus 4.
After reading the manuals, I pulled out the Kitkat image for the Nexus 4 and the Android SDK with all the tools. However, to my surprise, the problem arose where I did not expect it - the drivers for Windows 7 x64 were not detected. First I tried to install the driver package from the Android SDK (just mention the Google USB Driver Package for installation). Not recognized. Then I tried to pull out the driver package only from developer.android.com/sdk/win-usb.html . The result is the same. To clear my conscience, I installed Universal Naked Driver 0.72 from here w3bsit3-dns.com/forum/dl/post/3529212/Universal_Naked_Driver_0.72.zip . In a 32-bit system, the result is the same.
The phone was purchased directly during the attraction of unprecedented generosity on Google Play through a forwarder. It was bought 2 phones 8 Gb version for me (well, I do not have the need to store large amounts of multimedia) and 16 Gb version for my brother. I was extremely surprised when his phone was immediately identified in the system. Immediately there was a thought about the device ID.
Each USB device has its own unique Vendor ID. These identification numbers are issued by the non-profit organization USB Implementers Forum (USB-IF). Inside the Vendor device IDs are categorized by Product ID. So, as the manufacturer of Nexus is Google, all its devices have a VID of 18d1. PID was a bit more complicated. If you look inside android_winusb.inf, on which the operating system is oriented, we can see the list of devices for which this driver is intended.
')
Nexus 4 is not mentioned, but the 16 Gb version matches the ID numbers with Google Nexus (generic). However, everything turned out wrong with my phone. The VID was d001, which prevented the system from seeing the driver for it.
This was followed by a somewhat illogical decision to try updating the firmware in a Linux environment, since the kernel already includes the necessary drivers for the phone. Deployed Kubuntu 13.10 to get a fresher core. Further, all the instructions below:
1) On the phone, in the “For Developers” section, we enable USB debugging.
2) Determine the PID: device VID
We are interested in this particular fragment - 18d1: d001 Google Inc.
2) Linux won't just give us access to our device. First you need to create rules for udev (more about the system ru.wikipedia.org/wiki/Udev ).
Create a file with the rules for our Nexus:
We enter there the following lines:
#Nexus 4
3) Change the attributes:
4) Restart udev:
5) Create the androiddev group and add the current user:
This is necessary for full access to the recording and execution of our device.
6) Add the necessary tools to work (you do not need a full-featured SDK if you do not plan to develop on the phone)
7) For normal operation, starting from version 4.2, you need to confirm on the phone itself that this PC is trusted for debugging. When you start working with adb, do not forget to positively answer this question on your phone. Check the visibility of the device:
Everything went well. Otherwise (the old version of adb, untrusted PC, etc.) will be something like:
8) Restart the phone in fastboot mode. On the Nexus 4, this is achieved by pressing simultaneously the increase and decrease of sound along with power. You can also send from the console adb restart fastboot. Check the list of connected devices using lsusb and find that the product id has changed! So again you need to edit /etc/udev/rules.d/51-android.rules. In my case it was 4ee0.
Reboot udev.
9) In fastboot mode, adb does not work, so we check the list of connected devices as follows:
If instead of your device, Waiting for devices is hanging, then you need to choose the correct Vendor ID / Product ID in the udev config.
10) Downloading the very latest image from developers.google.com/android/nexus/images
Unpack In my case there should be the following files:
11) Next we have two ways. The first is unlocking the bootloader with a system wipe and full firmware. The second is an update of the existing system.
1) Phone in fastboot mode.
2) Check that the phone is visible fastboot devices
3) Unlock the bootloader:
We agree on the phone with the data wipe
4) Full firmware. The easiest way is to run a ready-made flash-all.sh script.
5) If everything went well, the phone eventually turns on pristine clean with a new version.
1) Switch to the bootloader mode from fastboot. To do this, select the corresponding item with the volume rocker and turn it on with the power button.
2) As a result, we admire the picture of the nailed android with an open stomach and ... Everything. In my version did not work further. The idea at this stage is to simultaneously press the volume up and power to open the menu where “Apply update from ADB” is selected. My phone just turned on. But let's say you succeeded.
3) On the computer in the command window, enter the following command:
where xxxxxxxx.zip is the name of the zip file with the firmware. After that, a regular update will take place.
Successfully switched to ART from Dalvik. It seems that everything has become much faster to open, but he hasn’t conducted accurate measurements. The sensor has become nicer and more accurate. In general, there are no obvious changes on the surface. ART should be tested, but so far nothing is falling. Recompilation took about 20 minutes for 120+ applications.
Ps. Remember that any careless actions can lead to a “brick” state. The author is not responsible for incorrect user actions. Please always read the instructions on the relevant resources.
We come on a rake in Windows 7 x64 / x86
After reading the manuals, I pulled out the Kitkat image for the Nexus 4 and the Android SDK with all the tools. However, to my surprise, the problem arose where I did not expect it - the drivers for Windows 7 x64 were not detected. First I tried to install the driver package from the Android SDK (just mention the Google USB Driver Package for installation). Not recognized. Then I tried to pull out the driver package only from developer.android.com/sdk/win-usb.html . The result is the same. To clear my conscience, I installed Universal Naked Driver 0.72 from here w3bsit3-dns.com/forum/dl/post/3529212/Universal_Naked_Driver_0.72.zip . In a 32-bit system, the result is the same.
The phone was purchased directly during the attraction of unprecedented generosity on Google Play through a forwarder. It was bought 2 phones 8 Gb version for me (well, I do not have the need to store large amounts of multimedia) and 16 Gb version for my brother. I was extremely surprised when his phone was immediately identified in the system. Immediately there was a thought about the device ID.
A couple of words about USB identifiers
Each USB device has its own unique Vendor ID. These identification numbers are issued by the non-profit organization USB Implementers Forum (USB-IF). Inside the Vendor device IDs are categorized by Product ID. So, as the manufacturer of Nexus is Google, all its devices have a VID of 18d1. PID was a bit more complicated. If you look inside android_winusb.inf, on which the operating system is oriented, we can see the list of devices for which this driver is intended.
;Google Nexus One %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02&MI_01 %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_4E11 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E12&MI_01 ;Google Nexus S %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_4E21 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E22&MI_01 %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_4E23 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E24&MI_01 ;Google Nexus 7 %SingleBootLoaderInterface% = USB_Install, USB\VID_18D1&PID_4E40 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E42&MI_01 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4E44&MI_01 ;Google Nexus Q %SingleBootLoaderInterface% = USB_Install, USB\VID_18D1&PID_2C10 %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_2C11 ;Google Nexus (generic) %SingleBootLoaderInterface% = USB_Install, USB\VID_18D1&PID_4EE0 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4EE2&MI_01 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4EE4&MI_02 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_4EE6&MI_01 ')
Nexus 4 is not mentioned, but the 16 Gb version matches the ID numbers with Google Nexus (generic). However, everything turned out wrong with my phone. The VID was d001, which prevented the system from seeing the driver for it.
We are looking for a new rake in Linux
This was followed by a somewhat illogical decision to try updating the firmware in a Linux environment, since the kernel already includes the necessary drivers for the phone. Deployed Kubuntu 13.10 to get a fresher core. Further, all the instructions below:
1) On the phone, in the “For Developers” section, we enable USB debugging.
2) Determine the PID: device VID
meklon@meklon-kubuntu:~$ lsusb Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 18d1:d001 Google Inc. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 003: ID 09da:9033 A4 Tech Co., Ltd X-718BK Optical Mouse Bus 004 Device 005: ID 046d:c225 Logitech, Inc. G11/G15 Keyboard / G keys Bus 004 Device 004: ID 046d:c221 Logitech, Inc. G11/G15 Keyboard / Keyboard Bus 004 Device 002: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub We are interested in this particular fragment - 18d1: d001 Google Inc.
2) Linux won't just give us access to our device. First you need to create rules for udev (more about the system ru.wikipedia.org/wiki/Udev ).
Create a file with the rules for our Nexus:
sudo nano /etc/udev/rules.d/51-android.rules We enter there the following lines:
#Nexus 4
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d001", MODE="0660", GROUP="androiddev", SYMLINK+="android%n"3) Change the attributes:
chmod a+r /etc/udev/rules.d/51-android.rules 4) Restart udev:
sudo service udev restart 5) Create the androiddev group and add the current user:
sudo groupadd androiddev && sudo useradd -G androiddev username This is necessary for full access to the recording and execution of our device.
6) Add the necessary tools to work (you do not need a full-featured SDK if you do not plan to develop on the phone)
sudo add-apt-repository ppa:nilarimogard/webupd8 sudo apt-get update sudo apt-get install android-tools-adb android-tools-fastboot 7) For normal operation, starting from version 4.2, you need to confirm on the phone itself that this PC is trusted for debugging. When you start working with adb, do not forget to positively answer this question on your phone. Check the visibility of the device:
# adb devices List of devices attached xxxxxxxxxxxxxxx device Everything went well. Otherwise (the old version of adb, untrusted PC, etc.) will be something like:
# adb devices List of devices attached xxxxxxxxxxxxxxx offline 8) Restart the phone in fastboot mode. On the Nexus 4, this is achieved by pressing simultaneously the increase and decrease of sound along with power. You can also send from the console adb restart fastboot. Check the list of connected devices using lsusb and find that the product id has changed! So again you need to edit /etc/udev/rules.d/51-android.rules. In my case it was 4ee0.
#Nexus 4 SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d001", MODE="0660", GROUP="androiddev", SYMLINK+="android%n" SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee0", MODE="0660", GROUP="androiddev", SYMLINK+="android%n" Reboot udev.
9) In fastboot mode, adb does not work, so we check the list of connected devices as follows:
fastboot devices If instead of your device, Waiting for devices is hanging, then you need to choose the correct Vendor ID / Product ID in the udev config.
10) Downloading the very latest image from developers.google.com/android/nexus/images
Unpack In my case there should be the following files:
bootloader-mako-makoz20i.img
radio-mako-m9615a-cefwmazm-2.0.1700.84.img
image-occam-krt16o.zip
flash-all.sh
11) Next we have two ways. The first is unlocking the bootloader with a system wipe and full firmware. The second is an update of the existing system.
First option:
1) Phone in fastboot mode.
2) Check that the phone is visible fastboot devices
3) Unlock the bootloader:
fastboot oem unlock We agree on the phone with the data wipe
4) Full firmware. The easiest way is to run a ready-made flash-all.sh script.
sudo sh flash-all.sh 5) If everything went well, the phone eventually turns on pristine clean with a new version.
The second option:
1) Switch to the bootloader mode from fastboot. To do this, select the corresponding item with the volume rocker and turn it on with the power button.
2) As a result, we admire the picture of the nailed android with an open stomach and ... Everything. In my version did not work further. The idea at this stage is to simultaneously press the volume up and power to open the menu where “Apply update from ADB” is selected. My phone just turned on. But let's say you succeeded.
3) On the computer in the command window, enter the following command:
adb sideload xxxxxxxx.zip where xxxxxxxx.zip is the name of the zip file with the firmware. After that, a regular update will take place.
Epilogue
Successfully switched to ART from Dalvik. It seems that everything has become much faster to open, but he hasn’t conducted accurate measurements. The sensor has become nicer and more accurate. In general, there are no obvious changes on the surface. ART should be tested, but so far nothing is falling. Recompilation took about 20 minutes for 120+ applications.
Ps. Remember that any careless actions can lead to a “brick” state. The author is not responsible for incorrect user actions. Please always read the instructions on the relevant resources.
Source: https://habr.com/ru/post/202876/
All Articles