After the decision to build a dedicated device that is widely available to users, it is necessary to make a few key decisions when it comes to, hardware, the application development technology stack, customized device UX, deployment, remote debugging and logistics. Each of these concepts represents an important segment of the entire system, and if one is selected incorrectly, it can affect the quality of the entire product.
Choosing a Hardware Solution
Hardware can impact the quality, user experience, and stability of the entire system. There are many factors to consider when choosing the right hardware, including:
- Does the device support all use cases of the project?
- What is the price-performance ratio?
- How easy is it to establish a setup of devices for development and distribution to users?
- Does the device have all the right certifications, if needed, based on industry?
- Most importantly, do these all fit into the project budget?
COTS vs. DIY
Dedicated devices can be divided into two groups: off-the-shelf devices (COTS) and custom devices (DIY). COTS devices are mainly developed by original equipment manufacturers (OEMs), and they are usually available to a larger number of users. Some prominent OEMs are Samsung, Apple, LG, Mason, and others.
DIY devices are custom devices created exclusively depending on the needs and specifications of the project. They may be customized versions of modular off-the-shelf options, or something designed specifically for the purposes of the project. They may rely on an operating system like Android OS or may use only microcontrollers and low-level firmware to manage their processes. Some solutions include Raspberry Pi, Mason, and OEM/original design manufacturer (ODM) catalog devices. DIY or out-of-country options typically require evaluating the device for certifications, checking for regulatory compliance, performing your own quality assurance, etc. Also, import/export laws and the certifications required may change.
Selecting an Application Development Technology Stack
In most cases, dedicated devices use an Android operating system; therefore, the natural choice for the mobile application stack is Android's SDK. Native Android development requires a basic understanding of how the Android OS works and how the connection between software and hardware is established. When it comes to the language for developing Android applications, Java or Kotlin, among other possible languages, can be used. Java is a proven programming language with many open-source tools and libraries available that can facilitate the development process. Also, most of the Android SDK code is written in Java.
On the other hand, Kotlin is increasingly taking the lead in Android mobile application development. Almost all the latest and greatest Android apps use Kotlin or largely transfer their Java code to Kotlin. Kotlin is designed to improve the flaws and shortcomings of Java and is currently clean, lightweight, and less verbose. The Android team recommends Kotlin for the development of Android applications, and Kotlin is many times the first choice of languages.
Kotlin vs. Java Overview
The table above shows some primary offerings of Java and Kotlin. For more details, see how Kotlin compares to Java: https://kotlinlang.org/docs/comparison-to-java.html
In addition to native development, it is possible to use cross-platform technologies — the most represented include Flutter, ReactNative, Xamarin, and the increasingly popular, relatively new Kotlin multi-platform (KMM). This approach makes sense if you need to develop the application with one source code on several platforms, such as on an Android device and on a web platform (this option is offered by Flutter) to save money and development time.
The major difference between native and cross-platform development is that native is much safer, has faster performance, and is very responsive, which leads to a generally enhanced user experience. The disadvantages are that it can run only on one platform, the cost of software development is higher, and it requires more developer resources.
In contrast, cross-platform development is far cheaper, the code can be used on more platforms, and in most cases, it requires fewer developer resources. The disadvantages are mainly related to limited device feature support and performance delays. Additionally, features that are not supported in the cross-platform must be developed in the native platform, and this requires the mandatory presence of a native mobile developer on each team.
Customizing the Device UX
The appearance of the application plays a decisive role in what kind of experience the user will have. Often, the user interface (UI) influences whether the user will like the product or not, as well as whether they will continue to use it. Due to these factors, it is crucial that the device offers maximum flexibility and freedom regarding its design. With custom OS development, it is possible to change the entire UI system to meet the project requirements.
A concrete example of this is Android Automotive within the Android Open Source Project (AOSP), where a separate UI system was created (Android Automotive System UI) using components and core applications for OEMs, users, and developers. You can explore this example further here: https://source.android.com/devices/automotive
Some OEMs make it easy to configure the base OS of their device through a YML configuration file, starting from the boot-up animation to turning hardware components on and off (such as a camera). This flexibility simplifies the customization process and allows developers who may not have deep system knowledge to easily change the OS.
In addition to this approach, there are EMM/MDM options available, primarily offered by large manufacturers. These providers have devices with predefined UI that can also be changed depending on the needs of the client via their managed services. If, for example, a client wants a specific design for the Android Launcher, modifications can be made in the config file by the provider. A simple use case is a company that provides devices to their employees with a specific login method, custom Android Launcher design, and limited number of applications. Another example is kiosk mode on top of the Android OS layer, which can generally have only one application that supports a single function, or a set of applications that are locked by the IT admin. Also, the UI can be modified inside custom read-only memory (ROMs) using rooting.
Creating a Deployment Pipeline
Deploying software is one of the most important and complex processes of the SDLC. This step includes selecting the appropriate deployment method, automating the deployment process to reduce the risk of human errors, increasing the deployment speed, and streamlining the process overall. There are several platforms on the market that cover and automate many parts of this process, such as AppCenter, AWS CodeDeploy, and CircleCI, as well as tools that can be used in conjunction with these and integrated into any deployment pipeline or workflow, enabling automation — for example, Mason with Jenkins and Kubernetes.
As shown in the image above, there is a difference between continuous delivery and continuous deployment. Continuous delivery refers to the delivery of code to the testing team, and continuous deployment refers to the deployment of code to the production environment.
Remote Debugging and Support Tools
It is completely common for minor or major errors to occur in production; in extreme situations, it is even possible for the entire system to stop. To avoid such situations, devices running Android OS often offer options for remote debugging and support tools.
A dedicated Android device is debugged via the development machine on which the DevTools instance is located. From there, the content on the Android device is screencast to the DevTools instance. It is then possible to use Team Viewer, Remote ADB tool — which allows developers to connect to the ADB shell service of an Android dedicated device over the network and execute necessary terminal commands — or a number of enterprise devices with MDM included (e.g., VMware Workspace One). This approach requires interaction on both the client and server side, but there are often devices for which it is not possible to have someone on the client side run the debugging tool.
In these situations, some manufacturers offer touchless support and debugging. Such systems themselves can recognize the error or abnormal behavior of the software, and this can be implemented as a separate feature, add-on, or a special application that controls the system.
There are different types of operations and logistics services that certain manufacturers and companies offer, including product flow control from the manufacturer to end user, product storage, production, packaging, warehousing, provisioning, certifications, shipping, and security. Depending on the level of service, there are three basic types of logistics for managing dedicated devices:
||All services in house
||An in-house logistics team is ready to prepare, provide, and ship software/hardware to end users.
|Individual third party
||Partial in-house services
||Services may include warehousing and in-house IT work but do not involve processes such as shipping software/hardware to the end user.
|Full third party
||Every process relies on third-party services
||All logistics are handled externally, including shipment directly to a fulfillment service without seeing the product.
It is especially important to note that involving a third party may introduce compliance issues as well as reduce visibility into and control over processes. These factors should be weighed if you are considering any level of managed services.