Android development: What you need to know

Continuing from a previous installment of How to Build a Mobile App: The Ultimate Guide, we’re on to the next major player of the mobile market; Android!

If you own anything other than an iPhone, it most likely runs on the Android Platform. Mainly programmed using JAVA, Kotlin, and C++, Android boasted a global market share of 88% in 2018 (a growth of over 85% since 2009), and currently holds 36% of the US market. Just like our blog on iOS development, we’ll go over the information you need to know to make pragmatic decisions about Android development, and key terms to better communicate with developers.

Disclaimer: If you’re a developer or software engineer, there might not be any new information for you here. For a look into inventive strategies to boost your ASO, check out our featured piece on The Manifest.

If you’re a business owner, CTO, or marketing director, and you’re looking to hone your Android dev knowledge, or want to brush up on your developer jargon, you’ve come to the right place.

The Android platform has seen a meteoric rise in popularity since its inception – when Google Play first came on the scene in 2008 under the name “Android Market,” the platform was facing an uphill battle against tech giants Apple and Microsoft, who in 2009 both retained about 9% more market share than Android, which entered Q1 of 2009 with a market share of 1.6%, compared to the 88% it now holds globally.

Google Play now hosts over 2.6 million apps, and in 2016, Google Play announced users had downloaded over 65 billion apps in eight years.

The tools available to developers

Written using the programming languages JAVA, Kotlin, and C++ (among others), the Android Open Source Project (AOSP) is hosted on GitHub, and provides developers with access to 99 (and counting) open source repositories. A repository is like DropBox, but for code – it gives software developers remote access to different libraries of useful functionalities (which can also be called features). In the case of GitHub, these repositories are open and free to any member of the AOSP, but most developers will use their own private repositories as well.

A functionality is – in the simplest of terms – anything the app can accomplish. Does the app provide users with a map? That’s a feature. The map is GPS enabled? That’s another feature. The app provides users with next-step-directions in the form of push notifications when running in the background? That’s another feature.

If you’d like to learn more about feature sets and proper app ideation, check out our post on the topic.

Repositories are used to speed up the programming process by providing generic code structures that can be tweaked to fit an app’s specific branding and design.

A massive upside to Android development is its ease of access to software engineers – primarily due to JAVA acting as the flagship programming language when developing Android apps.

JAVA was first thought of in 1991, after all, and saw its first public release as JAVA 1.0 in 1996. As of 2016, it has been hailed as one of the most popular programming languages in use today, with 9 million developers reporting in, and is currently on its 11th version.

Kotlin, on the other hand, made its public debut in 2017, and is currently on version 1.3, which was released in October of 2018. Very new and relatively untested, Kotlin was designed to fully integrate with JAVA, and like JAVA, is an object-oriented language (meaning important information is stored in individual classes in the code itself), and seems to be a direct rebuttal to iOS’ Swift language. For an example of a class, check out our iOS development page.

With a new language emerging like Kotlin, it’s always fun to stay up to date on what’s coming down the pipeline; luckily, the Kotlin community makes it easy to stay in the loop.

Android developers, unlike those who work with iOS, have multiple compilers to choose from. A compiler is a program that software engineers use to write programs, and developers can choose from a number of compilers in which to write their code. For example, an Android developer could use Android Studio to write their code, or Intellij IDEA, or Eclipse (and many others).

The hierarchy of Android

There are four layers to the Android OS:

1. Applications – This is where the native apps on your device, like your camera or text messenger, as well as any apps that have been download from Google Play, live in the OS. When an app is installed, it is stored in the aptly-named Application layer.
2. Android Framework – This is layer that provides the tools developers use to make apps work – service functions live here: activity manager, package manager, NFC (near field communication) services, location services, windows manager, content providers, and view the system manager.
3. Android Runtime – This is the layer that consists of the Android core libraries (the tools developers use to hook up JAVA with the Android OS), as well as the Dalvik Virtual Machine (DVM), a register-based virtual machine. For someone who speaks English, and not code, it’s basically a computer that lives in the OS itself, and ensures that the device the OS is on can run multiple instances simultaneously. Android Runtime is the foundation for the previous layer, Android Framework.
4. Platform Libraries – Containing various C/C++ and JAVA libraries, this layer provides support for Android development. This layer contains functionalities like the media player, libraries for graphics, font support, and browser support – among many others (no one wants to read a list that long).
5. Linux Kernel – This is the lizard brain of the Android OS. It manages drivers on the device, (think camera, audio, Bluetooth, memory), as well as memory management, power management, and other base-level management systems.

Those are the layers on the Android OS that provide the foundation, functions and space for your app to live and interact with. Now that we’ve got that out of the way, let’s move on to the building blocks of an Android app.

The building blocks of an Android App

There are five main components that make up an Android app:

1. Activities
2. Intents
3. Services
4. Broadcast receivers
5. Content providers

Activities

Activities are how your users interact with your app. When a developer speaks about an activity in Android, they are usually referring to the multiple points of interaction on a single screen through the app’s UI (single screens in Android are referred to as view models, and they dictate the “box” that visual information fits into). Take, for instance, a device’s native phone app – there are separate activities to dial a number, view recent and missed calls, and voicemail. All of these activities are separate from each other, and are considered distinct activities unto themselves – but they all work together as a whole to help the user achieve their goal.

Activities in Android are designed to keep track of what the user is currently doing, the processes that keep track of the features users are engaging with, and “killing” the processes that are no longer necessary for the user at the moment.

When an activity is killed, its current state is saved, in case the user comes back to that activity. This ensures that memory is both freed up for current processes, but the processes in the background remain quickly accessible to the user.

Within activities are fragments, which can be thought of as sub-activities. Fragments can be interacted with just like an activity, but they are specialized – they give your app’s UI the ability to adapt to different device screen sizes, as well as the ability to produce a more dynamic layout. If you know HTML, it’s basically the same idea as building a responsive website.

Intents

Intents function as the messengers between the components that make apps work. They are used to take the necessary information from one component of an app to the next, in order for that component to do it’s job.

If that was a little confusing (which it is, I don’t blame you), think of them as an alarm clock. An alarm clock wakes you up and tells you what the current time is – the information you need in order to start acting to get out of bed and get on with your day. Intents “wake up” app components, and let them know it’s time to get out of bed.

The most important part of intents is making sure your code uses clear naming conventions – an intent needs to match with the names of components it needs to interact with, and if the names don’t match, it won’t be able to find the component it needs to deliver the message to.

For an example of naming conventions, let’s pretend there’s a turtle. The turtle sees a coyote. An intent is sent from TURTLE_CRAWL to TURTLE_HIDE. This changes the action the turtle is taking, just as an intent will change what action the app is taking in order to properly interact with the user.

There are two types of intents: implicit and explicit. Implicit intents are used to send information from one component of one app to another component of a separate app. Explicit intents are the direct opposite – and are used to take information from one component of an app and use it to invoke another component of that same app.

Services

Services are what keep the functions of apps running in the background, and are broken down into two categories: started services and bound services. A started service, for example, is used to run some sort of function in the background, until the user stops the function; this would be used to allow a user to listen to music from one app, while engaging another app at the same time.

A bound service is kind of like one app giving another app a helping hand – these basically tell the system to not kill the function the two apps are sharing, and as soon as the function has been completed, it can be killed.

Broadcast receivers

Broadcast receivers are aptly named, and serve as the proverbial loudspeaker for a device. Probably the most well-known (and dreaded) broadcast receiver is the “low battery” notification.

When a user downloads an app onto an Android device, the OS will assign that app a unique Linux user ID (Android’s foundation is a Linux kernel), and all apps run on a virtual machine (a simulated computer that exists as its own entity on the OS), so each app runs in an isolated environment from all other apps on the device.

This is called the principle of least privilege. This means that each app can only access the functionalities and data it needs to complete a task, and nothing more. This provides an extra layer of security, as apps are unable to share data with each other, and can only access the systems they need to work.

Broadcast receivers usually function with the help of the previously-mentioned intents.

Content providers

Just as the Android OS has libraries that help it function, so to does an individual app. The libraries, named content providers, house the information of that app, so other apps can access that information in order to function properly.

Think about how when someone texts you an address, you can click on that address to open it in Google Maps. In order for your map to display the address that was texted to you, your text messenger app stores that information in a content provider, which Google Maps can then access and display.

The manifest file

After you’ve made your app, all of the components of your app (activities, intents, services, broadcast receivers, and content providers) must be stored in what’s called the manifest file. The manifest file is the folder the Android OS searches through in order to find the components that make your app run. In short, for a device to know that an app component exists, that component must be stored in the manifest file.

Think of it as the roadmap the system uses to run an app – it tells the OS where to go and what to interact with. It also identifies permissions the user has set within the device, declares the hardware features an app needs to run, and the APIs it needs to be hooked up to.

Where to go from here?

The next steps to take are beta testing and then publishing, which comes with its own costs (a one time fee of $25 for Google Play) in addition to the other costs that can be expected while developing a mobile app.

We hope you’ve found this guide to Android development helpful! Below, you’ll find a glossary of commonly used words regarding app development.

Glossary of developer jargon:

• Adaptive interface: An app that adapts to the available screen resolution. Essentially the same idea as a responsive web page.
• API: An Application Programming Interface is a set of functions, classes, and protocols that define how pieces of software interact with each other. They facilitate code creation by providing tools and building blocks that help companies connect their software with another set of software, or even other companies’ code.
• API calls: Sometimes referred to as an API request, an API call is essentially a piece of software in an app connecting to a server, and requesting a data transfer.
• Back end development: This forms the logic and data structure of the app.
• Back end integration: This allows an enterprise system to connect to an app – for example, connecting the database of a website to an app, in order for users to access the database through the app rather than the website. The information is hosted on the website’s server, but is still accessible through the app itself.
• Front end: This is the layer of the app that users interact with.
• Iterate: To perform a certain task or function repeatedly.
• On demand app: These are apps that allow users to find, connect with, and book a professional service.
• SDK: A Software Development Kit is a pre-made software tool that can be used for a variety of functions. Some SDKs help with analytics, others provide debugging and maintenance utilities, and a whole host of other functions.
• Tokens: A token is a software based security tag that produces a single-use login password or PIN.
• UI/UX: User Interface and User Experience are intrinsically tied to each other. UI is the layout and design of the front end of an app. UX is how the app flows, functions, and responds to the user’s inputs.