Skip to content

Android development: Building for billions

On April 2017, Android has become the world’s most popular operating system by overtaking Microsoft’s Windows operating system. It marks the beginning of an era in which upcoming generations are going to make their childhood memories with the Android operating system. The core reason people loved Android is its simplicity and diversity factors. The Android operating system, is cheaper for a billion users while other operating systems are found to be more costly for them.

Image for building for billions.

When an operating system is exposed to a billion of users who are totally different each other, It becomes a great pain for the developers to maintain compatibility in all aspects. There are many things we have to have taken care of while we builds an app for a wide range of users. This post will figure some of the common issues and factors which you should care about while developing an Android application.

User Interface

A user interface is a main aspect since it affects the user directly. Nowadays, designers are competing each other to produce more minimalized or materialized mobile UI. But as a developer perspective, you should be always aware that not all good designs may not produce good results in your app.

For example, If you introduce an icon of heart instead of cheers thumb icon for like action it might create different reactions on different users. Just think about how Facebook’s reactions got different reviews and user perspectives. For a successful Android app, these behavioural changes because of user interface might be a valid point to research on. Simply, think about your app’s audience and their nature.

Colours also will make the same impact on the audience. In a recent study, it shows that if your app is represented by a single color, There may be more chances that people can easily distinguish your brand name in the middle of anything.So be clever to find out a color for your app.

History of audience

I bet you that you will be always googled your holiday spot before the journey. Isn’t it? We all are searching for the history of a specific item before we go into its core. Then why not a research about history of audience before your app goes into their hands? This will make your app development more meaningful one. If you are creating an image editor app and you add some red colored filters to your app, but users love only blue colored filters, this will result huge drop of your app. So, before implementing any features think about your audience taste and their needs.

In Android, the app is a static thing. Once you have built and deployed it you cannot revert it. You have to make another one. Analytics tools like Firebase, Facebook, mixpanel etc. will give a real outcome of user’s behaviour in your app. Make use of these tools and know your audience.

App size and assets

A friend of mine, has developed an e-tutor offline app and uploaded it to the Playstore during the middle of 2013. The app sized around 40mb and users started downloading it because of the quality of content. By the end of 2016, Things have changed. There are plenty of other e-tutor apps started appearing on the market. Some of them had better content than his app and some of them had none. As a result, The user reach to his app was dropped eventually. He started encountering the problem. The reason was astonishing. Users interested to download less sized apps only. They do not care about the availability of the content, whether it is online or offline. They are ready to wait for a few seconds to fetch content from the server and use it. Countries like India, where internet is cheaper, Users are ready to stream it, but they also care about app size.

So this is the time to move your offline assets to online and implement more networking logics in your code. Try to reduce the size of the app and make it flexible for the users. If you are not ready to go for this, Just think that next generation users of the Android operating system are not coming with the experience of dial up connections and offline files. They are the active users of Youtube,Netflix, and other web based services. The floppy disc is a 3D printed model of save icon for them!

Code by knowing the user

Android ecosystem is famous for its diversity factors. Anyone can build and run the operating system in various devices. Device compatibility is a painful issue where an enterprise developer will suffer all the time. For ensuring device compatibility Android has mentioned some tricks in their well written documentation. You should always make use of it. I will not be repeating the same things. But i will be talking about some extra things that every developer should be aware of.

Check whether the feature is available

When you want to use compass in the phone, always check that the device has it. The PackageManager class will help you to address this. Specially dealing with hardwares, make sure this check is performed initially.

* Code to check device is having a particular feature
 PackageManager pm = getPackageManager();

if (!pm.hasSystemFeature(PackageManager.FEATURE_CAMERA)) {
   // Not having camera,disable it


From Android Marshmallow, run time permissions are a mandatory. It will be a good practice that users should always aware that your app is using certain permissions. Instead of showing request rationale popup directly a prior note describing about the need of particular permission will be a good thing. It will increase the trust in the user on your app.

I have seen some apps will show one more note to user to revoke already allowed permissions when the app’s job is done. Even though there is no direct feature to revoke programmatically, It will also make more trust in your app from the user. [Can be a feature request on developer forum for upcoming Android versions.]

Internet speed and caching

Caching of data are basically making things easier for the users. But it has another side effect in Android. Since Android is proposed to run on low end devices having less storage, caching of the huge amount of data will make out of memory problems to your app. Apps like ccleaner shows more memory eater apps in the base of cached data they have. Still, many of users think that apps like ccleaner are effective. So if your app takes more cached data, the chances of getting uninstalled is more.

In order to avoid this issue, there are some tricky solutions. You can implement out of the memory broadcast receiver in your app code and clear the cache at that time. So that you can easily get out of the ring.


While making any huge file downloading or uploading from your app, It will be nice to check the internet connection speed and make a toast to user that connection speed is low. This will also make your app more responsive, which will affect the user in a positive way.

* Method to get current network type

 public static String getNetworkClass(Context context) {

      ConnectivityManager cm = (ConnectivityManager)

      NetworkInfo info = cm.getActiveNetworkInfo();

      if (info == null || !info.isConnected())

       return "Not Connected network found"; //not connected

      if (info.getType() == ConnectivityManager.TYPE_WIFI)

          return "WIFI";

       if (info.getType() == ConnectivityManager.TYPE_MOBILE) {

                int networkType = info.getSubtype();

          switch (networkType) {

           case TelephonyManager.NETWORK_TYPE_GPRS:

             return "GPRS";
           case TelephonyManager.NETWORK_TYPE_EDGE:

             return "EDGE";

           case TelephonyManager.NETWORK_TYPE_CDMA:

            return "CDMA";

           case TelephonyManager.NETWORK_TYPE_1xRTT:

           case TelephonyManager.NETWORK_TYPE_IDEN: 

               return "2G_IDEN";

           case TelephonyManager.NETWORK_TYPE_UMTS:

               return "UMTS";

           case TelephonyManager.NETWORK_TYPE_EVDO_0:

           case TelephonyManager.NETWORK_TYPE_EVDO_A:

           case TelephonyManager.NETWORK_TYPE_HSDPA:

               return "HSDPA";

           case TelephonyManager.NETWORK_TYPE_HSUPA:

           case TelephonyManager.NETWORK_TYPE_HSPA:

           case TelephonyManager.NETWORK_TYPE_EVDO_B: 

           case TelephonyManager.NETWORK_TYPE_EHRPD: 

           case TelephonyManager.NETWORK_TYPE_HSPAP:  

               return "3G_HSPAP";

           case TelephonyManager.NETWORK_TYPE_LTE:   

               return "4G_LTE";

                return "Not Available";
     return "Not Available";

Don’t keep activities

This is a pretty-self explanatory title for developers. While you enable this feature from developer settings, The OS won’t keep any track of previous activity in your app. Obviously, this will result a misbehaviour of your app at the end of the day. From their developer doc it says,

Don't keep activities under the Developer Options menu.
When this option is enabled, the Android OS will destroy an activity as soon as it is stopped. 
It is intended to help developers debug their apps. For example, it can simulate the case that Android will kill an activity in the background due to memory pressure. 
In normal use, it is not recommended to turn this option on because this may lead to unexpected issues on the apps, such as freezes, force closes and reboots.

As they mention, it is not recommended to use in the normal way. But I have met many users’ devices are shipped with enabling this feature in the ROM itself. If the user starts to use your app with that condition, the app will result in crashes or a deep wounded survival.

There are some ways to solve this issue with less wounded. First, you can check whether this option is enabled by using below code snippet and requesting the user to turn it off the feature for better experience. Otherwise, you can also save your activity instance state on onSaveInstanceState(…) and restoring any previous state in onCreate(…)

* Method checks don't keep activities is enabled or not

public   static boolean isAlwaysFinishActivitiesOptionEnabled(Context context) 


int alwaysFinishActivitiesInt = 0;

if (Build.VERSION.SDK_INT >= 17) {

alwaysFinishActivitiesInt = Settings.System.getInt(context.getApplicationContext().getContentResolver(), Settings.Global.ALWAYS_FINISH_ACTIVITIES, 0);

} else {

alwaysFinishActivitiesInt = Settings.System.getInt(context.getApplicationContext().getContentResolver(), Settings.System.ALWAYS_FINISH_ACTIVITIES, 0);


if (alwaysFinishActivitiesInt == 1) {

return true;

} else {

return false;


You might be thinking about that why this feature is implemented on Android.Right? It’s just to ensure that app can be run in low memory states also. But in practice it is found that, when the device goes to low memory it won’t destroy activity, but it will destroy the entire app itself. So this feature is just a failed mock up!?

Services and background executions

Services are the essential component of an Android ecosystem. You cannot create an app without a service. Services can be executed without the app launching itself. For the next billion users, there may be a use in the huge rise of low battery power phones. Services are easily battery draining ones. If the user founds that your app is draining the battery, he may instantly uninstall your app.

Since the release of Android Oreo (Android SDK 26~27), They made a huge restriction on background services. You can read those changes here. From that post you can easily understand one thing. The user should be aware of things happening in the background of your app. He will be having all the privilege to restrict those processes. Google aims for next billions. The changes done in SDK 26 and sdk 27 are just a beginning of that. We, developers are also should capable of accepting the next billions and their choices.

Notifications and remoteviews

These are the other essential part of an Android application. These are instant reminders to your app. Sometimes these components will mark as another entry point to your app. What will happen if you put multiple notifications? This will definitely annoy the user. Make only valuable notifications. I have made another post about notifications here. You can read it here.

Handling Crashes

When an unhandled exception occurs in the app, The app might stop, its all process and will exit itself. A new feature in google play console called Android vitals is found to be effective while finding out serious crashes in a daily basis. But if you consider using crashlytics on fabric, It will give you more insights to all the crashes occurred among various users. They provide a more flexible system for crash reporting.

In an Android ecosystem while a crash leads to termination of the app, Sometimes users are found to be leaving the app forever. This can be avoided by handling uncaught exceptions by the below class and start a joyful sorry for inconvenience activity to the user which will make the user to stick with the app.

* Handle all the uncaught exception on overriden Application
* Class of your application

public class MyApplication extends Application {

          public void onCreate () {
            // Setup handler for uncaught exceptions.

            Thread.setDefaultUncaughtExceptionHandler (new 



              public void uncaughtException (Thread thread, Throwable e)


                handleUncaughtException (thread, e);




          public void handleUncaughtException (Thread thread, Throwable e)


            Intent intent = new Intent ();

            intent.setFlags (Intent.FLAG_ACTIVITY_NEW_TASK); 

            startActivity (intent);

            System.exit(1); // kill off the crashed app



There are lots of other things you have to consider while building for the next billion of users. I just listed some of the important factors. I will be talking more about this topic in upcoming posts. Thanks for reading my post.


Happy coding!

Published inAndroidFirebaseKotlin

One Comment

  1. Very soon this web page will be famous among
    all blog people, due to it’s pleasant articles

Leave a Reply

Your email address will not be published. Required fields are marked *