Open camera anomaly analysis (I)

        Some three parties and other scenarios are used in the project camera Cause problems , And not released in time camera device Cause mobile phone camera The serious problem that the application has been unable to use , A series of analysis and tracking have been carried out for this kind of problems , Finally, the problem is located and some solutions are provided , But the whole process of tracing back to the solution has to be thought-provoking , In case this happens in the future , How to achieve efficient and perfect processing at the bottom .

1. abnormal log Analysis and traceability ：

         First of all, DreamCamera2 apk Call the process for analysis ,15:08:35  open fail Report errors , And then to the abnormal before and after CameraService、HAL Layer correlation log Analyze , The positioning reason is camera device occupied , need check other apk Or the package is right Camera Device Usage situation .

2. Camera CameraService Layer to view other package pairs camera device Call to

        Check the related log Find out ,15:06:34 com.sprd.validationtools call camera device An exception has occurred in the phase , The two calls before the exception are 15:06:03、15:06:31, Both are called camera id 1, This is the front shot ,15:06:03 No, disconnect Related actions ,15:06:31 perform openCamera 3s Then it happened openCamera fail An error is reported for the exception , And then to camera device The call of will always report too many other clients connecting It's abnormal . 

        15:06:34 Feedback camera connect erro The question is about 15:06:31 openCamera error A feedback callback of the status .

3. Yes 15:06:03 openCamera Then analyze the abnormal process

        Camera open After through API 1 call startPreview Open Preview , At  15:06:03.085

         15:06:07 Camera2Client appear sync with HAL Abnormal error reporting

          15:06:08 appear cmr_prev frame error The error of

         15:06:16 events.log Inside com.sprd.validationtools appear anr abnormal , Abnormal duration 10s, And frame error The time coincides , And then directly destory fall FrontCameraTestActivity.

4. Yes 15:06:31  The time period opens again camera Process and abnormal points .

         15:06:31.514 Manually select open FrontCameraTestActivity

         15:06:34.587 Print open fail abnormal ,FrontCameraTestActivity Can't call startPreview.

 2. Abnormal summary

        The problem is ： The outliers are 15:06:03 openCamera After that 3s A frame occurred after time error The preview frame will not come up , causing anr destory Drop the whole thing activity.( frame error Following analysis, it is determined that the hardware frequency interference leads to )

        difficulty ： This problem is caused by the frame error As a result of , But the headache is the frame erro Then it triggered ANR Processing mechanism , Not at all Camera Exception handling mechanism of , This leads to CameraDevice The state of cannot clear、reset To the previous original state , about Camera HAL Come on , Will think that there is a client Always with him connecting In state , Lead to the following camera device The use of connect fail.

        Solve the misunderstanding ： The initial solution is in Camera apk Go inside and deal with openCallback return openFail State to re trigger openCamera Operation and configureSession Flow distribution operation . In fact, at this time, certain thinking patterns let us fall into a big misunderstanding .

        Trace code through segments , stay CameraService It found the wrong answer ,Camera APP And Camera HAL establish Client、Server When contacting , But I need you packageName、clientPid、clientUid Of , Combined with this problem , Exception is com.sprd.validationtools call camera open There is an exception in the phase , But we chose to com.android.camera2 It handles exceptions , Now it's a little ridiculous , It's not just that you can't be different package Inside to solve the exception , In the same package Inside was destory It fell off , Again create After that, all exceptions will be handled in camera Layers of connect Problems become unrecognized and unrecognized , Because it corresponds to pid It has changed .

        That's why camera apk Inside again reopen Camera You can then resume the preview , But switch to another mode or again openCamera There will still be reasons for abnormal error reporting .

          Follow up plan ： This problem is currently located in the frame error Caused by frequency interference of hardware , The hardware department came up with an evasion plan . But for Camera Team For Engineers , This problem requires us to monitor camera device At the same time , To establish a mechanism for monitoring preview frames , Once within a certain time frame error No updates , We must adopt a standard camera device destory The process goes on release operation , Otherwise, it will cause a series of follow-up big problems .

        Of course, there is a very important point ： This is not just about camera apk Create frame error Monitoring mechanism , For any other call camera device Of package Come on , All need such a mechanism , Otherwise, such problems will occur , And the rest of it package It's all because packagesname、pis、uid There is no way to deal with this process .

3. Technical summary

        1. This problem involves different packages call camera Devices The problem of , Analytical thinking should not be limited to camera app Layer related interfaces , even to the extent that Framework The layers are different camera API, Only in CameraService、HAL Layer to whole check All of the camera Call the abnormal process and state .

        2. For different apk Use camera device Abnormal but not handled in time , You need to find a better interface at the bottom to achieve something similar reset all devic The interface of .( Like many different apk Call audio pcm device The problem of ,open But never do it close operation , This leads to other people wanting to use audio device The equipment apk Always in busy state )

4. summary

        In fact, I am afraid to think about this question carefully , Whether it's a mobile phone or a tablet or even IOT project , Will encounter many different uses to camera device Scene 、 application 、apk etc. , For the bottom , Only the front and back shots are fixed sensor For so many applications , In case the design of an application is unreasonable , It did happen. I broke up with it , Lead to camera device there is no way out close Drop operation , Or there's something that makes camera device It is always an occupied operation , It really makes me bald .

        alike , Audio device We often encounter such problems , For the whole mobile phone , Different applications preempt Limited device, The whole thing open、close It is really difficult to control the timing perfectly , We can only forge ahead , Choose to keep encountering problems 、 Solve the problem ！！！