AndroidThing is latest IOT operating system developed by Google. we can load android thing to raspberry pi/ intel Edison board and using peripherial port like I2s,PWM,GPIO, SPI. We also can remotely control it using IOT procols like MQTT.

1. P r o j e c t B r i l l o
Google is rejoining the Internet of Things platform wars. Today at
its Google I/O 2015 conference, the company announced Brillo,
the "underlying operating system for the internet of things," with a
developer preview coming in Q3 of this year. Brillo is "derived" from
Android but "polished" to just the lower levels. It supports Wi-Fi,
Bluetooth Low Energy, and other Android things.

2. IOT(Internet Of Things)
It is a network of physical devices who has network connectivity
which enables exchange of information.

3. List of IOT protocols
MQTT Message Queue Telemetry
Transport protocol
COAP Constrained Application Protocol
AMQP Advance Message Queue Protocol
Rest Representational State Transfer
XMPP Extensible Messaging and Presence
Protocol
STOMP Simple Text Oriented Messaging
Protocol
MQTT
Message Queue Telemetry Transport
protocol
COAP Constrained Application Protocol
AMQP Advance Message Queue Protocol
Rest Representational State Transfer
XMPP
Extensible Messaging and Presence
Protocol
STOMP
Simple Text Oriented Messaging
Protocol

4. Android Things
Google’s Operating system for IOT devices.
Because it's based on Android, you get access to Android APIs,
Google services, and Android developer tools.

5. Android Things Overview

6. Android Thing API
 Bluetooth API
 Device Updates API
 LoWPAN API
 NDK API
 Peripheral I/O API
 User Driver API
 Settings API

7. Peripheral I/O API
your apps communicate with sensors and actuators using industry
standard protocols and interfaces. The following interfaces are
supported: GPIO, PWM, I2C, SPI, UART.
GPIO General purpose input output
PWM Pulse width modulation
SPI Serial Peripheral Interface
I2S Inter-Integrated Circuit
UART Universal Asynchronous Receiver Transmitter

8. Core application packages
(Not Supported by Android Thing)
 CalendarContract
 ContactsContract
 DocumentsContract
 DownloadManager
 MediaStore
 Settings
 Telephony
 UserDictionary
 VoicemailContract

9. https://developer.android.com/things/sdk/index.html

10. Android thing console
https://partner.android.com/things/console/

11. Types Of Hardware
System On Module(SOM)
o NXP Pico i.MX7D
o NXP Pico i.MX6UL
o NXP Argon i.MX6UL
o Raspberry Pi 3 Model B

12. Load Android thing to Raspberry Pi board
1. Flash Raspberry Pi with Android thing
2. SD card formatter (Etcher)
3. Connect Raspberry Pi to WiFi.
4. (HDMI cable, network cable, LED Monitor)

13. Raspberry Pi – Overview
https://developer.android.com/things/hardware/raspberrypi-io.html

14. Practical

15. User-Space Drivers / Setting
https://developer.android.com/things/sdk/drivers/index.html
https://github.com/androidthings/contrib-drivers
 App developers can register new device/sensors drivers with the
Android thing.
 Any Hardware event, you can inject into the android thing using this API.
 Explore Peripheral I/O

16. MQTT
(Message Queuing Telemetry Transport)

17. • MQTT Basics
• Introducing MQTT
• Publish & Subscribe Basics
• Client, Broker and Connection Establishment
• Publish, Subscribe & Unsubscribe
• Topics & Best Practices
• MQTT Features
• Quality of Service Levels
• Persistent Session and Queuing Messages
• Retained Messages
• Last Will and Testament
• Keep Alive & Client Take-Over
• MQTT Specials
• MQTT over Websockets

18. History MQTT
 invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now
Cirrus Link) back in 1999.
 create a protocol for minimal battery loss and minimal
bandwidth connecting oil pipelines over satellite connection.
Why MQTT ?

19. Introduction to MQTT
 MQTT is a Client Server publish/subscribe messaging transport
protocol.
 It is light weight(consume minimum resources, network
bandwidth), open, simple, easy to implement.
 These characteristics make it ideal for use in Machine to
Machine (M2M) / Internet of Things (IoT).
 Open Source: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-
v3.1.1-os.html
MQTT With Goals
 Simple to implement
 Provide a Quality of Service Data Delivery
 Lightweight and Bandwidth Efficient
 Data size
 Continuous Session Awareness

20. Publish & Subscribe Basics
Pub/Sub decouples a client, who is sending a particular message
(called publisher) from another client (or more clients), who is
receiving the message (called subscriber).
This means that the publisher and subscriber don’t know about the
existence of one another. There is a third component, called broker,
which is known by both the publisher and subscriber, which filters
all incoming messages and distributes them accordingly.

21. Publish & Subscribe Basics

22. Publish & Subscribe Basics
Pub/Sub also provides a greater scalability than the traditional
client-server approach.
Message Filtering Types
 Subject-based filtering
 Content-based filtering
 Type-based filtering
MQTT uses subject-based filtering of messages.
So each message must contains a topic.

23. Client, Broker and connection
MQTT client and broker and the parameters and options available,
when connecting to a broker.
Client : A MQTT client is any device from a micro controller up to a
full fledged server, that has a MQTT library running and is
connecting to an MQTT broker over any kind of network.
MQTT client libraries are available for a huge variety of
programming languages, for example Android, Arduino, C, C++, C#,
Go, iOS, Java, JavaScript, .NET.
https://github.com/mqtt/mqtt.github.io/wiki/libraries

24. Client, Broker and connection
Broker : The broker is primarily responsible for receiving all
messages, filtering them, decide who is interested in it and then
sending the message to all subscribed clients.
Heart of any publish/subscribe protocol.
Therefore it is important, that it is highly scalable, integratable into
backend systems, easy to monitor and of course failure-resistant.
Broker manages :
 persistence session
 Filter messages
 Authorize client

25. List of broker
 Mosquitto
 Mosca
 VernMQ
 emqttd
 HiveMQ
 IBM Bluemix
 HiveMQ
https://github.com/mqtt/mqtt.github.io/wiki/public_brokers

26. MQTT Connection
The MQTT protocol is based on top of TCP/IP and both client and
broker need to have a TCP/IP stack.
The connection is initiated through a client sending a CONNECT
message to the broker. The broker response with a CONNACK and
a status code.

27. Client initiates connection with the CONNECT message

28. Broker responds with the CONNACK message

29. MQTT Publish, Subscribe & Unsubscribe
Publish:
 Each message must contain a topic, which will be used by the broker to
forward the message to interested clients.
 Each message typically has a payload which contains the actual data to
transmit in byte format

30. MQTT Publish, Subscribe & Unsubscribe
 Topic Name :
 QoS :
 Retain-Flag : This flag determines if the message will be saved
by the broker for the specified topic as last known good value.
 Payload: send images, texts in any encoding, encrypted data
 Packet Identifier : unique identifier between client and broker
to identify a message in a message flow
 DUP flag : The duplicate flag indicates, that this message is a
duplicate and is resent because the other end didn’t
acknowledge the original message

31. MQTT Publish, Subscribe & Unsubscribe
Broker will read the publish, acknowledge the publish if needed
(according to the QoS Level) and then process it.

32. MQTT Publish, Subscribe & Unsubscribe
Subscribe :

33. MQTT Publish, Subscribe & Unsubscribe
Suback: (Subscribe Acknowledgement)

34. Mqtt Features
 Quality of Service Levels
 Persistent Session and Queuing Messages
 Retained Messages
 Last Will and Testament
 Keep Alive & Client Take-Over

35. Quality of Service 0, 1 & 2
Quality of Service (QoS)
Level of agreement between sender and receiver of a message
regarding the guarantees of delivering a message.
There are 3 QoS levels in MQTT:
 At most once (0)
 At least once (1)
 Exactly once (2)
Always thinks in two part when QOS.
1. From Publisher to Broker. -: Qos sets by publisher/Sender
2. From Broker to Subscriber. :- Qos sets by receiver.

36. QoS 0 – at most once ( fire and forget )
A message won’t be acknowledged by the receiver or stored and
redelivered by the sender.

37. QoS 1 – at least once
It is guaranteed that a message will be delivered at least once to
the receiver. But the message can also be delivered more than
once.
The sender will store the message until it gets an
acknowledgement in form of a PUBACK command message from
the receiver.

38. QoS 2 – ( The highest QoS )
 It guarantees that each message is received only once by the
counterpart.
 It is the safest and also the slowest quality of service level.

39. Persistent Session and Queuing
Messages
 constrained clients with limited resources it would be a burden
to subscribe again each time they lose the connection.
 So a persistent session saves all information relevant for the
client on the broker.
 The session is identified by the client ID provided by the client
on connection establishment .

40. Persistent Session and Queuing
Messages
So what will be stored in the session?
 Existence of a session, even if there are no subscriptions
 All subscriptions
 All messages in a Quality of Service (QoS) 1 or 2 flow, which
are not confirmed by the client
 All new QoS 1 or 2 messages, which the client missed while it
was offlne.
 All received QoS 2 messages, which are not yet confirmed to
the client
That means even if the client is offline all the above will be
stored by the broker and are available right after the client
reconnects.

41. Retained Messages
(last known good value)
A retained message is a normal MQTT message with the retained
flag set to true. The broker will store the last retained message and
the corresponding QoS for that topic.
So retained messages can help newly subscribed clients to get a
status update immediately after subscribing to a topic and don’t have
to wait until a publishing clients send the next update.
last known good value, because it doesn’t have to be the last value,
but it certainly is the last message with the retained flag set to true.

42. Last Will and Testament(LWT)
MQTT is often used in scenarios were unreliable networks are very
common.
some clients will disconnect ungracefully from time to time, because
they lost the connection, the battery is empty or any other imaginable
case.
MQTT DISCONNECT message
The broker will store the message until it detects that the client has
disconnected ungracefully.
The stored LWT message will be discarded if a client disconnects
gracefully by sending a DISCONNECT message.

43. Keep Alive Time Interval and Client Take-Over
The keep alive functionality assures that the connection is still
open and both broker and client are connected to one another.
That means as long as messages are exchanged frequently and
the keep alive interval is not exceeded, there is no need to
send an extra message to ensure that the connection is still
open.
The broker must disconnect a client, which doesn’t send
PINGREQ or any other message in one and a half times of the
keep alive interval.

44. Keep Alive Time Interval and Client Take-Over
 A disconnected client will most likely try to connect again.
 It could be the case that the broker still has an half-open
connection for the same client.
 In this scenario the MQTT will perform a so-called client take-
over.
 The broker will close the previous connection to the same
client (determined by the same client identifier) and
establishes the connection with the newly connected client.
 This behavior makes sure that half-open connection won’t stand in
the way of a new connection establishment of the same client.

45. MQTT over WebSockets
It would be quite nice to send and receive MQTT messages directly in
the browser of a mobile phone or in general. This is possible by MQTT
over WebSockets.
1) Display live information from a device or sensor
2) Receive push notifications, for example if there is an alert or critical
condition
3) See the current status of devices with LWT and retained messages
4) Communicate efficiently with a mobile web application

46. MQTT over WebSockets
WebSockets are suitable as transport for MQTT because the
communication is bi-directional, ordered and lossless (which is
essentially because WebSockets also leverage TCP).

47. Now Move to production
Build Prototype > Design your PCB > Create
schematic > create layout > PCB fabrication and
assembly
Once you have a schematic and layout, you can now take this to a
vendor to start building your custom PCB. There are three general
steps in the process:
1. Design and bill of materials (BOM)
2. Fabrication or the manufacturing of the PCB
3. Assembly or the installation of all the components on the
PCB
https://developer.android.com/things/get-started/prototype.html#create_a_schematic