Android and Mobility Technologies

In April 2020, MoT was established when JapanTaxi and DeNA’s MOV, DRIVE CHART, and other businesses were integrated. Even though many people may not know the company name, they have seen the “GO” logo around town. MoT has partnered with 100,000 taxis nationwide. As of September 2021, the “GO” app has been launched in 20 of Japan’s prefectures. Even during the pandemic, app use has increased significantly. In the one year after its release, the app was downloaded 5 million times.

Also, at DroidKaigi 2019, JapanTaxi set up a booth to exhibit its products for reconfiguring taxi on-board hardware. Some readers may also remember this display.

A distinctive feature of MoT’s Android app development is that we not only develop the smartphone app for the general public, but Android apps capable of operating on a variety of devices, such as an app for taxi drivers that allows them to receive pickup requests and on-board systems employing the Android environment including tablets mounted in taxi backseats.

Introduction to our teams

This article provides a look at the two Android app development teams involved with the “GO” app: the team developing the user app that taxi riders utilize and the team developing the taxi on-board system.

The user app team makes full use of the camera, microphone (audio integration with tablet), telephone calls, GPS, push, and other Android features

First, here is an introduction to the user app team developing “GO” for the general public.

As mentioned previously, “GO” is a taxi app that was created when the “JapanTaxi” app developed by JapanTaxi and the “MOV” app developed by DeNA were integrated in April 2020. It was in this context that the user app team was created when engineers from JapanTaxi and others from DeNA joined together.

April 2020 was also when the initial state-of-emergency declaration was issued during the pandemic, so the user app team was essentially working on development remotely. On account of that initial setup, they have yet to, believe it or not, actually all assemble in one place at the same time.

The user app team is currently working on enhancing code serviceability and scalability. Within a context involving multiple features even just to originally realize a taxi dispatch service with the camera, microphone, GPS, telephone call, and other features, successful integration of the two apps has led to more and more features that we would like to implement. As we are also welcoming new team members, serviceability and scalability are key themes. We are re-factoring the existing code daily so that we may reduce legacy code, yet, at the same time, we have also taken up the challenge of multi-modularizing new components.

The following is a simplified illustration of the “GO” module structure.

“GO” is separated into modules for each layer and feature. Unique characteristics are the android-core and repository layers, which are left unseparated.

We did discuss whether or not to divide the repository according to specific features. We made the decision that, for the “GO” app, we would gain little in return compared to the demerits resulting from separation (increase in boilerplate code, etc.). In addition, the android-core was arranged as a layer encompassing a common class that is neither the repository, nor a model.

Because we are developing a large-scale app, we are particularly sensitive to stability when adopting any new technology. As with the development of multiple modules mentioned earlier, the challenge we face when developing new features is to incorporate new technologies while keeping the scope of impact to a minimum.

For example, when we developed a new feature for in-app payment with “GO Pay,” we used CameraX, which had just come out at the time in the Google I/O 2019 release, for getting around camera-related problems that developers often suffer with Android. In these and other decisions, we have taken care to balance our investment in technologies so that we maintain stability while bringing in innovation.

We have a video that provides more detail about what has been discussed here. Please also be sure to take a look at the archive in our blog.

Development team for the on-board Android terminal interfacing with multiple external devices amid conditions of extreme temperature and radio waves

Next is our on-board Android terminal development team which develops on-board systems for taxis (driver terminals and rear seat-mounted tablets).

The team is comprised not only of Android engineers specializing in embedded systems, but also engineers who have switched over from developing Android smartphone apps for the general public.

Here is one example of our technology.

This example shows how the driver’s device (with SIM card) connecting directly to the Internet and the rear seat-mounted tablet (without SIM card) which does not are able to use WiFi-Direct and VpnService to provide Internet communication to the rear seat-mounted tablet.

This is achieved using a configuration where VpnService, which is essential for implementing a VPN connection, is used to acquire all communications originating on the non-SIM device, which are then transmitted to the SIM terminal via WiFi-Direct.

Nevertheless, there was one issue that arose here. In contrast to VpnService for which all network packets are sent, Java’s existing socket communication has removes the header from all communication protocols. We could not establish communications with this combination. So, we provided our own implementation with a class capable of handling the TCP/IP protocol stack.

While some people might feel culture shock when engaging in development in such a field that is different from app development, we maintain an environment where we have gained an extensive range of technological knowledge because we need to be concerned about things such as signal quality when a vehicle enters a tunnel, equipment installation situations and other such scenarios that engineers are not necessarily concerned about when developing Android smartphone apps for the general public.

If anyone reading this example feels “Hey, why not just use tethering?”, then please be sure to take a look at the archive in our blog for a video providing a more detailed explanation of this case.

I hope that you enjoy these kinds of constrains specific to domains a little bit different from smartphone apps for the general public, and other facets particular to vehicle on-board systems.

In conclusion

MoT, a transportation sector specialist, has launched not only the “GO” app presented here, but also a variety of businesses. We have many opportunities for Android engineers to put their skills to work.

• Taxi app “GO,” a starting point for revolutionizing the way people get around
• Food delivery app “GO Dine” bringing people the luxury of savoring delicious meals at home
• “DRIVE CHART,” the next generation AI drive-recorder service leveraging AI to help reduce traffic accidents
• Spatial-data project developing infrastructure for utilizing traffic data, as well as other ventures and projects

We are looking to hire colleagues who would like to take up the challenge together with us of achieving our mission of “bringing joy to people in their travels. ” If you are interested, please check out our technology blog and career information here.

About the author

Technology Communications Team

We are a team of engineers assembled from different divisions who plan online events and active on Twitter. Our Android engineers usually work in Kotlin, but we recently began using Flutter!

Please be sure to follow our official Twitter account @mot_techtalk where we are constantly posting the latest information about MoT’s technologies!