[Android camera]

My understanding of Android camera will be written down one after another to gradually improve the camera network in the brain.

 

 

1. Two independent processes of Android camera

Android camera is a C/S architecture that has been said to be poor, but I still want to write this article down, because I often have a short circuit in my head, the hope of doing useless work on the client side to solve the problem is truly an extravagant hope.

Needless to say, the core is the service end. The service process is always responsible for receiving data from the underlying camera driver and then displaying it to the surface.

The client does not have a dry meal either. Although the client process does not have any substantive camera data, the service end provides a wide range of interfaces for it to easily obtain the addresses of camera data and then process the data.

Finally, let's add another nonsense. The client and service communicate through the binder.

 

 

2. Camera and icamera

When I first came into contact with camera, I couldn't understand the workflow of camera. When I watched camera and pressed Ctrl + on the keyboard, I jumped to icamera, there was only one feeling in my heart. Isn't it a pitfall!

In fact, it is not very difficult to analyze it carefully...

Icamera, icameraclient, and icameraservice all belong to the client of Android camera. Their task is to communicate with the service end of Android camera.

Well... Please note that we are always active on the client side of Android camera.

 

According to the process, after a crash, we finally got to camera. cpp and finally had a relationship with icamera. For upper-layer applications, camera. cpp is the most direct function call and implementation. It inherits from the icameraclient class and is a typical client-side interface instance.

 

Never be dizzy. The truth is: sp <camera> camera = camera: connect ();

 

 

The camera class calls a function through the sp <icamera> mcamera object.

The result is that the mclient function of cameraservice: client is directly called.

 

If you are dizzy, it indicates that you did not remember that the android camera service that I just mentioned provides a wide range of interfaces for the android camera client.

 

Sp <camera> camera: connect ()

{

Logv ("Connect ");

Sp <camera> C = new camera ();

Const sp <icameraservice> & cs = getcameraservice ();

If (CS! = 0 ){

C-> mcamera = cs-> connect (C );

}

If (c-> mcamera! = 0 ){

C-> mcamera-> asbinder ()-> linktodeath (C );

C-> mstatus = no_error;

} Else {

C. Clear ();

}

Return C;

}

 

Connect function interface of cameraservice:

Sp <icamera> cameraservice: connect (const sp <icameraclient> & cameraclient ){

.....

// Create a new client object

Client = new client (this, cameraclient, callingpid );

Mclient = client;

If (client-> mhardware = NULL ){

Client = NULL;

Mclient = NULL;

Return client;

}

.....

}

Here, a client instance object is created, and the instance object is assigned to mclient, a class member of camerasevice, to facilitate the call of the function interface to the client.

 

3. The customer is abnormal, and the sensor model must be changeable.

The customer always changes the hardware solution. Well, we have to re-port Android camera. Many people feel terrible when talking about porting two words. We are talking about embedded systems, not medicine. If you transplant a kidney, you have to shake it up. If you transplant a camera, you need to write more sensor drivers. What are you afraid ?!

As for how to write the specific configuration attributes of the sensor, I have to hear from the customer.

Hi, programmer, who has not been challenged by the customer's needs? Sigh, forget it, and never complain. Who makes us the greatest, smartest, kind programmer in the IT world!

Author: yiyaaixuexi published on 23:24:00 Original article link reading: 3707 comments: 48 Views comments