How to do things manually: USB Driver installation, ADB configuration, rooting

[loko]

PREFACE

Some time ago, friends asked for my help to configure their first Android devices. One option was to help them in person, spending a couple of hours with each one of them. Another option was to spend some hours writing a guide, then simply give it to anyone who asked for my help. While the first option seemed more direct, I would probably have to do this all over again and again, so I decided to opt for the second one. Recently, another friend asked for my help. Instead of giving this guide to him privately, I decided to share it with the community for anyone who may find it helpful. Nowadays it seems that there is a lot of information floating around. Anyway, there is nothing wrong about sharing just another guide.

This guide is addressed to anyone who prefers doing things manually, keeping as much control as possible. It is highly not recommended for people who like to find the easiest and quicker way to complete any task and do not really care about what is going underneath.


INTRODUCTION

As far as the appropriate Android device driver installation is concerned, there is a lot of information around, but hardly concentrated in extensive guides with detailed information. Most of the people sadly suggest 3rd party device drivers or proprietary adware software for convenience, which, as usual, install additional applications and services to the system.

As far as the use of the Android SDK Platform-tools is concerned, simple instructions on how to setup a minimum working installation of the Android SDK Platform-tools cannot be easily found. Most of the people sadly suggest installing the whole Android SDK, saying that it can be handy in the future. It is a real pain installing the whole Android SDK in multiple installations and virtual machines, just to use adb and fastboot.

Last but not least, as far as the actual Android device configuration is concerned, if you like to have maximum control over your device's operation, you want to make as many configurations as possible manually, using the adb shell. Most of the people sadly suggest using automated rooting tools running directly on the device or using the adb shell. Most of these methods are supposed be harmless (and are indeed), but some of them make some configurations to the system which have to be altered afterwards, according to your liking. Anyway, using these automated tools does not leave the feeling of satisfaction you are getting when you do things yourself, especially in Android devices that have looser security and can be completely manually configured.


DISCLAIMER

You may use any information found in this guide at your own risk.
This guide is not meant to be a professional one.
You may find this guide too long and/or boring.
You do not have to like this guide or read it if you are uninterested.


CONTENTS

PART 1: How to manually install appropriate Android USB Drivers in Windows
PART 2: How to manually uninstall Drivers in Windows
PART 3: How to manually install Android SDK Platform-tools
PART 4: How to manually root your Android device using ADBs

[loko]

How to manually install appropriate Android USB Drivers in Windows

If there are no dedicated device drivers for your Android device, in order to enable ADB usage you are obliged to find and install an appropriate device driver. If you want to have control over what is installed in your computer, you probably want to avoid the option of using any 3rd party device drivers and especially any proprietary adware software. The generic Google USB Driver is appropriate for any Android device, but cannot be automatically used because it includes references only to a few Android devices. The only way of keeping your computer free of any potentially unwanted software is to use a manually modified version of the generic Google USB Driver that has an extra reference to your specific Android device. After all, most of the 3rd party solutions are based on modified versions of the generic Google USB Driver, probably old and outdated ones. So, the best thing to do is to download the latest version of the generic Google USB Driver and manually modify it to include a reference to your specific Android device.

If you want more information on this topic, keep reading this section.


When you connect any device to a Windows computer, it shows up in the Device Manager. If an appropriate device driver that matches the connected Device Hardware Id cannot be automatically found and installed, Windows will ask for a device driver. If you do not provide one, you cannot access the device.

This means that if you connect an Android device to a Windows computer, an appropriate device driver has to be installed, in order to enable usage of the Android SDK Platform-tools (adb, fastboot). The main problem is that there are no dedicated device drivers for most of the Android devices.

You do not have to use any 3rd party device drivers or proprietary adware software if there are no dedicated device drivers for your Android device.

Just download Google USB Driver (Google it or visit Google USB Driver | Android Developers and download latest_usb_driver_windows.zip from the provided link).

Extract the ZIP file in a folder of your choice, navigate there, and open android_winusb.inf in a text editor.

Under the section [Google.NTx86] and/or [Google.NTamd64] for 32-bit and/or 64-bit Windows respectively add a single or multiple lines with the required Device Hardware Ids of your Android device, in the form of:

%SingleBootLoaderInterface% = USB_Install, USB\VID_XXXX&PID_XXXX
%SingleAdbInterface%        = USB_Install, USB\VID_XXXX&PID_XXXX
%CompositeAdbInterface%     = USB_Install, USB\VID_XXXX&PID_XXXX&XXXX

where USB\VID_XXXX&PID_XXXX or USB\VID_XXXX&PID_XXXX&XXXX is the Device Hardware Id of your Android device as it appears in the Device Manager, when your Android device is connected to your computer.

If you do not know how to find the Device Hardware Id of your device, open your Windows Device Manager, connect your device, browse and find that device under the corresponding device type (maybe under "Other devices"), double click (or right click and select "Properties") on the desired device name, then go to the Details tab, where you can see its corresponding Properties, including the Device Instance Id. You may open the Property drop down list, and select Hardware Ids to get simpler Values than the Device Instance Id. Select the desired Value, press Ctrl-C to copy it and paste it in a text editor. If needed, trim the unwanted rightmost part of the string and create the wanted Device Id, in a form similar to the ones used in the original android_winusb.inf file.

Note that every Android device does not have only a single Device Hardware Id. The Device Hardware Id of your Android device changes according to its status (e.g. Bootloader, Recovery or Android System). If you want to be able to access your device under any of these statuses, you have to include multiple lines with all the corresponding references you need.

For example, if you want to use fastboot under the Bootloader, you have to enter the Bootloader in your Android device, find the corresponding Device Hardware Id as it appears in the Device Manager, include it in the android_winusb.inf file, install the modified Google USB Driver and then you will be able to use fastboot whenever you enter the Bootloader in your Android device.

Similarly, if you want to use adb under the Recovery, if supported, you have to enter the Recovery in your Android device, find the corresponding Device Hardware Id as it appears in the Device Manager, include it in the android_winusb.inf file, install the modified Google USB Driver and then you will be able to use adb whenever you enter the Recovery in your Android device.

Do not also forget, that to use adb while your Android device is in the Android System, you have to enable USB debugging in your device's developer options settings, find the corresponding Device Hardware Id as it appears in the Device Manager, include it in the android_winusb.inf file, install the modified Google USB Driver and then you will be able to use adb whenever your Android device is in the Android System and you have enabled USB debugging.

If you want your device to be displayed in the Windows Device Manager using a dedicated name of your taste, different than the generic ones used in the original form, you can use any Device Name (left part of the equation) you like, either by writing the actual Device Name you like directly in place, or by inserting a new string in the [Strings] section and refer to it.

It is recommended that you delete or comment (by adding a semicolon ";" prefix) all other device references under the [Google.NTx86] and [Google.NTamd64] sections (e.g. the original "Google Nexus One", "Google Nexus S", "Google Nexus 7", "Google Nexus Q" and "Google Nexus (generic)" references), since you will be making a modified thus unsigned Setup Information file, which you do not want to be used by the originally referenced devices.

In the [Strings] section you may also alter the "Android Device" ClassName under which your device will be displayed in the Windows Device Manager.

You must inspect the layout of the original Setup Information file to understand the formatting being used, as any additions to the original file must be made according to the same valid formatting.

Example for a XYZ Android device having a Device Hardware Id "USB\VID_1234&PID_5678":

[Google.NTx86]

%SingleAdbInterface%        = USB_Install, USB\VID_1234&PID_5678


[Google.NTamd64]

%SingleAdbInterface%        = USB_Install, USB\VID_1234&PID_5678

Example for a XYZ Android device having a Device Hardware Id "USB\VID_1234&PID_5678&MI_01":

[Google.NTx86]

%CompositeAdbInterface%     = USB_Install, USB\VID_1234&PID_5678&MI_01


[Google.NTamd64]

%CompositeAdbInterface%     = USB_Install, USB\VID_1234&PID_5678&MI_01

or using additional comments to make device entries more clear

[Google.NTx86]

;My XYZ Android device's description
%CompositeAdbInterface%     = USB_Install, USB\VID_1234&PID_5678&MI_01


[Google.NTamd64]

;My XYZ Android device's description
%CompositeAdbInterface%     = USB_Install, USB\VID_1234&PID_5678&MI_01

Note that by using the generic %CompositeAdbInterface% string, your device will be named using the corresponding entry in the [Strings] section, i.e. "Android Composite ADB Interface". If you want to use a dedicated name of your taste, either write the actual Device Name you like directly in place, or insert a new string in the [Strings] section and refer to it.

For example, if you want your XYZ Android device to be named as "XYZ Composite ADB Interface", you can either use only

[Google.NTx86]

;My XYZ Android device's description
XYZ Composite ADB Interface = USB_Install, USB\VID_1234&PID_5678&MI_01


[Google.NTamd64]

;My XYZ Android device's description
XYZ Composite ADB Interface = USB_Install, USB\VID_1234&PID_5678&MI_01

or use the following combination

[Google.NTx86]

;My XYZ Android device's description
%XYZCompositeAdbInterface%  = USB_Install, USB\VID_1234&PID_5678&MI_01


[Google.NTamd64]

;My XYZ Android device's description
%XYZCompositeAdbInterface%  = USB_Install, USB\VID_1234&PID_5678&MI_01

AND

[Strings]
XYZCompositeAdbInterface    = "XYZ Composite ADB Interface"

Save the modified android_winusb.inf file in place. If you want to save the file using another name, make sure that you save it in the same folder as the original one and that it has an "inf" extension. In that case, you have to pay more attention especially if you use the "Hide extensions for known file types" Folder Option in Windows. The correct file type should be "Setup Information".

You may now use this modified Google USB Driver when Windows will ask for a device driver for your Android device. To force Windows to ask for a device driver for your Android device, you may have to unplug and replug your device, or open your Windows Device Manager, browse and find that device under the corresponding device type (maybe under "Other devices"), right click and select "Update Driver" on the desired device name. You have to select "Install from a list or specific location (Advanced)" when prompted for a device driver, then check "Include this location in the search" and Browse to the folder where you saved the modified android_winusb.inf.

If you want more information on this topic, you may visit OEM USB Drivers | Android Developers.

To install an unsigned driver under Windows 7/8 64-bit, you have to disable driver signature enforcement.

If you are running Windows 7 64-bit, you have to select Disable Driver Signature Enforcement in the Advanced Boot Options menu. To get in the Advanced Boot Options menu you have to press F8 repeatedly while booting.

If you are running Windows 8 64-bit, you have to Disable Driver Signature Enforcement by selecting Settings -> Change PC settings -> General (Windows 8) or Update & recovery -> Recovery (Windows 8.1) -> Advanced startup -> Restart now -> Troubleshoot -> Advanced options -> Startup Settings -> Restart -> Disable driver signature enforcement (Press 7 or F7).

After the device driver installation, using the modified android_winusb.inf file, an exact copy of this file will be created in \WINDOWS\INF\ folder, named OEM_____.INF, where _____ corresponds to the next available number, as there are already some OEM_____.INF files existing. If you want to remodify the Google USB Driver to include other Android devices, you may create a new modified android_winusb.inf. In this case, a copy of this newly modified android_winusb.inf file will also be created in \WINDOWS\INF\ folder after installation, along with the previous one. This way you will end up having multiple OEM_____.INF files corresponding to different modifications of the Google USB Driver lying in your \WINDOWS\INF\ folder. Instead of that, when you will need another modification to the Google USB Driver, you can search and find the previously created OEM_____.INF file in your \WINDOWS\INF\ folder corresponding to the modified Google USB Driver and remodify its contents and save it in place. You may include or exclude Android devices and comment existing references to Android devices, altering this backup reference of the modified Google USB Driver as needed. This way, you will not have to provide the modified Google USB Driver again, since it will be found automatically and used when needed, according to its new contents. In the case you remodify the previously created OEM_____.INF file and receive a "Insert Disk" or "Files Needed" error message during later Android device driver installation, you do not have to provide the Android WinUsb installation disk, since the required DLL files have already been installed in your \WINDOWS\SYSTEM32\ folder during the previous device driver installation. You may instead browse to your \WINDOWS\SYSTEM32\ folder, where the required files will be found and the device driver installation will continue normally. To remove the modified Google USB Driver for a specific device, you just have to comment or delete its references in the corresponding OEM_____.INF file in your \WINDOWS\INF\ folder, or delete the actual OEM_____.INF file in case you do not need it any more (there are no other references to other Android devices in it).

If you want more information on manual device driver uninstallation, keep reading the following section.

[loko]

How to manually uninstall Drivers in Windows

Every device connected to a Windows computer, whether it has a properly installed driver or not, has a visible entry in the Device Manager. You can open your Windows Device Manager, browse and find that device under the corresponding device type. You can also double click (or right click and select "Properties") on the desired device name, then go to the Details tab, where you can see its corresponding Properties, including Device Ids.

If you want to uninstall a device, you can right click on the device name and select Uninstall. The main problem is that after uninstalling a device in the Device Manager, when you refresh the Device Manager or reconnect the device, the old driver gets automatically reinstalled, even if it is not the desired one, because a backup reference of that driver is integrated in Windows. If you want to avoid the automatic installation of the old driver, you just have to delete the backup reference of that driver.

If you want to uninstall a previously installed device driver that has been installed by an installation utility, there might probably be an official uninstalling procedure available (e.g. as an entry in the Control Panel or a shortcut in the Start menu or there are specific uninstalling instructions). If such a procedure is available, it is highly recommended that you use that procedure to properly remove any modifications that were made to your system during the device driver installation.

In the case of a device driver that has been manually installed by browsing and selecting an INF file under a folder, there does not seem to be any way of uninstalling. If for any reason you want to remove such a device driver backup reference from your Windows installation, particularly in the case of a manually modified and installed device driver, you have to manually delete it.

In every Windows device driver package there is one or more INF files, corresponding to different supported devices and/or different Windows versions. These INF files contain Device Hardware Ids and installation instructions. When installing a new device, the system searches these INF files and if a matching Device Hardware Id is found, the device driver installation continues according to the included instructions in the corresponding INF file.

After every device driver installation, using a corresponding INF file, an exact copy of this file is created in \WINDOWS\INF\ folder, named OEM_____.INF, with an according OEM_____.PNF file, where _____ corresponds to the next available number, as there are already some OEM_____.INF files existing. You can open these INF files with any text editor and read the contents.

If you want to remove the backup reference of a specific driver from the system, you just have to remove its corresponding INF file. Find the desired OEM_____.INF file in \WINDOWS\INF\ by reading the contents of various OEM_____.INF files. If the INF file you are searching has been installed recently, for your convenience, start looking backwards, beginning with the last installed INF files. When you find the desired INF file, remove it (double check that it is indeed the correct file and optionally create a backup). You can also remove the corresponding OEM_____.PNF file.

There can also be some other files being copied to your system during the device driver installation (e.g. DLL files). These files and their installation locations are referenced inside the corresponding INF file installation instructions. It would be wiser not to manually delete any of these files, since they can be shared with other driver instances and being actively used by the system. You can safely leave these files in your system, since there will be no undesired reference to them after removing the corresponding INF file. If you are completely sure that these files will not be used by the system in any way, you may then delete them at your own risk. In this case it is highly recommended that you keep a backup of the files you delete, in case you would need to restore them.

Now, if you uninstall the device in the Device Manager and refresh the Device Manager or reconnect the device, Windows will ask for a new driver for that device, since there will not be any INF file containing a corresponding Device Id automatically found in the system.

If you accidentally remove another INF file, the corresponding device will continue to work normally, but if you uninstall it, you will have to provide again the original device driver package.

[loko]

How to manually install Android SDK Platform-tools

To successfully use ADB in Windows, you do not have to download or install the whole Android SDK, you may just download the appropriate Platform-tools from the Android Repository (e.g. platform-tools_r18.0.1-windows.zip for the 18.0.1 version) and extract it to a folder of your choice. Do not also forget that you may need to add a line with your Hardware Vendor Id (in the hexadecimal form of "0xXXXX") in your "adb-usb.ini" file in your ".android" folder, in the case that your Android device has an unsupported Hardware Vendor Id. Also, make sure you use the latest version of the Android SDK Platform-tools and always run "adb kill-server" before running "adb devices".

If you do not know how to find your adb-usb.ini file, first navigate to your home directory (open Windows Explorer and type %HOMEPATH% in the Address Bar followed by ENTER) and search for a folder named ".android". This folder gets automatically created when you first run ADB. If it does not exist, you may create it either by running ADB or manually. Enter that folder and search for a file named "adb-usb.ini". If it does not exist, you have to manually create it. Make sure to name it "adb-usb.ini" and not "adb-usb.ini.txt" or anything else, especially if you use the "Hide extensions for known file types" Folder Option in Windows. The correct file type should be "Configuration Settings". Open that file in a text editor and make sure that there is a dedicated line containing your Hardware Vendor Id, in the hexadecimal form of "0xXXXX", where "XXXX" is the 4 character Vendor Id as it appears in your Device Hardware Id "USB\VID_XXXX". If you do not know how to find your 4 character Vendor Id, open your Windows Device Manager, connect your device, browse and find that device under the corresponding device type, double click (or right click and select "Properties") on the desired device name, then go to the Details tab, where you can see its corresponding Properties, including your Device Hardware Id containing the 4 character Vendor Id. If adb-usb.ini is empty or there is no dedicated line for your Hardware Vendor Id, you have to manually create a new line containing your Hardware Vendor Id. Do not forget to add the numeric constant hexadecimal prefix "0x" before the 4 character Vendor Id. Save the file, make sure everything went well and you are ready to go.

You may notice that the Vendor Id can be different when your device is in Bootloader, Recovery or Android System. If your device is not detected by adb when it is running the Android System, there can still be a problem with your adb-usb.ini file or your configuration. Before giving up, you may try fastboot detection after entering the Bootloader, or adb detection after entering the Recovery. If any of these configurations work, then you have to double check all your configurations for errors.

Note that since your Device Hardware Id changes according to the status of your connected Android device (e.g. Bootloader, Recovery or Android System), you have to install the modified Google USB Driver separately for each different status (you can make a single modified android_winusb.inf file containing multiple lines with every required Device Hardware Id that your device is using).

Under Linux, you have to download the appropriate Platform-tools from the Android Repository (e.g. platform-tools_r18.0.1-linux.zip for the 18.0.1 version) and extract it to a folder of your choice. To find your idVendor you have to run "lsusb". If you cannot easily find out which entry corresponds to your device, you can unplug your device and run "lsusb", then replug your device and run "lsusb" again. You can easily locate your device comparing the two "lsusb" results. If needed you have to add your idVendor to your adb_usb.ini file by running "gedit ~/.android/adb_usb.ini" or "sudo gedit ~/.android/adb_usb.ini" if your adb_usb.ini file is owned by root. Make sure that there is a dedicated line containing your idVendor, in the hexadecimal form of

0xXXXX

where "XXXX" is the 4 character idVendor. If adb-usb.ini is empty or there is no dedicated line for your idVendor, you have to manually create a new line containing your idVendor. Do not forget that you may also have to add your idVendor to your 51-android.rules file by running "sudo gedit /etc/udev/rules.d/51-android.rules". Make sure that there is a dedicated line containing your idVendor, in the form of

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", MODE="0666", GROUP="plugdev"

where "XXXX" is the 4 character idVendor. If 51-android.rules is empty or there is no dedicated line for your idVendor, you have to manually create a new line containing your idVendor. Save the file and run "sudo chmod a+r /etc/udev/rules.d/51-android.rules" and "sudo service udev restart", or restart your system and you are ready to go. To make sure that you have a working adb configuration, navigate to your platform-tools folder and run "./adb kill-server" and "./adb devices" as a normal user or "sudo adb kill-server" and "sudo adb devices" using root privileges. Do not also forget that you have to enable USB debugging in your device's developer options settings.

If you want more information on this topic, you may visit OEM USB Drivers | Android Developers.

[loko]

How to manually root your Android device using ADB

If you can attain privileged control within an Android command line shell, you can then configure everything else manually according to your liking. You may attain privileged control one way or another, but there seem to be some Android devices that have looser security (especially Chinese ones), where you can easily gain root access using the adb shell, without having to modify any security settings.

First, you have to enable USB debugging in your device's developer options settings, connect your device to your computer and install any needed drivers. Then, open a Windows Command Prompt terminal (you may need to run the terminal as Administrator) and navigate to your Android SDK Platform-tools folder (e.g. "cd c:\platform-tools"). Run "adb kill-server" then "adb devices". Make sure that you have a working adb configuration. (Under Linux run e.g. "cd ~/platform-tools" then run "./adb kill-server" and "./adb devices" or "sudo adb kill-server" and "sudo adb devices" as root).

Enter the adb shell by running "adb shell". If the prompt ends with the # symbol, then you have root access. You may also run "id" to check your user and group id. If you have root access, then uid and gid will be both 0. If the prompt ends with the $ symbol and uid and gid are not 0, then you do not have root access yet. In that case, try running "su". In some devices, you may now be granted root access, the $ symbol will change to the # symbol and uid and gid to 0. If that is your case, you do not have to use any rooting tools to configure your device. You can use the busybox binary, su binary and superuser application of your liking, copy them to their final locations in the Android system and configure their file owner and permissions. To achieve this, first of all you have to get the su binary and superuser application of your liking and copy them to your Android SDK Platform-tools folder. You may also have to copy the busybox binary of your liking, although you will later have to install the busybox application of your liking from within the Android system to achieve full integration (i.e. proper creation of symbolic links to the binary). Superuser by ClockworkMod is newer and less used than its alternatives but it is an open source project (it is also fully integrated into CyanogenMod). You may get the ClockworkMod Superuser application from the official page. Download the recovery zip http://download.clockworkmod.com/sup.../superuser.zip, decompress it and get Superuser.apk. The direct apk link http://download.clockworkmod.com/apks/Superuser.apk seems to link currently to an older version, so use the one in the recovery zip. To get the su binary that corresponds to your superuser application, you may decompress Superuser.apk with a decompression utility. If you cannot directly open the apk file with a decompression utility you may create a copy and change its extension to zip. Copy Superuser.apk along with the extracted armeabi su binary (e.g. com.koushikdutta.superuser/assets/armeabi/su) to your Android SDK Platform-tools folder.

If you cannot gain root access as in the previous cases, you have to use some existing exploit compatible with your device. There are several exploits, depending on the type of your device (e.g. for MT6589 devices, there is the Motochopper Android root exploit that works just fine). You do not have to use the whole exploit as it is, you can make personal modifications to the procedure (e.g. in the previous case you can just keep the pwn binary and change the other binaries with ones of your liking). You can also run all steps manually, according to the provided script instructions.

After gaining root access, to make any changes to your /system/ folder, you have to mount it as read-write using the command "mount -o remount,rw /system". After the needed changes, do not forget to mount it again as read-only using the command "mount -o remount,ro /system".

To gain root access to your Android device, there must be an su binary in the system, having the right file owner (root) and permissions (6755 i.e. -rwsr-sr-x). The su binary normally lies in the /system/xbin/ folder, but you may find it under /system/bin/ as well (or /system/sbin/). There may also be some symbolic links pointing to some of these locations. There also are superuser applications that provide graphical interface to the su binaries from within the Android system. To gain root access from within the Android system (and sometimes even from the adb shell), both an su binary and its corresponding superuser application must be present to the system. This means that you also have to install the corresponding superuser application by running "adb install Superuser.apk".

Sometimes, even if there is an su binary in the system, you may not be able to gain root access from within the Android system, but you may be able to do so from the adb shell. In that case, you can use the available root access from the adb shell to rename the original su binary (e.g. to suold) and install a different su binary of your liking in its place, that can also grant root access from within the Android system in combination with its corresponding superuser application. Since renaming the original su binary will not modify its file owner and properties, you may afterwards open an adb shell and run it by its new name and still gain root access. In any case, to be on the safe side, do not delete the original su binary, renamed or not, before ensuring that your new configuration is fully working. When finished, make sure you do not have various su binaries mixed together in your system folders (different su binary versions or even binaries from different developers), to avoid potential conflicts that could impose security risks.

Push the su binary of your liking to the /system/xbin/ folder by running "adb push su /system/xbin/su" from your computer. If you cannot push files directly to your /system/xbin/ folder because you cannot get the required permissions, but still can gain root access in the adb shell, keep in mind that you always have access to the /data/local/tmp/ folder, whether rooted or not. So run "adb push su /data/local/tmp/su" to copy the su binary of your liking to the temporary folder, then enter the adb shell and run as root "cp /data/local/tmp/su /system/xbin/su" then "rm /data/local/tmp/su". (Beware that you cannot move a file across filesystems, so you cannot use the "mv" command to move the su binary from the tmp folder to the system folder. You have to use the "cp" command to create a copy of the file, then the "rm" command to delete the original file. Note that to use these commands, you need to have a toolbox or busybox binary in your system). Then set the right file owner and permissions for the su binary by running as root "chown root:root /system/xbin/su", "chmod 6755 /system/xbin/su". If you also want to push the busybox binary of your liking to the /system/xbin/ folder, you can use a similar procedure, taking into consideration that the su binary must have 6755 permissions while the busybox binary must have 0755 permissions. Do not give 6755 permissions to your busybox binary in any case.

If you want to experiment at your own risk, just for fun, creating exchangeable superuser combinations in a supposedly safe enough manner, you may download and install through adb all three commonly used superuser applications together. 1) Superuser by ClockworkMod (com.koushikdutta.superuser), 2) Superuser by ChainsDD (com.noshufou.android.su) and 3) SuperSU by Chainfire (eu.chainfire.supersu). You may then manually install their corresponding su binaries with different names, as "su1", "su2" and "su3". To test them, open Android Terminal Emulator from within the Android system and run "su1", "su2" or "su3". Each binary will invoke its corresponding superuser application and supposedly work fine. Then, you can change on the fly the default superuser combination that will be used from within the Android system, by simply renaming "su1" or "su2" or "su3" to "su" manually or using custom scripts. Of course, if you already have one superuser combination installed, so you can gain root access from within the Android system, you can create a copy of its su binary from within the Android Terminal Emulator, then install another superuser combination and create another copy of its su binary, so you can get to the previous situation from within the Android system. Then, you can write a script to exchange superuser combinations, by gaining root access from the current superuser combination, then giving the option to select a new superuser combination, renaming the current su binary, then renaming the new su binary, then setting 6755 permissions to the new su binary and 0755 permissions to the previous one, so it is supposed to be safe enough, since only one su binary will have 6755 permissions at a time. I cannot understand who on earth would do so, but I must admit I already did so. At the end, clean up the system but make sure that you will leave one valid su binary in the system, otherwise you will lose root access.

It is advisable to download or update Android Terminal Emulator by Jack Palevich (jackpal.androidterm), BusyBox by Stephen (Stericson) (stericson.busybox) and the open source Superuser by ClockworkMod (com.koushikdutta.superuser), although you may use any other versions of your liking.



A real example is following, based on a T-R42 Quad Core Android TV BOX

Device Manager -> Other devices -> rk31sdk -> Hardware Id -> USB\VID_2207&PID_0010&MI_01


Device Hardware Id corresponding entries added in adb_usb.ini file for proper device driver installation

[Google.NTx86]

;T-R42 Quad Core Android TV BOX
T-R42 Composite ADB Interface = USB_Install, USB\VID_2207&PID_0010&MI_01


[Google.NTamd64]

;T-R42 Quad Core Android TV BOX
T-R42 Composite ADB Interface = USB_Install, USB\VID_2207&PID_0010&MI_01

ADB output before editing adb_usb.ini

C:\platform-tools>adb kill-server

C:\platform-tools>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached

C:\platform-tools>

Hardware Vendor Id line added in adb_usb.ini file

0x2207

ADB output after editing adb_usb.ini

C:\platform-tools>adb kill-server

C:\platform-tools>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
XXXXXXXXXX      device

C:\platform-tools>

Android Terminal Emulator output under the factory firmware

u0_a62@android:/ $
u0_a62@android:/ $ id
uid=10062(u0_a62) gid=10062(u0_a62)
u0_a62@android:/ $
u0_a62@android:/ $ ls -al /system/xbin/su
-rwsr-sr-x root     root        67080 2013-10-22 11:38 su
u0_a62@android:/ $
u0_a62@android:/ $ su
su: uid 10062 not allowed to su
u0_a62@android:/ $

ADB shell output under the factory firmware (note that you already have adb shell root access)

C:\platform-tools>adb shell id
uid=0(root) gid=0(root)
C:\platform-tools>
C:\platform-tools>adb shell cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.sys.usb.config=adb
C:\platform-tools>

Android Terminal Emulator output after installing the su combination of your liking

u0_a62@android:/ $
u0_a62@android:/ $ id
uid=10062(u0_a62) gid=10062(u0_a62)
u0_a62@android:/ $
u0_a62@android:/ $ ls -al /system/xbin/su
-rwsr-sr-x root     root       311872 2013-11-30 22:25 su
u0_a62@android:/ $
u0_a62@android:/ $ su
Permission denied
u0_a62@android:/ $
u0_a62@android:/ $ su
u0_a62@android:/ #
u0_a62@android:/ # id
uid=0(root) gid=0(root)
u0_a62@android:/ #
u0_a62@android:/ # exit
u0_a62@android:/ $

Installation of the su combination of your liking

In the following example, the su binary is installed through the /data/local/tmp/ folder. If you can push files directly to your /system/xbin/ folder, you do not have to use this intermediate step.

Also, the approach followed is to install the new su binary under another name e.g. as "sunew", verify that everything is working well, then rename the older existing binary e.g. as "suold", then rename the new binary as "su", verify again that everything is working well and then delete the older binary.

You may first rename the older existing binary and install the new su binary directly in its place. Since renaming the original su binary will not modify its file owner and properties, you may afterwards open an adb shell and run it by its new name and still gain root access.

In any case, to be on the safe side, do not delete the original su binary, renamed or not, before ensuring that your new configuration is fully working.

C:\platform-tools>
C:\platform-tools>adb install Superuser.apk
5063 KB/s (2025538 bytes in 0.390s)
        pkg: /data/local/tmp/Superuser.apk
Success
C:\platform-tools>
C:\platform-tools>adb push su /data/local/tmp/sunew
6497 KB/s (311872 bytes in 0.046s)
C:\platform-tools>
C:\platform-tools>adb shell
root@android:/ #
root@android:/ # id
uid=0(root) gid=0(root)
root@android:/ #
root@android:/ # mount | grep /system
/dev/block/mtdblock8 /system ext4 ro
root@android:/ #
root@android:/ # mount -o remount,rw /system
root@android:/ #
root@android:/ # mount | grep /system
/dev/block/mtdblock8 /system ext4 rw
root@android:/ #
root@android:/ # busybox which busybox
/system/bin/busybox
root@android:/ #
root@android:/ # busybox which su
/system/xbin/su
root@android:/ #
root@android:/ # ls -al /system/xbin/su*
-rwsr-sr-x root     root        67080 2013-10-22 11:38 su
root@android:/ #
root@android:/ # cp /data/local/tmp/sunew /system/xbin/sunew
root@android:/ # rm /data/local/tmp/sunew 
root@android:/ #
root@android:/ # chown root:root /system/xbin/sunew
root@android:/ # chmod 6755 /system/xbin/sunew
root@android:/ #
root@android:/ # /system/xbin/sunew
root@android:/ #
root@android:/ # exit
root@android:/ #
root@android:/ # mv /system/xbin/su /system/xbin/suold
root@android:/ # mv /system/xbin/sunew /system/xbin/su
root@android:/ #
root@android:/ # ls -al /system/xbin/su*
-rwsr-sr-x root     root       311872 2013-11-30 22:25 su
-rwsr-sr-x root     root        67080 2013-10-22 11:38 suold
root@android:/ #
root@android:/ # mount -o remount,ro /system
root@android:/ #
root@android:/ # exit
C:\platform-tools>

[loko]

You are welcome to leave any comments.

[peety]

Wow

You are welcome to leave any comments.

How about thank you! Well written and nice to have it all in one place. Now when I forget somthing..I know where to look. Sticky!