Installing an Alternate SSL Provider on Android
At this point, the CyaSSL provider is fully installed into the Android platform. You can move on to building and testing the platform with the new provider installed. If no errors arise during the platform build, the provider can be loaded into the emulator to make sure the platform runs correctly with the new provider installed.
The build process can take a significant amount of time depending on the build environment. All commands should be run from the Android platform root:
$ source build/envsetup.sh [Sets environment variables] $ lunch 1 [Builds the emulator] $ make [Builds the Android Platform]
Keep in mind that it is possible to rebuild a single project (such as the CyaSSL shared library) to test that the shared library builds correctly using the mm command (shown below), but before testing in the emulator, a full platform build needs to be done:
$ cd external/cyassl $ mm
The Android platform build process results in three image files: <Android-Platform>/out/target/product/generic/ramdisk.img, <Android-Platform>/out/target/product/generic/system.img and <Android-Platform>/out/target/product/generic/userdata.img:
ramdisk.img — a small partition that is mounted as read-only by the kernel at boot time. It contains only /init and a few configuration files. It is used to start /init, which will boot the rest of the system images and run the init procedure.
system.img — a partition image that will be mounted as / and contains all system binaries. This is the image file that contains all of the changes that were made above.
userdata.img — this image is used only when the -wipe-data option is used with the emulator. In a normal emulator execution, a default userdata image will be used.
Of these, system.img is of the highest concern. It contains the majority of the system and all of the changes that have been made with the addition of the CyaSSL SSL provider.
Before you can use the Android Emulator, you must create an Android Virtual Device. Android Virtual Devices are configurations of emulator options that allow developers to model a physical Android device better. They hold configuration information, such as a hardware profile, a mapping to a system image and a dedicated storage area. To create an Android Virtual Device, the android application is used. This application is found under the tools directory of the SDK. Create a new Virtual Device using the following command (issued from the SDK /tools directory):
$ android create avd -n <desired-name> -t <target-version>
where <desired-name> is the name of the Android Virtual Device and <target-version> is the desired target platform. Run the following command to view available targets:
$ android list targets
After the Android Virtual Device has been created, load the emulator with the built images:
$ emulator -avd <virtual-device-name> -system <Android-Platform>/out/target/product/generic/system.img -data <Android-Platform>/out/target/product/generic/userdata.img -ramdisk <Android-Platform>/out/target/product/generic/ramdisk.img
There are other useful emulator options that may be added to the above command. A few are listed below, but for a complete list see the official Android Emulator Web page:
-verbose — verbose output.
-nocache — don't use a cache.
-show-kernel — print kernel messages to the terminal window.
Once the emulator is running, the logcat output can be viewed in a new terminal window (assuming the current directory is <Android-SDK>/tools):
$ adb logcat
In this article, installing an alternative SSL provider into the Android platform is explained using CyaSSL. By using CyaSSL in the Android platform instead of OpenSSL, developers are able to leverage both the speed and size advantages of the CyaSSL library. Making use of both a shared library and JNI, the same general process could apply to installing other third-party libraries into the Android platform and could provide a good reference for developers moving C libraries over to Android from other operating environments.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Android's Limits
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?