What is Android Go?

what is android go

Android Go, also known as Android Oreo (Go edition), is a stripped-down version of Android designed to run on entry-level smartphones. It’s comprised of three optimized areas — the operating system, Google Play Store, and Google apps  which have been reimagined to provide a better experience on lesser hardware.

Operating system

The operating system is based on Android Oreo, but it’s optimized to run on smartphones with 512 MB to 1 GB of RAM. It takes up roughly half the space of Android Nougat, giving smartphones with low storage the breathing room to hold more media and apps out of the box  most Android Go smartphones come with 8 or 16 GB of storage.

Devices running Android Go are said to open apps 15 percent faster than previous Android software, although this is also the case with the regular version of Oreo. Additionally, Google has enabled the “data saver” feature for Android Go users by default to help them consume less mobile data.

what is android goGoogle


Like the OS, Google has also developed apps to make better use of the device’s memory. These require up to 50 percent less space and perform better on low-end hardware. Android Go smartphones come with only nine pre-installed apps, listed below:

Keep in mind that these apps may be slimmer and faster, but they might be missing a feature or two. For example, you can’t set reminders or control smart home devices with Assistant Go, but you can do most other standard things like set alarms, open apps, and ask various questions.

It’s worth noting that we can expect to see many other Android Go optimized apps in the near future. Developers can already start producing apps for the OS with the help of Google’s Building for Billions development guidelines.

what is android go

Play Store

Building a new OS and pre-installed apps package is a great start for Android Go, but what about when people begin using the device in the real world? To help users maintain their lightweight system they set out with, Android Go devices have access to an exclusive version of the Play Store.

The Android Go Play Store offers all of the same content as the regular Play Store, only the storefront is more suited to low-storage devices. It has a featured apps section that recommends apps specifically for Android Go handsets, pointing users in the direction of apps that will be of most benefit to them.

what is android go

What’s the point of Android Go?

Demand for smartphones in emerging markets like India is on the rise. Google expects its next billion users to come from these countries, where the purchasing power is lower than in the West. That’s why the company wants to provide them with a new generation of affordable, sub-$100 smartphones that work faster, provide more storage, and help reduce data consumption.

It sounds like a brilliant plan on paper, as it could allow Google to increase the number of users of its apps and services. However, software is only one part of the equation. The company has to get as many hardware partners as possible on board that will flood the market with smartphones, which will not only have to be affordable but also easy on the eyes. Let’s face it, no one wants an ugly smartphone.

A few options are already available on the market, which we’ll take a look at next. But before we do, check out our short “Android Go: A promising start” video below to learn even more about Google’s Go initiative.

Smartphones running Android Go

We saw the first batch of Android Go devices at MWC 2018 in February. Six smartphones were announced, with arguably the most interesting one being the Alcatel 1X. What makes it stand out from the rest is that in addition to an affordable price tag it also comes with an 18:9 display — something we’re more used to seeing on high-end and some mid-range smartphones.

The Alcatel 1X comes in two variants and starts at €100 for a single-SIM and €110 for a dual-SIM version. You can get it with either 1 or 2 GB of RAM, both of which feature a 5.3-inch display with a resolution of 960 x 480 pixels, a 5 MP selfie snapper, and a 2,460 mAh battery — see our hands-on video to learn more.

what is android go

Alcatel 1X

The next Android Go smartphone that grabbed our attention was the Nokia 1. HMD Global is pitching it as a “transition” device for those moving from feature phones to their first smartphone. It sports a 4.5-inch display, a low-level quad-core MediaTek processor, and 1 GB of RAM.

The device has a polycarbonate back, which users can swap out for various different color options. You’ll be able to get it in Europe, the Middle East, Africa, India, Asia Pacific, Australia, and Latin America this April for just $85.

what is android go

Nokia 1

Other Android Go devices announced at MWC include the Micromax Bharat Go and Lava Z50, both of which are targeted at Indian consumers. Then there’s also the GM 8 Go and the ZTE Tempo Go, which goes for $85 in the U.S.

Some of these devices are already on sale, while others are yet to be released. Generally speaking, there are minor differences between them when it comes to specs, with one of the biggest ones being screen size.

Six smartphones is a start, but the number will have to increase significantly for Android Go to become successful. We’ll likely see a few more soon, as Huawei and Transsion have already announced they are on board with the program. Let’s hope more companies will follow shortly.

What are your thoughts on Android Go? Do you think Google’s plan to make entry-level smartphones more appealing will be successful? Let us know by posting a comment down below.

Using Android Architecture Components: Lifecycles and SQLite made easy

Before Google I/O 2017, Google avoided recommending any particular architecture for Android development. You could use Model View Presenter (MVP), Model View Controller (MVC), Model-View-ViewModel (MVVM), some other pattern, or even no pattern at all.

With the release of the Android Architecture Components project, we finally have an official recommendation for Android Application Architecture, and all the components we need to implement it.

The Android Architecture Components project spans a number of libraries, but since Room and Lifecycles recently saw their first stable release, I’ll focus on how to set up and use both of these production-ready libraries.

By the end of this tutorial, you should know how to avoid memory leaks and application crashes by creating components that are capable of managing their own lifecycles, and how to store data locally in SQLite using much less boilerplate code.

>> An SQLite primer for Android app developers

Creating lifecycle-aware components

Most Android components have a lifecycle associated with them. You used to be responsible for managing your application’s lifecycle, which wasn’t always easy, especially if your application featured multiple asynchronous calls happening simultaneously.

Failing to manage application lifecycles correctly can result in all kinds of issues, ranging from memory leaks, to your application losing the user’s progress, and even outright application crashes.

Even if you managed the lifecycle correctly, implementing all of that lifecycle-dependent code in your lifecycle methods (such as onStart and onStop) could make them bloated and complex. This makes methods difficult to read, maintain, and test.

The Lifecycles library offers a new approach to lifecycle management, by providing all the classes and interfaces needed to create lifecycle-aware components that adjust their behavior automatically, and even perform different actions in response to lifecycle events.

As of Support Library 26.1.0, Fragments and Activities have a Lifecycle object attached to them, which lets them broadcast their lifecycle state to other components within your application. For example, if an Activity features video content, then you can use this new lifecycle awareness to detect and pause the video automatically whenever the Activity loses focus, and restart it as soon as your application regains the foreground.

Since this process is automated, Lifecycles helps you avoid many problems caused by lifecycle mismanagement. Since you’re not cramming all of that lifecycle-dependent code into your lifecycle methods, your code is going to be much more organized, so it’ll be easier to read, maintain, and test.

To use the Lifecycles library, you need to add the following to your module-level build.gradle file:

dependencies {
   implementation "android.arch.lifecycle:runtime:1.0.3"
   annotationProcessor "android.arch.lifecycle:compiler:1.0.0"

If you want to use Java 8.0 with the Lifecycles library, then you’ll also need to add the following:

implementation "android.arch.lifecycle:common-java8:1.0.0"

The Lifecycles library introduces the following components:

  • Lifecycle – An abstract class that has an Android Lifecycle attached to it. Objects can observe this state and act accordingly.
  • LifecycleOwner – An interface that’s implemented by objects with a Lifecycle. Fragments and Activities already implement the LifecycleOwner interface (in Support Library 26.1.0+), and are therefore LifecycleOwners by default. You can observe LifecycleOwners— and any class that extends a LifecycleOwner— using a LifecycleObsever.
  • LifecycleObserver – LifecycleObserver receives updates about LifecycleOwner events. Prior to the Lifecycles library, you could only react to methods that were triggered by lifecycle events, like onCreate and onDestroy, but now you can create methods that are triggered by changes in a LifecycleOwner’s state. You can make a method lifecycle-aware by adding the @OnLifecycleEvent annotation.
  • Observer – An Observer receives an update whenever their assigned LifecycleOwner enters a new lifecycle state. An Observer that’s assigned to an Activity will be notified when this Activity enters a paused state, and again when it enters a resumed state. You add an Observer to a lifecycle, using lifecycle.addObserver(this).

The @OnLifecycleEvent annotation can react to the following lifecycle events:

  • ON_STOP .
  • ON_ANY.

ON_ANY is triggered by any lifecycle event. If you use Lifecycle.Event.ON_ANY, then the method should expect a LifecycleOwner and Lifecycle.Event argument.

Let’s look at how you’d create a LifecycleObserver that responds to changes in an Activity’s state. In the following code, we’re printing a message to Android Studio’s Logcat whenever the associated LifecycleOwner (MainActivity) enters a started or stopped state:

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.arch.lifecycle.Lifecycle;
import android.arch.lifecycle.LifecycleObserver;
import android.util.Log;
import android.arch.lifecycle.OnLifecycleEvent;

public class MainActivity extends AppCompatActivity {
   private static final String TAG = "MainActivity";
   protected void onCreate(Bundle savedInstanceState) {

//Associate the LifecycleOwner with the LifecycleObserver, using getLifecycle().addObserver//

       getLifecycle().addObserver(new Observer());

//Create an Observer that implements the LifecycleObserver interface//

   public class Observer implements LifecycleObserver {

//Use @OnLifecycleEvent to listen for different lifecycle events//

       public void onStart() {
           Log.e(TAG, "ON_START");

       public void onStop() {
           Log.e(TAG, "ON_STOP");

You can also handle multiple lifecycle events within the same method:

@OnLifecycleEvent({ON_STOP, ON_START})

If your project already has methods that handle lifecycle events, you can add the @OnLifecycleEvent annotation to these existing methods, rather than re-writing your current implementation.

Performing operations based on the Lifecycle state

You’ll usually only want to perform an operation when a Lifecycle is in a certain state.

For example, if you attempt to perform a FragmentTransaction after an Activity state has been saved, then the FragmentManager is going to throw an exception. By using getState.isAtLeast, you can ensure this operation only happens when the Lifecycle is in a compatible state:

public void startFragmentTransaction() {
     if (lifecycle.getState.isAtLeast(STARTED)) {
//Perform the transaction//

The isAtLeast method can check for the following Lifecycle states:


You can also retrieve the current lifecycle state by calling getCurrentState().

LiveData: Keep track of changing data

The Lifecycles library also provides the foundation for additional Android Architecture Components, including LiveData, which you can use alongside the Room data persistence library.

LiveData is an observable wrapper that can hold any data, including Lists. Once a LiveData has a value, it’ll notify its assigned Observers whenever that value changes.

However, unlike a regular Observable, LiveData is lifecycle-aware, so it only updates Observers that are in an “active” state (i.e STARTED or RESUMED). If the LifecycleOwner reaches a Lifecycle.State.DESTROYED state, then the LiveData will remove the Observer automatically. This lifecycle-awareness helps you avoid the crashes and errors that can occur if you try to update a stopped Activity or Fragment.

Whenever a component enters the STARTED state, it automatically receives the most recent value from the LiveData object it’s observing. If an Activity or Fragment is resumed, or recreated as part of a configuration change, then it’ll receive the latest data.

To use the LiveData component in your project, you’ll need to add the following to your module-level build.gradle file:

implementation "android.arch.lifecycle:extensions:1.0.0"

Easier data storage with Room

If your app handles a significant amount of structured data, you can often improve the user experience by caching some of this data locally. If you persist all of your app’s most important data then users will be able to continue using your application, even when they don’t have an internet connection.

While Android has supported the SQLite data persistence solution since version 1.0, the built-in APIs are fairly low-level and implementing them requires a significant amount of time, effort, and boilerplate code. There’s also no compile-time verification of raw SQL queries, and if the data changes then you’ll need to manually update your SQL queries to reflect these changes, which can be time-consuming and error-prone.

Room is an SQLite mapping library which aims to lower the barrier to using SQLite on Android. Room abstracts some of the underlying implementation details of creating and managing an SQLite database and lets you query data without having to use Cursors or Loaders. Room also provides compile-time validation of queries and entities, and forces you to perform database operations on a background thread, so you don’t inadvertently wind up blocking Android’s all-important main UI thread.

To use Room, add the following to your project’s module-level build.gradle file:

compile "android.arch.persistence.room:runtime:1.0.0-alpha1"
annotationProcessor "android.arch.persistence.room:compiler:1.0.0-alpha1"

In Room, operations such as Insert, Update and Delete are annotated, which is why we need to add the annotation processor as a project dependency.

There are three major Room components:

1. Database

The @Database class provides the bridge between your application and SQLite.

Your @Database class must be an abstract class that extends RoomDatabase, which defines tables present in your database, provides Data Access Objects (DAO) classes, and includes a list of entities associated with the database.

//List the entities contained in your database. Separate multiple entities with a comma//

@Database(entities = {List.class}, version = 1)

//Define an abstract class that extends RoomDatabase//

public abstract class MyDatabase extends RoomDatabase {

//Declare your DAO(s) as abstract methods//

   public abstract ItemDao itemDao();

You can acquire an instance of Database by calling Room.databaseBuilder() or Room.inMemoryDatabaseBuilder().

2. Entity

Room creates a table for each class that you annotate with @Entity, where each field corresponds to a column in the table. Entity classes are usually small model classes that don’t contain any logic.

Room can only persist fields it has access to, so you either need to make a field public, or provide getter and setter methods. Each entity also needs to define at least one field as a primary key. Even if there’s only a single field, you’ll still need to annotate that field with @PrimaryKey.


//Unless we specify otherwise, the table name will be List//

public class List {


//The column name will be id//

    private int id;

private String item;

  public String getItem() {
       return item;

   public void setItem(String item) {
       this.item = item;

Room uses the class name as the database table name, unless you override it using the tableName property:

@Entity(tableName = "list")

Room also derives the column name from the field name, unless you explicitly define the column name using the @ColumnInfo(name = “column_name”) annotation, for example:

@ColumnInfo(name = "productName")

Room creates a column for each field that’s defined in the entity. If there’s a field you don’t want to persist, then you’ll need to annotate it with @Ignore.

public class List {

    Bitmap image;

Even though most object-relational mapping libraries let you map relationships from a database to the respective object model, Room doesn’t allow object references. The reasoning behind this restriction is that this type of lazy loading typically occurs on Android’s main UI thread, which can result in unresponsive user interfaces and application crashes. Instead, you’ll need to explicitly request the data your app requires.

3. DAO

You access your data via Data Access Objects (DAO), which can either be an interface or an abstract class, but must contain all the methods you want to use in your database queries.

These annotated methods generate the corresponding SQL at compile time, reducing the amount of boilerplate you need to write and maintain.

There’s several convenience queries you can use with DAOs, including:

  • @Insert. When you annotate a DAO method with @Insert, Room generates an implementation inserting all entries into the database in a single transaction.
  • @Update. Modifies entities in the database.
  • @Delete. Removes entities from the database.
  • @Query. This is the main annotation you’ll use in your DAO classes and it’s how you’ll perform all your read/write operations.

The following DAO interface contains various operations that we can perform on our table:

public interface ItemDao {

//We don’t need to write all that Cursor related code; instead, define queries using annotation//

@Query("SELECT * FROM List")
   List<List> fetchAllData();

   void update(List list);

   void delete(List list);

Each @Query method is checked against the table schemas at compile time. If there’s a problem with a query, you’ll get a compilation error rather than a runtime failure.

When performing queries, you’ll often want your application to update automatically when the data changes. You can achieve this by using Room in combination with LiveData – specifically, by using a return value of type LiveData in your query method. Room will then generate all the code necessary to update the LiveData when the database is updated.

@Query("SELECT * FROM List")
LiveData<List<List>> fetchAllData();

Room and RxJava

If you’re using the RxJava library in your project,  you can create Room queries that return a backpressure-aware Flowable. Flowable is a new addition to RxJava 2.0 that helps you avoid the issue of a source Observable emitting items too quickly for the downstream Observer to process. This can result in a backlog of unconsumed, memory-hogging items.

To use RxJava with Room, you’ll need to add the following dependency to your module-level build.gradle file:

implementation "android.arch.persistence.room:rxjava2:1.0.0"

If you’re interested in learning more about using RxJava 2.0 in combination with the Room library, then Google has published a Room and RxJava Sample app.

Wrapping up

Even though Room is Google’s recommended approach for working with databases, Android still supports direct database access using SQLite, so you don’t need to switch to Room.

Are you happy with Android’s default SQLite implementation? Will you be migrating to Room? Let us know in the comments!

Android Pay is now live in Canada

Another country is officially joining the shortlist of places that support Google’s Android Pay program. After the official announcement during Google I/O 2017, support for Android Pay in Canada is finally rolling out starting today. This confirms earlier rumors that stated Google would unveil Android Pay support on this exact day.

If you are an Android user in Canada, you can now download and install the application from the Play Store. At launch, BMO, CIBC, Banque Nationale, Scotiabank, Desjardins, President’s Choice Financial, ATB Financial, and Canadian Tire Financial Services will work with Android Pay on devices running Android KitKat 4.4 or higher. Google stated support for American Express cards and Tangerine will be coming soon. Similar to Apple Pay, the wireless wallet app uses the tokenized system to create a secure transaction for payments when an Android phone is tapped against an NFC-supported terminal. It’s a fast, reliable, and most importantly secure method of payment.

Android Pay was launched in September 2015 in the United States. Since then, Google rolled out the program to 10 other regions including New Zealand, U.K., Australia, Japan, Poland, and Hong Kong. In the next few months, we should see the program expanding to other areas such as Russia, Spain, Brazil, and Taiwan.

If you live in Canada and have an account with one of the listed banks, you can try Android Pay already by downloading the app from the Play Store link below. Please note that your device needs to be pass SafetyNet checks to make it work. If your device is rooted or has an unlocked bootloader, that means you’ll need to have Magisk and Magisk Hide enabled. Instructions for how to install these two modifications can be found here.

Get Android Pay from the Play Store Via: Reddit