Android developers have a lot of opportunities when it comes to releasing their product across multiple devices. Developing cross-platform tools is a key element in any development process to ensure that software can be ported.

Why is this important?

Android becomes a nightmare when discussed in context with store fragmentation. Items such as Google Play Services, push notification systems, and even user interface have been heavily influenced by the app store ecosystem Android has created.

One Platform Foundation is attempting to buck the trend of having to submit an app across multiple app stores independently by creating a single file that can be published from one location and automatically released to all app stores. Unfortunately, this only fixes the submission issue (and will only be viable if more app stores support the initiative) and there is still several technical issues that developers will run into along the way.

Google Play Services

This is one of the more tedious obstacles for any Android developer that is developing for a device that does not support Google Play Services. This service is used to update Google apps and apps from Google Play. Without this service, these apps among all the others are not updated in the way that Google intended. This also disallows a developer to use services such as Google Maps, Google+, Wallet Fragment among others to enhance their product.

If a user were to disable Google Play Services on their device, any app that was using these services at the time may break and cease to work. Devices manufactured by such companies as Nokia and Amazon do not have the ability to use Google Player Services, therefore they do not get all the benefits of the Google apps or native services; they must develop their own services to handle this, which of course is not going to be on par with the services that Google can handle. Samsung and HTC have signed licensing deals with Google that give control to Google over what is shipped with each device.

So what is the solution?

The main fact is that Google Play Services is not freely distributable. What this means is that it is only available to licensees, which is why we don’t find it on Nokia, BlackBerry or Amazon products (even though they use Android in some way, shape or form).

There is no simple solution to this. Companies have either had to deal with the exclusion of apps from their own stores and marketplaces or they have had to create their own proprietary services to ignore some of these issues. It would be advantageous for developers to have the ability to access a service on a device in a more broad sense. The trouble with this is that all services are developed differently so gaining access to a specific part of a service may be deemed too difficult.

Push Notification Systems

Businesses are keen on conveying current or prospective customers with all the information necessary to get them to spend time and money on their product. Apps have taken the route of pushing notifications to their users and informing them of any deals or updates that are necessary. With Android app store fragmentation, this became difficult to apply when developers used specific services that only pertained to select devices.

So what is the solution?

This issue is a little easier to solve more recently. Google Cloud Messaging allows developers to send data from servers to an Android device. This solves the problem for multiple Android devices that contain Google Play Services, but what about those that do not have these services?

Third-party plugins and libraries have made it simple for a lot of small tasks to be handled from a remote location onto multiple devices that do not have the necessary services.

OpenPush and PushWoosh are examples of SDKs that are available to developers to handle push notifications on a global scale. If there was ever a need to send one message to multiple devices using only one service, these libraries would be a quick solution.

User Interface

Devices come in all shapes and sizes. Companies can’t seem to make up their minds when it comes to how big or small they think users will want their devices. With new devices comes bigger and better resolutions. These new devices carry hardware that can only handle a specific size of texture (sprite sheets, images, icons, etc).

For example:

The LG Nexus 4 supports a maximum texture size of 4096×4096.
The Motorola Xoom supports a maximum texture size of 2048×2048.
The Samsung Galaxy Tab supports a maximum texture size of 2048×2048.
The T-Mobile G1 supports a maximum texture size of 1024×1024.

If a developer is not thinking about multiple devices, this can be an issue that causes a lot of complications.

So what is the solution?

Creating multiple sprite sheet and texture sizes has been a solution used by a lot of developers. By using preprocessing rules and restricting the output of what is displayed on a device-to-device basis, the developer is able to control the connection between screen resolution and image sizes.

Another problem arises out of this technique, which is filling an app with files that will not be used by certain devices. This makes a build larger than it needs to be depending on which devices download the software. Does the developer focus on certain devices and not others? Does the developer get the user to download assets outside of the software download itself? The latter has actually been a very popular technique used when it comes to mobile development.

Companies such as Nokia, Blackberry, and Amazon, who use Android in some capacity, have choices to make when it comes to integration issues and creating proprietary services. Amazon’s Fire Phone is a great example of a product that is going to cause more headaches for the Android ecosystem. The Fire Phone does not include Google’s standard setup of apps or it’s Google Play app store so developing for the phone will consist of connecting with separate elements than most developers are used to. Having technical issues across multiple platforms is a tough pill to swallow for developers and these companies have not made it easy but there is a reason they are doing what they do.

The good news: for every new device there will be a developer that will try their best to develop a tool to make life easier.