I want to write an activity that:
With approach 2 the issues is stability. I tried some examples, but I've managed to stop the camera from working (until a restart) on some devices and completely freeze another device. On another device the capture worked, but the preview stayed black.
Either there is a bug in the examples or there is a compatibility issue with the devices.
The example that CommonsWare gave works well. The example works when using it as-is, but here are the issues I ran into when modifying it for my use case:
PictureCallback.onPictureTaken()
has been called. The CommonsWare example uses the inPreview
flag for this purpose.SurfaceView
is full-screen. If you want a smaller preview you might need to change the preview size selection logic, otherwise the preview might not fit into the SurfaceView
on some devices. Some devices only support a full-screen preview size, so keeping it full-screen is the simplest solution.To add more components to the preview screen, FrameLayout
works well in my experience. I started by using a LinearLayout
to add text above the preview, but that broke rule #2. When using a FrameLayout
to add components on top of the preview, you don't have any issues with the preview resolution.
I also posted a minor issue relating to Camera.open()
on GitHub.
"the recommended way to access the camera is to open Camera on a separate thread". Otherwise, Camera.open() can take a while and might bog down the UI thread.
"Callbacks will be invoked on the event thread open(int) was called from". That's why to achieve best performance with camera preview callbacks (e.g. to encode them in a low-latency video for live communication), I recommend to open camera in a new HandlerThread, as shown here.