We have talked about the vision that drives Android Things. Let's now look at the design considerations as a platform that are reflected in how it works and the options it gives to us, namely being designed without the requirement to have a display, the meaning of Activity and Home, and a different way of working with permissions and notifications.

The most significant characteristic of Android Things is that it has been designed to work without a graphical user interface. This is a very logical decision if you consider that most IoT devices do not have a screen. It is important because it dictates that all the APIs that have a strong requirement for a screen need to be redesigned or disabled/removed.

Quite often, this design decision is misunderstood as that Android Things does not support graphical user interfaces. That is not correct. You can use the same classes as you would do when building a UI on Android, the same way to create layouts and assign them to an activity. Those layouts will work fine and you can rely on them if you are building a device that has that sort of interface, but it is not a requirement for an Android Things project.

One small difference is that Android Things does not have a status bar or navigation buttons and, therefore, the application window takes all the real state of the display. This also implies that there is no way of displaying notifications on Android Things, so the Notification API is not present

Finally, even though you may not have a UI, the key component we will use to build our applications is the Activity, but, in many cases, it will not have a visual component.

Similar to Android home screen launchers, Android Things supports the concept of home, and it is defined the same way. This is the application that will run when the device boots. We will see how this is declared later in the chapter when we explore the default project of Android Things.

An IoT device will usually have a single purpose, in contrast with mobile phones that have multiple apps that can be launched. That single purpose is what the Home application does.

While developing, you can launch apps in the same way you can on Android phones, also having them declared on the Manifest. This is useful for quickly testing some ideas, especially if you are just playing around with simple apps and do not want them to become the home app, but keep in mind that you won't have the ability to launch them in any other way.

Granting permissions to apps is a good example of a feature that has been redesigned because having a display is not mandatory. In Android, permission requests are pop ups that ask the user. So how do we do this without a user interface?

Firstly, the permissions are declared in the same way as you would do for an Android app; you just add them to your Manifest.

Then, permissions are granted at install time, either with Android Studio when you are developing, or via the Android Things Console if you include the app for distribution.

You can also use adb to grant and revoke permissions

Android Things provides a console that has a similar role to the Google Play Console for mobile apps, although its functionalities are quite different.

The key functionalities that the console provides to developers are:

• Downloading and installing the latest Android Things system image
• Building factory images that contain OEM applications along with the system image
• Pushing over-the-air (OTA) updates
• Managing OEM applications
• Analytics

The Android Things Console will help us with distribution.

It is intended to be used when you move to mass production and you want to build the image to be flashed on your boards.

Given the nature of this book, the console is not something we will be exploring. We will just use it to download the script that flashes the default image on the developer kits.

Android Things relies heavily on Android libraries to offer flexibility and functionality. Given that Android Things is optimized for embedded devices that may not contain the same feature set as an Android phone or tablet, not all the APIs are present. In most cases this is coming from the restriction of not requiring a UI. There is a reference list of system APIs and Google APIs that are supported and unsupported in the Appendix.

As a rule of thumb, if it requires a system service -such as a calendar or telephone- or a strong UI component -such as AdMob or Sign-in- it is likely to not be supported, but the number of available services is remarkably large.