Camera framework requires 352x288, and 320x240 frames for video preview and video
recording. If these dimensions are missing in camera properties the camera app
may abort when entering video mode, or start video recording.
Also truned off switching fake frames, leaving only the checker board.
(cherry picked from commit 6f00e7fc48)
Change-Id: Ic50225e1700ea3b04ae5445549548f2ffe4ae2df
Implement CAMERA_MSG_PREVIEW_FRAME callback
Also does better work detecting pixel format for video frames, depending on the
mode that camera is intended to be operated with.
Change-Id: Idb2dfc7c0a79e81eff58f83a14af769afc713096
Also does better work detecting pixel format for video frames, depending on the
mode that camera is intended to be operated with.
Change-Id: I352204b8d6d1a9e7857d77b6363de2bb5d5db0dd
Don't cofuse preview window with preview frames. Preview frames are relevant only
in panoramic mode that receives frames via CAMERA_MSG_PREVIEW_FRAME callback.
Change-Id: Ibecb345e43ba452856b8ca75449264d8d354a9d5
Sometimes framework chooses to override the default JPEG quality value (90), so we need to
respect that when compressing frame during picture taking.
Change-Id: Ic7ad8938d33d94d34ecd0b979e5c8c3e8246fd53
Apparently, video pixel format expected by the camera framework is YU12, and not YV12
as it was implemented.
Change-Id: Id33d8aa7f62f6e68276774ca2a7d25c04acd71cc
These two tasks (starting the camera device, and starting working thread that pulls frames
from the started camera device) should be clearly separated, and should not be combined in
one method (as it was with the 'startCapturing' method).
Change-Id: I779bee924d99d9a87257c6b76791545b76795e72
Holding an object lock while macking the callbacks cause deadlocks
due to reentrance to the callabck notifier.
Change-Id: I5f2780989798ebf5c5d7aab34ac233bb5952079d
When stopping the camera, the working thread should be stopped before sending
"stop" query to the emulator: we don't want "frame" queries to be floating around
while we're in the process of stopping the camera.
Change-Id: I16dc56ca1c2e304a07a074302001d2e27100f2ac
The code submitted here builds a camera.goldfish.so module that encapsulates a camera HAL.
The major components of the camera HAL implementation are:
* Generic HAL module implemented in emulated_camera_hal.cpp There is nothing much
to it: just exporting the required HAL header.
* EmulatedCameraFactory class that manages emulated cameras, and provides handling for
camera_module_methods_ methods. There is only one object of this class, that is statically
instantiated when camera.goldfish.so module is loaded.
* EmulatedCamera class that implements camera_device_ops_t API. Objects of this class are
instantiated during EmulatedCameraFactory construction, and they interact with objects
of EmulatedCameraDevice class to get frames.
* EmulatedCameraDevice class encapsulates an actual camera device. Objects of this class
are contained in EmulatedCameraDevice objects, and interact with them as required by the
API.
The fake camera implementation is shared between EmulatedFakeCamera, and EmulatedFakeCameraDevice
classes. They are pretty light. In fact, EmulatedFakeCamera is nothing more than just a
placeholder for EmulatedFakeCameraDevice instance, and EmulatedFakeCameraDevice does nothing
more, than just drawing a checker board with a bouncing square.
Other components / routines are minor: helpers, wrappers, etc. The code is heavily commented,
so there will be plenty of explanations between the lines.
Change-Id: I4463e14c255c6e3b1dcca17bed5f4efde32d9879
See hardware/libhardware/include/hardware/qemu_pipe.h for the API
implemented by the library. It enables very fast reads/writes between
the guest system and specific emulator services.
Define BUILD_LIBQEMU_TESTS=true in your environment to build the
test programs (a simple host ping-pong server, and a benchmark
guest program).
You can invoke them with:
1/ Testing TCP pipes:
host: test-libqemu-1 -tcp 8012
guest: test-libqemu-2 -pipe tcp:8012
Alternatively
guest: su
test-libqemu-2 -tcp 8012
2/ Testing Unix pipes:
host: test-libqemu-1 -unix /tmp/libqemu-socket
guest: test-libqemu-2 -pipe unix:/tmp/libqemu-socket
3/ Testing internal pingpong server (within the emulator)
host: /* nothing to do */
guest: test-libqemu-2
Change-Id: Ib50fc9cbee6b5f4581baca97412d6f69d4f84860
Unfortunately, we need to keep duplicate libraries under sdk/emulator/
to avoid breaking a few internal branches.
commit 776bd3e46c
Author: David 'Digit' Turner <digit@android.com>
Date: Thu Apr 7 10:58:07 2011 +0200
emulator: Remove the global Make variable trick for emulator-specific system modules.
Remove a sad trick that was used to smoothly move the platform-specific emulator
modules from sdk/emulator/ to development/tools/emulator/system without creating
build conflicts.
Now that the sdk/ modules have been removed, we can get rid of the guard variable.
Change-Id: Id5c44a4160191d8ac9afcbbeeef7de0b9a5b0f6f
Remove a sad trick that was used to smoothly move the platform-specific emulator
modules from sdk/emulator/ to development/tools/emulator/system without creating
build conflicts.
Now that the sdk/ modules have been removed, we can get rid of the guard variable.
Change-Id: I0261fcd6cdf6af7564106c5ab8d2b3bda001d567
This copies the platform-specific emulator modules from sdk.git into
development.git/tools/emulator/system/. Note the use of guard variables
to prevent clashes when the original modules are still in the tree.
The goal is to submit this and https://review.source.android.com/#change,21737,
then later remove the modules from sdk.git when we move the internal sdk branch
to the appropriate tools_rXXX branch.
Change-Id: I762d0efb72d93a935d96c4549f36029c258c3ef9
