Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "what is the structure of Camera Service". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The structure at the end of camera service is still very confusing, and it took me a long time to get a clear understanding of the relationship.

The service section includes the following header files: ICamera.h, ICameraService.h, CameraService.h, and the corresponding implementation ICamera.cpp, ICameraService.cpp, CameraService.cpp.

CameraService contains an inner class CameraService::Client, this CameraService::Client is the implementation of ICamera, and the ICamera obtained by camera client is this CameraService::Client.

In other words, it is this CameraService::Client that really communicates with camera client. Let's analyze the implementation of service step by step.

1.ICameraService

(1) ICameraService.h

Only three methods are defined:

Virtual int32_t getNumberOfCameras () = 0

Virtual status_t getCameraInfo (int cameraId, struct CameraInfo* cameraInfo) = 0

Virtual sp connect (const sp& cameraClient, int cameraId) = 0

(2) ICameraService.cpp

Look at the code:

Status_t BnCameraService::onTransact (uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

Switch (code) {

Case GET_NUMBER_OF_CAMERAS: {

CHECK_INTERFACE (ICameraService, data, reply)

Reply- > writeInt32 (getNumberOfCameras ())

Return NO_ERROR

} break

Case GET_CAMERA_INFO: {

CHECK_INTERFACE (ICameraService, data, reply)

CameraInfo cameraInfo

Memset (& cameraInfo, 0, sizeof (cameraInfo))

Status_t result = getCameraInfo (data.readInt32 (), & cameraInfo)

Reply- > writeInt32 (cameraInfo.facing)

Reply- > writeInt32 (cameraInfo.orientation)

Reply- > writeInt32 (result)

Return NO_ERROR

} break

Case CONNECT: {

CHECK_INTERFACE (ICameraService, data, reply)

Sp cameraClient = interface_cast (data.readStrongBinder ())

Sp camera = connect (cameraClient, data.readInt32 ())

Reply- > writeStrongBinder (camera- > asBinder ())

Return NO_ERROR

} break

Default:

Return BBinder::onTransact (code, data, reply, flags)

}

}

The real implementation of these three functions is in CameraService.cpp.

The client for this connection is obtained in sp cameraClient = interface_cast (data.readStrongBinder ()); and passed to the connect function. The purpose of saving client information is to save it in CameraService::Client and call back client when appropriate.

2.CameraService

(1) CameraService.h

Class CameraService: public BinderService, public BnCameraService

What is this BinderService? Look at its definition, BinderService.h under frameworks/base/include/binder.

Template

Class BinderService

{

Public:

Static status_t publish () {

Sp sm (defaultServiceManager ())

Return sm- > addService (String16 (SERVICE::getServiceName ()), new SERVICE ())

}

Static void publishAndJoinThreadPool () {

Sp proc (ProcessState::self ())

Sp sm (defaultServiceManager ())

Sm- > addService (String16 (SERVICE::getServiceName ()), new SERVICE ())

ProcessState::self ()-> startThreadPool ()

IPCThreadState::self ()-> joinThreadPool ()

}

Static void instantiate () {publish ();}

Static status_t shutdown () {

Return NO_ERROR

}

}

Return sm- > addService (String16 (SERVICE::getServiceName ()), new SERVICE ()); from this code, you can see that this is native service registering with SM.

In fact, this template class provides a unified way for native service to register with service.

The difference between publish and publishAndJoinThreadPool is whether the thread pool is opened to listen after registration.

Because I have seen the code of media server before, in the main function of media server, it is CameraService.instantiate that is called to register. Because camera service is running in the media server process, camera service does not need to open the thread itself to loop listening.

So, I think the different scenario for calling publish and publishAndJoinThreadPool is: if the service is running in another process, call publish, and if it is a separate process of your own, call publishAndJoinThreadPool.

(2) CameraService.cpp

Implement the three functions defined in ICameraService.

The implementation of getNumberOfCameras () and getCameraInfo () is simple.

Int32_t CameraService::getNumberOfCameras () {

Return mNumberOfCameras; / / mNumberOfCameras is initialized in the constructor, mNumberOfCameras = HAL_getNumberOfCameras ()

}

Status_t CameraService::getCameraInfo (int cameraId

Struct CameraInfo* cameraInfo) {

If (cameraId

= mNumberOfCameras) {

Return BAD_VALUE

}

HAL_getCameraInfo (cameraId, cameraInfo)

Return OK

}

Mainly look at the connect function:

Sp CameraService::connect (const sp& cameraClient, int cameraId) {

Sp client; / / CameraService::Client

.

If (mClient [cameraId]! = 0) {

Client = mClient [cameraId] .client ()

If (client! = 0) {

If (cameraClient- > asBinder () = = client- > getCameraClient ()-> asBinder ()) {

LOG1 ("CameraService::connect X (pid d) (the same client)"

CallingPid)

Return client

}

}

}

.

Sp hardware = HAL_openCameraHardware (cameraId); / / get the CameraHardwareInterface interface, which is passed into when the following code constructs Client

.

CameraInfo info

HAL_getCameraInfo (cameraId, & info)

Client = new Client (this, cameraClient, hardware, cameraId, info.facing, callingPid); / / this is the client saved in onTransact as mentioned earlier.

MClient [cameraId] = client

Return client

}

3.CameraService::Client

Class Client: public BnCamera, Client is the implementation of ICamera.

Constructor:

CameraService::Client::Client (const sp& cameraService

Const sp& cameraClient

Const sp& hardware

Int cameraId, int cameraFacing, int clientPid) {

Int callingPid = getCallingPid ()

LOG1 ("Client::Client E (pid d)", callingPid)

MCameraService = cameraService

MCameraClient = cameraClient

MHardware = hardware

MCameraId = cameraId

MCameraFacing = cameraFacing

MClientPid = clientPid

MUseOverlay = mHardware- > useOverlay ()

MMsgEnabled = 0

MHardware- > setCallbacks (notifyCallback

DataCallback

DataCallbackTimestamp

(void *) cameraId)

/ / Enable zoom, error, and focus messages by default

EnableMsgType (CAMERA_MSG_ERROR |

CAMERA_MSG_ZOOM |

CAMERA_MSG_FOCUS)

MOverlayW = 0

MOverlayH = 0

/ / Callback is disabled by default

MPreviewCallbackFlag = FRAME_CALLBACK_FLAG_NOOP

MOrientation = getOrientation (0, mCameraFacing = = CAMERA_FACING_FRONT)

MOrientationChanged = false

CameraService- > setCameraBusy (cameraId)

CameraService- > loadSound ()

LOG1 ("Client::Client X (pid d)", callingPid)

}

Mainly initialize some member variables, such as mCameraClient, mHardware and so on. It was all done during CameraService::connect.

The functions of Client can be seen for yourself, mainly the call to mHardware, which is a CameraHardwareInterface interface, that is, an encapsulation of the HAL layer. For example, the stopRecording function:

/ / stop recording mode

Void CameraService::Client::stopRecording () {

……

MCameraService- > playSound (SOUND_RECORDING)

DisableMsgType (CAMERA_MSG_VIDEO_FRAME)

MHardware- > stopRecording ()

.

}

4.ICamera

Finally, let's talk about ICamera.

This ICamera defines the interface between camera client and camera service.

When camera client connects to camera service, that is, when CameraService::connect is called, it returns an ICamera interface to camera client call, and the real implementation of this ICamera interface is CameraService::Client.

This is the end of "what is the structure of Camera Service". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.