Shenduos recovery compilation and debugging tutorial

This tutorial synchronously updates in http://blog.csdn.net/airk000
Reprinted please indicate the source http://blog.csdn.net/airk000/article/details/8916797

* This tutorial assumes that you already have an android compiling environment and the latest shenduos code.

1. Create a recovery for the new machine

You need to prepare: recovery. IMG (or boot. IMG)
If you have prepared boot. IMG, you also need the official recovery. fstab file. This file will be found in recovery. IMG through unpacking and under ETC. This file is critical. If it is not correct, the machine may become brick-and-mortar. Therefore, if conditions permit, it is better to prepare a recovery. IMG that can be used normally, as well as the official recovery. IMG, Which is safer. Of course, you can also prepare boot. IMG and calculate a recovery. fstab by using the cat kernel device ~~~ Why?

Go to the shenduos source code directory and run

Make otatools-JX

X indicates the number of compiled threads.

After compilation is complete, add the out/host/linux-x86/bin to the system environment variable:

Echo "Export Path = $ path:/XXX/out/host/linux-x86/bin/"> ~ /. Bashrc
Source ~ /. Bashrc

XXX is the source code directory path.

In the source code directory, run:

./Build/tools/device/mkvendor. Sh <menufacture> <model> <image>

Menufacture is the vendor name, such as HTC Samsung Huawei ZTE and etc.
Model is the product code, such as saga (HTC Desire S), i9100, n909, etc.
Image: The imgfile path you have prepared

After the preceding command is successfully executed, the system automatically generates the device code for your device. IMG, you must note that you need to replace or modify the recovery. fstab, this file is under the newly generated device code, such as device/HTC/saga/. This step is very important because the default recovery provided by the system. fstab is likely to make your machine brick. Of course, if you have prepared recovery. IMG, there is no need to replace this file. It is already correct. This is the advantage of using recovery for recovery.

2. Create a recovery for models supported by shenduos

Although this may be of little significance, I believe many people will try it and execute it directly:

./Build/envsetup. Sh
Breakfast xxx

XXX is the model code supported by shenduos, such as c8812, Saga, etc.

3. Start creating recovery

There are two production methods:

Make recoveryzip
Make recoveryimage

Make recoveryzip, which is generally used. This operation will directly generate the update.zip file that can be directly refreshed under recovery. if it is used, it will not overwrite the original recovery, just look at it, so this is often used for debugging. Debugging with ADB sideload is highly efficient.
Make recoveryimage, used to generate a recovery. IMG, which is usually generated after being debugged and confirmed to be correct. After being generated, you can use the installrecovery command to install the recovery (this command must be in. build/envsetup. sh before use)

4. debug recovery

This will be part of the focus of this tutorial. Everyone can compile the recovery, as long as you give some guidance, you can easily get it done in a short time (the same is true for the compilation system ), there are troublesome and important issues in subsequent debugging. The following describes several debugging points for shenduos recovery to facilitate development and participation.

1) color mode
Generally, the color mode after a new machine compiles a recovery is mostly incorrect, because many of the current machines are in the 8888 mode, while the default mode in the recovery mode is 565, therefore, the final cause is that the color is incorrect (blue-yellow), and the screen offset jitter occurs when the buttons are pressed.
The parameter changes are in recovery/minui/Android. mk:

Ifeq ($ (target_recovery_pixel_format), "rgbx_8888 ")
Local_cflags + =-drecovery_rgbx
Endif
Ifeq ($ (target_recovery_pixel_format), "bgra_8888 ")
Local_cflags + =-drecovery_bgra
Endif

Target_recovery_pixel_format is the boardconfig that needs to be written in the device code. in MK, you can try target_recovery_pixel_format: = "rgbx_8888" or "bgra_8888" to check whether the code can be corrected. In general, it can be easily corrected. If not, you need to analyze graphics. the Code flow in C. To be honest, this file still has potential risks in version 1.3, and cannot ensure that all machines can be used normally.

2) The upper and lower buttons take effect, and the power button does not take effect
In boardconfig. mk, set board_has_no_select_button: = true.

3) Custom font size
In boardconfig. mk, board_use_custom_recovery_font: = \ "XXX \". Here, XXX is the font file under minui, starting with font and ending with. h.

4) supports Virtual button touch
Added the support for virtual button touch feature since the shenduos recovery1.2 version. For compatibility issues, restrictions are imposed in the code. If you want to use the touch function, make some modifications and debugging.

First, check recovery/Android. mk:

Ifeq ($ (board_touch_virtual_key_recovery), true)
Local_cflags + =-duse_virtual_key
Ifeq ($ (target_screen_width), 720)
Local_cflags + =-dvirtual_key_720
Endif
Ifeq ($ (target_screen_width), 1080)
Local_cflags + =-dvirtual_key_1080
Endif
Ifeq ($ (target_bootloader_board_name), Mako)
Local_cflags + =-dmako-dvirtual_key_720
Endif
Endif

The premise is that board_touch_virtual_key_recovery. Touch starts only when this takes effect.
Board_touch_virtual_key_recovery determines whether to use virtual button touch;
Target_screen_width indicates the screen width. If the screen width is 720 p, target_screen_width: = 480. If the screen width is 480, no write is required, because is the default value.
Both of the above are to be written to boardconfig. mk.

You can also define it to mako (Nexus 4) as follows:
When the device name is Mako, define a mako flag and use a p virtual button. The Mako flag will be used later.

5) debug touch events
There are too many machines on the market with different touch interface standards. The interfaces suitable for Huawei are not necessarily suitable for Samsung, and they are not necessarily applicable to HTC, so this is also the difficulty of touch recovery. In the code, I have left out all the interfaces that can be thought of to debug different machines that need to be modified, so that you can easily debug and modify them.
This part of modification is mainly concentrated in recovery/UI. C. First, let's look at an interface:

# Ifdef use_virtual_key
// # Ifdef common_touch_driver
Int touch_type = ev_abs;
Int touch_code = abs_mt_touch_major; // 48
Int touch_pos_x = abs_mt_position_x; // 53
Int touch_pos_y = abs_mt_position_y; // 54
Int Lv = 0; // left Value
// # Endif

Touch_type is the type value of the touch event, and the Linux Standard is ev_abs (3). Therefore, it is also used as the default value, which is common to many devices. Ev_key ev_rel represents the keys and trajectory wheels respectively.
Touch_code indicates the identifier of a touch event (not standard). This indicates that when a touch event occurs, the value must exist. Generally, it indicates the touch area.> 0 indicates that a touch exists, <= 0 indicates that the touch time is complete.
Touch_pos_x is the X coordinate in the touch event.
Touch_pos_y is the Y coordinate in the touch event.
LV is not a bag ...... Is left value, that is, when the touch time ends, what is the value reported by the driver when code = touch_code is usually 0, but for example, Nexus 4 is-1, therefore, the interface is also reserved.

PS: When debugging a touch, you usually need to open touch_debug to display the key information intuitively on the interface.

If your machine-driven reporting standards are the same as this, it is very likely that your rediscovery will be successful at once, but it is often not so smooth. There are two common problems:

A. Different touch type equivalence and standards
B. Inconsistent coordinates
The following code (in Ui. c) solves these two problems:

# Ifdef Mako
Touch_code = 57;
Lv =-1;
If (EV. type = touch_type ){
If (EV. Code = touch_pos_x)
Ev. value = eV. Value * 768/1536;
Else if (EV. Code = touch_pos_y)
Ev. value = eV. Value * 1280/2560;
}
# Endif

First, let's talk about the Problem. During the debugging of Mako, we found that the starting and stopping of the touch event passed 57 rather than 48, so we can define touch_type as 57, to replace 48 in the standard interface.
At the same time, it was found that during the debugging process, code = 57 and value =-1 were reported every time the finger left the screen, instead of value = 0, therefore, the LV in the interface is defined as-1, so that the recovery can normally identify the start and end of the touch event.

Then, question B, in general, (0.0) coordinates are in the upper left corner of the screen, but there are very few manufacturers who may remember to play non-mainstream in other places, therefore, during debugging, we usually first find out where the 0-point coordinate is, whether it is in the upper left corner, and then find the maximum coordinate.
Maybe the resolution of your machine is 768*1280, but the maximum coordinate is (,). Don't be surprised. This is possible. If so, let's not go into the details and analyze Mako's solution directly:

Extract and convert the reported information of x y coordinates in a touch event to match the normal coordinates. This formula is also very easy to understand. It should be noted that they are all Division operations for integer data without remainder.

The above is the compilation tutorial for shenduos recovery1.2 and later versions, including common debugging points. I hope you will pay attention to it and actively participate in all shenduos development projects!