2.2 Control process analysis
2.2.1 LightsService service startup process
LightsService is started from SystemServer, and all necessary system services will be started when running SystemServer's run() method.
This includes the LightsService used to control LED lights and screen backlights, and start the service in SystemServer:
private void startBootstrapServices() {
...
// Manages LEDs and display backlight so we need it to bring up the display.
mSystemServiceManager.startService(LightsService.class);
...
}
The constructor of LightsService will be run first at startup. The construction method is as follows:
public LightsService(Context context) {
super(context);
mNativePointer = init_native();
for (int i = 0; i < LightsManager.LIGHT_ID_COUNT; i++) {
mLights[i] = new LightImpl(i);
}
}
In the construction method, assign a value to the private variable mNativePointer through the native method init_native(). This method is implemented by C++.
The main task is to allocate space for each Light device and return the first address pointer to mNativePointer. Subsequent native methods for Light devices
Operations are addressed according to this pointer. Next, a for loop will be used to create an instance of Light and save it in an array. This process is actually the same as
Corresponding to init_native(), the upper layer allocates storage space for each Light object. In this way, the initialization work is completed in the construction method.
Next, the lifecycle function onStart() of the service is called. In the onStart() method, only one private method publishLocalService is called,
You can see its prototype in SystemService:
/**
* Publish the service so it is only accessible to the system process.
*/
protected final <T> void publishLocalService(Class<T> type, T service) {
LocalServices.addService(type, service);
}
This is the service object passed in when registering the LightsService service, which is actually an instance of LightsManager//
private final LightsManager mService = new LightsManager() {
@Override
public Light getLight(int id) {
if (id < LIGHT_ID_COUNT) {
return mLights[id];
} else {
return null;
}
}
};
Through this method, LightsService is published to the local service library. It can be seen that LightsService is a local service, so it cannot be called by external applications.
This means that LightsService does not belong to the API provided by the platform (as shown in Figure 1-1), and can only be called by other parts in the same package in the JAVA framework.
This publish method has two parameters. The first parameter is the type, which is used to mark the service type and used when obtaining the service. The second parameter is used to save the instance of the service object.
Since it is a local service, it can be obtained through getLocalService(Class<T> tpye). Take the notification management service in the Android system to use LightService as an example:
private Light mNotificationLight;
final LightsManager lights = getLocalService(LightsManager.class);
mNotificationLight=lights.getLight(LightsManager.LIGHT_ID_NOTIFICATIONS);
This is the process of obtaining and controlling the indicator light when there is a notification message in the Android system. The proxy (Proxy) mode in the design mode is actually used here,
LightsManager acts as a proxy for the LightsService service. At this point, LightsService is started and can provide services.
If you want to access the LightsService service through remote services, you need to register the service in another way:
/**
* Publish the service so it is accessible to other services and apps.
*/
protected final void publishBinderService(String name, IBinder service,
boolean allowIsolated) {
ServiceManager.addService(name, service, allowIsolated);
}
That is, the service object is passed to the ServiceManager through the Binder mechanism, and the service can be obtained from the ServiceManager through the name, and the service interface is provided to other applications in this way.
2.2.2 Get and control a light switch and blink
After the LightsService is started and running, the lights can be obtained and operated through the LightsManager. The instance of the light is obtained by ID when obtaining the method. Next, we mainly analyze how the upper layer controls the on-off and flickering of the lights.
The control of the light is mainly completed in the Lingt class, including setting the brightness value for the light, setting the color of the light, setting the flashing of the light, setting the pulse of the light and turning off the light. The method looks like this:
public abstract void setBrightness(int brightness);
public abstract void setBrightness(int brightness, int brightnessMode);
public abstract void setColor(int color);
public abstract void setFlashing(int color, int mode, int onMS, int offMS);
public abstract void pulse();
public abstract void pulse(int color, int onMS);
public abstract void turnOff();
In the implementation of these methods, a method will be called after parameter processing: setLightLocked(int color, int mode, int onMS, intoffMS, int brightnessMode).
Among them, the pulse() method will start a delayed Handler task to stop the flashing of the light after the set time. Each of the above methods specifies different
parameters to achieve their respective goals. The first parameter is the color value or converted to a color value from the brightness value passed in. The second parameter is the brightness mode, there are three optional values here,
The meaning of these three modes can be seen in the definition of light.h (introduced in Chapter 4), LIGHT_FLASH_NONE means no flashing; LIGHT_FLASH_TIMED means according to
The set time to flash, you can specify how long it is on and how long it is off; LIGHT_FLASH_HARDWARE means that the flashing of the light needs to be controlled by hardware. third and
The fourth parameter indicates the time of on and off. The last parameter is the brightness mode. There are two optional values here, BRIGHTNESS_MODE_USER and BRIGHTNESS_MODE_SENSOR,
In turn, the brightness is set by the user and the brightness is set by the light sensor.
The setLightLocked method will then call the local method setLight_native(mNativePointer, mId, color, mode, onMS, offMS, brightnessMode),
Among them, the mNativePointer parameter is the starting address pointer of all light devices in the system returned after initialization when the LightsService service is started as described above.
Until here, the above parameters are actually passed to the bottom layer to process the lamp equipment. As long as you are familiar with the above interfaces, you can control the lights on the upper layer.