I was playing around with a simple Android application that makes use of the camera, in order to prove a point about the rotation and mirroring of camera preview frames. I tested the code on my Nexus 4 and Nexus 7 and after making sure that the Android API performed as I expected, I decided to give it a go on an Android virtual device (AVD) on Eclipse. I quickly configured a Nexus 4 AVD with Webcam0 as the front camera, but the emulator did not behave as I expected: the preview picture was rotated 270 degrees! I figured this was due to the unknown scanning order of the webcam on my laptop and therefore this is the resulting quirk. Still, when I switched the front camera to use the emulated camera, I get the same strange results from android.hardware.Camera.CameraInfo.orientation - a 270 degree orientation which is unexpected and not like the behavior of the camera on the actual Nexus 4 device that I own.
OK, so this obviously called for an investigation of how the camera is emulated and why I am getting these strange orientation values. It turned out that the camera orientation is hard coded - but by the time I discovered that code, my curiosity about how the camera works in emulation mode led me to dig deeper.
This three-part blog post is an attempt to review the AVD camera emulation code and the process that I usually use for reverse engineering code. Along the way I added to the Android emulator code to emulate Intel's Atom SoC camera and some other neat (geek talk) stuff. The first blog post will lay all the infrastructure details before I get to the interesting implementation details in the second post.
First thing, first: when you create a new AVD you configure the camera emulation for both the front and back cameras of the emulated device. There are three choice, None, Emulated, and Webcam0. As we will see later, Emulated refers to a completely fake emulated camera which uses synthetically generated image frames. Webcam0 refers to the webcam attached or built-in to your PC or laptop.
The AVD configuration is saved in a file on your workstation (on Windows it is located in %USERPROFILE%\.android\avd\AtomAVD.avd\hardware-qemu.ini) and I'll refer to it later when I describe how the emulator chooses which emulated camera to create. Here's the snippet from my AVD's camera configuration:
hw.camera.back = emulated
hw.camera.front = webcam0
I'll show later that this configuration can be extended with private variables if you need to configure your proprietary emulator.
To wrap up this post I want to give a very high level of the emulation environment. As with all virtual environments, we have three interacting components: the Host OS, the Guest OS, and the emulator. The Google SDK AVD uses the QEMU emulator in "computer emulation mode". To quote Wikipedia:
QEMU (short for "Quick EMUlator") is a free and open-source hosted hypervisor that performs hardware virtualization.
QEMU is a hosted virtual machine monitor: It emulates central processing units through dynamic binary translation and provides a set of device models, enabling it to run a variety of unmodified guest operating systems. It also provides an accelerated mode for supporting a mixture of binary translation (for kernel code) and native execution (for user code), in the same fashion as VMware Workstation and VirtualBox do. QEMU can also be used purely for CPU emulation for user-level processes, allowing applications compiled for one architecture to be run on another.
The diagram below depicts QEMU in full system emulation mode running in parallel to a few other Host applications. QEMU runs as a Host OS process and emulates a full Android mobile device, including an Atom x86 or ARM processor, SoC IPs and various peripherals. On a Linux Host OS, the KVM (Kernel Virtual Machine) driver can be used for virtualizing the CPU and memory. On an x86 Host machine, HAXM (Hardware Accelerated Execution Manager) can be used for further acceleration.
There is a very good description with many further details in this site about Android Emulator Under the Hood.
OK, so this obviously called for an investigation of how the camera is emulated and why I am getting these strange orientation values. It turned out that the camera orientation is hard coded - but by the time I discovered that code, my curiosity about how the camera works in emulation mode led me to dig deeper.
This three-part blog post is an attempt to review the AVD camera emulation code and the process that I usually use for reverse engineering code. Along the way I added to the Android emulator code to emulate Intel's Atom SoC camera and some other neat (geek talk) stuff. The first blog post will lay all the infrastructure details before I get to the interesting implementation details in the second post.
First thing, first: when you create a new AVD you configure the camera emulation for both the front and back cameras of the emulated device. There are three choice, None, Emulated, and Webcam0. As we will see later, Emulated refers to a completely fake emulated camera which uses synthetically generated image frames. Webcam0 refers to the webcam attached or built-in to your PC or laptop.
The AVD configuration is saved in a file on your workstation (on Windows it is located in %USERPROFILE%\.android\avd\AtomAVD.avd\hardware-qemu.ini) and I'll refer to it later when I describe how the emulator chooses which emulated camera to create. Here's the snippet from my AVD's camera configuration:
hw.camera.back = emulated
hw.camera.front = webcam0
I'll show later that this configuration can be extended with private variables if you need to configure your proprietary emulator.
To wrap up this post I want to give a very high level of the emulation environment. As with all virtual environments, we have three interacting components: the Host OS, the Guest OS, and the emulator. The Google SDK AVD uses the QEMU emulator in "computer emulation mode". To quote Wikipedia:
QEMU (short for "Quick EMUlator") is a free and open-source hosted hypervisor that performs hardware virtualization.
QEMU is a hosted virtual machine monitor: It emulates central processing units through dynamic binary translation and provides a set of device models, enabling it to run a variety of unmodified guest operating systems. It also provides an accelerated mode for supporting a mixture of binary translation (for kernel code) and native execution (for user code), in the same fashion as VMware Workstation and VirtualBox do. QEMU can also be used purely for CPU emulation for user-level processes, allowing applications compiled for one architecture to be run on another.
The diagram below depicts QEMU in full system emulation mode running in parallel to a few other Host applications. QEMU runs as a Host OS process and emulates a full Android mobile device, including an Atom x86 or ARM processor, SoC IPs and various peripherals. On a Linux Host OS, the KVM (Kernel Virtual Machine) driver can be used for virtualizing the CPU and memory. On an x86 Host machine, HAXM (Hardware Accelerated Execution Manager) can be used for further acceleration.
There is a very good description with many further details in this site about Android Emulator Under the Hood.
Harrah's Casino Hotel & Racetrack - MapYRO
ReplyDeleteFind Harrah's Casino Hotel 광양 출장안마 & Racetrack 안성 출장마사지 locations, 수원 출장마사지 rates, 문경 출장마사지 amenities: 광주광역 출장안마 expert Harrah's research, only at Hotel and Travel Index.