Saravana Pandian Annamalai
17. October 2018 · Write a comment · Categories: Android · Tags: ,

Android offers few emulators for development purposes. As a part of standard AOSP (Android Open Source Project), these emulators come in handy for development such as customization, debugging, middleware development, app development etc. But for underlying hardware access most of the other higher-level developments can be done over these emulators. There are quiet a few variants of emulators such as for general Phone/Tablet emulation or for automotive purposes – Car Emulator. This blog will focus primarily on building Android car emulator and running it in the system. We will also touch up on compiling the kernel from the source and running them as well.

Downloading AOSP source for emulation

First thing to start building car emulator is to finalize on the release version we want to build against. The list of supported variants is available in the Codenames, Tags, and Build Numbers page from the android web site. Based on the requirements, identify the version – in this case let us assume we want to build for OPM6.171019.030.B1. Note the build version it corresponds to android-8.1.0_r33.

Now we will have to download the source code for the same. Android source code is in fact a collection of git repositories. Each of the major directories in the AOSP corresponds to a separate repository. Since it is difficult to manage such a large code base individually one by one, Google has created a tool called repo that helps in this process. Install this tool with the following steps

mkdir -p ~/bin
wget ‘https://storage.googleapis.com/git-repo-downloads/repo’ -P ~/bin
chmod +x ~/bin/repo

Now that the tool is downloaded, set up your git configuration using the following commands

git config –global user.name “your name”
git config –global user.email “your_email@your_domain.com”

Assuming you are running Ubuntu 16.04, to prepare the environment, execute the following

sudo apt-get update

Install the dependencies:

sudo apt-get install openjdk-8-jdk android-tools-adb bc bison build-essential curl flex g++-multilib gcc-multilib gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev libesd0-dev liblz4-tool libncurses5-dev libsdl1.2-dev libssl-dev libwxgtk3.0-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc yasm zip zlib1g-dev

Identify the working directory and create it if necessary.

mkdir -p ~/aosp

Switch to the directory

cd ~/aosp

As mentioned earlier, we need the manifest file to being with. This initial file can be set up using the following commands.

The above command will download an XML file called “manifest.xml” that contains information about all the git repositories that constitute the AOSP.

Since the above command will download a large set of objects including previous versions, if you want to limit the download size, you can set the downloaded version depth to 1.

repo init -u https://android.googlesource.com/platform/manifest -b android-8.1.0_r33 –depth=1

With everything set, being the download using the following command.

repo sync

This command will perform the actual download operation all the necessary repositories and prepare the directory for further building.

Building Car Emulator

We can now start building Android car emulator. Once again being a large project, it is better to set up a compiler cache so that the incremental builds are quite faster.

export USE_CCACHE=1
prebuilts/misc/linux-x86/ccache/ccache -M 15G

Below output confirms that the command executed successfully.

Output

Set cache size limit to 15.0 Gbytes

Powered by the Soong build system, the AOSP employs a variety of tools to build the source and create the images. Jack compiler used employs a server mechanism where by a single process running in the system compiles files. To configure the same, execute the below commands such that the Java based tool uses the configured amount of RAM for the JVM. In this example, it is limited to 6GB.

export ANDROID_JACK_VM_ARGS=”-Xmx6g -Dfile.encoding=UTF-8 -XX:+TieredCompilation”

With every thing set up now for building the source, now configure the environment variables used by the Android build system using

source build/envsetup.sh

The source command simply executes the given script in the same shell so that its environment variables are affected. Below output is shown

root@aosp:/home/user1/aosp/ # source build/envsetup.sh
including device/asus/fugu/vendorsetup.sh
including device/generic/car/vendorsetup.sh
including device/generic/mini-emulator-arm64/vendorsetup.sh
including device/generic/mini-emulator-armv7-a-neon/vendorsetup.sh
including device/generic/mini-emulator-mips64/vendorsetup.sh
including device/generic/mini-emulator-mips/vendorsetup.sh
including device/generic/mini-emulator-x86_64/vendorsetup.sh
including device/generic/mini-emulator-x86/vendorsetup.sh
including device/generic/uml/vendorsetup.sh
including device/google/dragon/vendorsetup.sh
including device/google/marlin/vendorsetup.sh
including device/google/muskie/vendorsetup.sh
including device/google/taimen/vendorsetup.sh
including device/huawei/angler/vendorsetup.sh
including device/lge/bullhead/vendorsetup.sh
including device/linaro/hikey/vendorsetup.sh
including sdk/bash_completion/adb.bash

Now choose the platform you want to build. For example, we can either build the car emulator for 32-bit X86 system or 64-bit x86 system.

For building for 32-bit, use the below command.

lunch aosp_x86_car_emulator

For 64-bit use,

lunch aosp_x86_car_emulator

Typically, you will see the below output.

============================================

PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=8.1.0
TARGET_PRODUCT=aosp_car_x86
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_PLATFORM_VERSION=OPM1
TARGET_BUILD_APPS=
TARGET_ARCH=x86
TARGET_ARCH_VARIANT=x86
TARGET_CPU_VARIANT=
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-4.4.0-137-generic-x86_64-with-Ubuntu-16.04-xenial
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=OPM6.171019.030.B1
OUT_DIR=out
AUX_OS_VARIANT_LIST=

Initiate the build now with make command. To leverage the multiple CPU cores, present in your host machine, specify a number corresponding to it.

make -j8

It will take about 1 hour to 3 hours for the build to complete depending on the host system configuration.

Creating filesystem with parameters:
Size: 2684354560
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 10240
Label: system
Blocks: 655360
Block groups: 20
Reserved block group size: 159
Created filesystem with 2219/163840 inodes and 219060/655360 blocks
[ 99% 64341/64342] Install system fs image: out/target/product/generic_x86/system.img
out/target/product/generic_x86/system.img+ maxsize=2740556544 blocksize=2112 total=2684354560 reserve=27684096
[100% 64342/64342] Create system-qemu.img
1+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00427205 s, 245 MB/s
2560+0 records in
2560+0 records out
2684354560 bytes (2.7 GB, 2.5 GiB) copied, 3.17107 s, 847 MB/s
1048576+0 records in
1048576+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 1.86999 s, 561 kB/s
Creating new GPT entries.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Setting name!
partNum is 0
REALLY setting name!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
#### build completed successfully (01:26:36 (hh:mm:ss)) ####

Running the Car Emulator

Once the build is completed, the images will be created inside the out/target/< product >/directory. The emulator can now be invoked using

emulator

Typically, you will see the emulator running as below.

Now you can connect to it over ADB and perform various operations such as installing a new App, debugging it, modifying the AOSP source and testing it etc.

Compiling the kernel

The emulator can be launched to show the kernel output and console by using the show kernel option as below.

emulator –show-kernel
generic_x86:/ $

In the login, we can check the kernel version using uname command.

We can see, this emulator runs kernel version 3.18.74+. Looking for the source, it can be found that it is available in the repository as commit c57e557. Download the same using the below commands:

Get goldfish branch c57e55706abeffafbc52d28155297650dae6e2c0

Build the same using the following commands:

git clone https://android.googlesource.com/kernel/goldfish/ -b android-goldfish-3.18
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9
cd goldfish
export CROSS_COMPILE=x86_64-linux-android-
export ARCH=x86_64
export PATH=$PATH:/path/to/x86_64-linux-android-4.9/bin
make x86_64_ranchu_defconfig
make menuconfig # enable overlayfs and namespaces support here
make -j8

The output kernel will now be available at arch/boot/x86/bzImage

This image can be used for the emulator when launching as follows:

emulator -kernel <Path to kernel directory>/ arch/boot/x86/bzImage

By giving uname now, it can be seen that the build time/machine reflects

Building Android Car Emulator and running it in the system helps to accelerate various platform/application developments. It is possible to complete some part of underlying driver/HAL development using this kernel in this approach.

About Embien: Embien Technologies is a leading service provider for the Android technologies including Android porting, HAL development, HIDL developments, custom system services, deployment, App development etc. Our team extensively uses emulator for speeding up the developments even before the underlying hardware is available. Apart for developing Auto-infotainment systems, customized tablets, Home Automation consoles, rugged handhelds, Industrial HMI’s, our SMEs offers corporate training covering topics such as Android Platform development, Android for Automotive and Linux Device Drivers.

Earlier, in a series of blogs on eStorm-B1 BLE module, we have discussed about few applications of the module such as smart metering, as a Bluetooth to serial adapter along with a demo of the same. Further to a very positive response to the module, Embien has come up with an Evaluation Kit for the same. Incorporating various features targeting different market segments, we have designed the EVK as a ready to use product. This blog will introduce the reader to the kit for eStorm-B1 BLE module and in detail its application as a BLE to RS232 MODBUS converter

RS232 Modbus serial interface 

RS232 serial interface is still one of the most used wired communication standards. Introduced in 1960, it has survived and still surviving onslaught from many advanced standards because of its reliability and simplicity. They are intended to operate over a distance up to 15 meters and the maximum data rate is around 160 Kbits per second. They are often being used in many applications such as data acquisition systems, PLCs etc. While the underlying logical layer can be handled by UART interface, there are many possible application layer protocols that can be run on it. One of the most popular industrial protocol standards is called Modbus.

Modbus is a serial communication protocol developed for transmitting information over serial lines between electronic devices. The Modbus network can have one Master device and up to 247 slave devices. The master device can request or write the information to the slave and the slave device will supply the information. Registers are allocated for each data in the slave device and the master will write or read data to and from a slave device’s register.

It is an open protocol, where the manufacturer can build into their equipment without any royalties. The protocol has multiple versions such as Modbus RTU, Modbus ASCII for serial communication and Modbus TCP for Ethernet. Modbus has become the standard communication protocol in industry and it is a commonly available means of connecting industrial electronic devices.

Need for Wireless Communication 

Day by day, the communication interfaces and protocols are being updated to handle large data more reliably and over a longer distance. Of late, due to the advent of Industry 4.0 and IIoT, the need for wireless communication becomes inevitable. Industry 4.0 brings smartness in automation and data exchange in manufacturing technologies. It includes IoT, cloud computing, etc which calls for seamless data communication. Existing infrastructure can enable them with minimal changes using wireless technologies. This necessitates a suitable gateway for converting the wired serial interfaces to wireless.

Embien, following the current industry trends has launched a wireless module “eStorm-B1” under its eStorm series of solutions. The BLE module can support wireless serial communication with the available UART interface and can readily be used as a BLE to UART converter bridge. In addition to the COTS BLE module, Embien has also launched an evaluation kit “eStorm-B1 EVK”. This evaluation kit can support quick evaluation of eStorm-B1 module features.

Following are the features of eStorm-B1 EVK,

  1. 1X RS232 or RS485 serial interface
  2. 1X CAN interface
  3. 1X LIN interface
  4. One analog input and one isolated digital input for external sensor interface
  5. One digital output for external load control
  6. Onboard EEPROM
  7. Onboard Accelerometer
  8. Battery operated with inbuilt battery charger
  9. Compact dimension with mounting holes
  10. Screw type PCB connectors for serial and CAN interface enabling rigid connection to external devices
Evaluation kit for eStorm-B1 BLE module

Evaluation Kit for eStorm-B1 BLE Module

eStorm-B1 EVK as Wireless Modbus gateway

Of various interfaces, one that interests us for this blog is the presence of a RS232 interface. eStorm-B1 EVK based BLE to RS232 Modbus converter is suited for wireless Modbus gateway applications discussed earlier. eStorm-B1 EVK supports three wire RS232 serial communication via null modem cable and is exposed via a screw type PCB Terminal connector. Designed for rugged industrial environments, the EVK can operate in 5V DC input and RS232 receiver can accept up to +/- 30V input withstanding surges up to 15-kV (HBM) in the RS232 lines. Optional enclosure is also available.

On the protocol front, it includes a fully tested Modbus Client stack. It can query Modbus slaves present in the line. Android application is also available that can be used to configure the device and acquire data. Some of the features supported by the eStorm-B1 EVK based Wireless Modbus Gateway are,

  • Configuration of baud rate, Stop and data bits.
  • Modbus RTC/ASCII support
  • Continuous data acquisition
  • Notification based on change of value
  • Customizable buttons in the App for simple configuration of Modbus slaves

Thus eStorm-B1 as a wireless Modbus gateway can be used to interface with multiple devices for applications such as wireless data acquisition via existing data acquisition device, controlling the machines via PLCs for various industrial automation application, etc.

About Embien

Embien Technologies is a leading provider of embedded design services for the industrial automation. We have done various types of Data acquisition Systems, Industrial Human Machine interfaces, BLE based pH Meters, precision measuring instruments etc. We are currently working on enabling the industry 4.0 initiatives to make them smarter and greener.

Understanding the growth of new technologies and keeping in mind of giving an added value to its existing product eStorm-L1, Embien launched an Android app named “DAQ Suite”. With experience in developing Android app for many segments such as IoT, healthcare, automotive etc we have developed “DAQ Suite” for enhancing user experience in multiple industrial applications such as remote control, remote data acquisition/logging, etc.

This blog is the sequel of the blog “eStorm-L1 as GSM based remote switch” demonstrating the relay control and sensor monitor via an Android app. The following video shows the remote monitoring and control application typically applicable in industrial domain and many other verticals. The demo is setup using the GSM based remote switch and android application controlling the device through SMS command.

For the demo purpose we have connected two LED’s and two switches for demonstrating the relay control and sensor monitor functionality respectively. In the real time application, the LED could actually be a relay with suitable external DC supply for coil excitation and switch could be a sensor/transducer output preferably a digital high/low signal or even a pulse type output. The device stores all the configuration settings corresponding to the user, IO, etc in the EEPROM and hence preserved even on power cycling. Also the device has an option to erase the memory on site and start the user settings from the initial factory default.

The DAQ Suite android app includes the following menu options

  1. Device type selection setting – To select the type of the device need to be monitored or controlled. Available device will be listed in the Device model list box.
  2. User settings – To set the user details such as name, phone number, password, device description, and phone number to be taken for call actions etc.
  3. Relay settings – To set the on duration, ON/OFF delay etc. For multiple relays, the name of the device attached to the relay can be set.
  4. Update settings – To set the update interval for how much time interval the user need to receive the SMS about the current status of the relay and digital input. Many options can be chosen from the list view such as on change, periodic, both and none.
  5. Call actions settings – To set the action to be done on the relay upon calling the device. Either the relay can be switched ON/OFF.

The main screen of the DAQ suite includes the status of the SMS command being sent and time information of the last received/sent SMS. The control switch to toggle the relay and the status LED of the digital inputs is also included in the main screen.

Upon every operation, a SMS will be sent to the device with the predefined command set and the respective status of the digital inputs and relay will be displayed on the main screen based on the acknowledge SMS from the device.

DaqSuite, the user friendly Android App for GSM based remote switch and sensor monitor applications is available in Google Play store. Feel free to try it or contact us for more information.

About Embien: Primary focus of Embien technologies lies in the Industrial Automation segment. We have a rich experience in working on industrial automation and control systems with customers across geographies to enable their factories and assembly lines run efficiently. Our team have developed protocol stacks for various industrial protocols and enabled them in customer devices. We have created various Human Machine Interfaces (HMI) systems to make easier the interface with the machine. Our Machine to Machine (M2M) service offering includes developing system capable of remote monitoring and controlling of machines, PLC’s, etc.