While designing and building your apps, you may encounter the question: Should I create multiple versions of my apk for different devices? In most instances, the answer should be an emphatic no! Unnecessarily offering multiple copies of your apk to your customers will not only make your development process more complex and painful, it may also create confusion for your users. A well-designed app that follows the best practices guidelines will be deployable and usable on almost all Android devices.
Some common scenarios when developers think they need to create multiple apks, but really don’t, include supporting:
If you are concerned about your app being installed on an unsupported environment, follow the best practices guide for Android development to avoid such issues.
After appropriately defining settings in your Android manifest file, you will want to design your app to make the necessary runtime decisions at the lowest levels in your code. For instance, you may want to implement conditional user interface logic at the latest point possible, such as altering display and layouts based on device screen and density settings. This is an ideal way to not only lower the total lines of code you write, but it may also reduce the number of bugs in your app and reduce the size of your apk.
There are, however, a handful of situations that justify creating multiple apks. These include:
If you are offering your app for a different price to customers on a smartphone versus a tablet, then submitting a separate apk for each form factor makes sense. Furthermore, if the apk file size difference is significant and you want to avoid users of your SD version unnecessarily downloading MBs of HD images, then a separate apk may be appropriate. You should consider making this decision when your apk grows larger than 8 MBs. Under these circumstances, and others that we did not cover, you will need to submit each apk individually to the Amazon Appstore as separate apps.
In conclusion, unless your reason for creating multiple versions is well-justified, we recommend that you submit only one apk per app version.
At last week’s CES, it was hard to ignore the fact that many technology pundits are considering 2011 as the year of the tablet. And although Apple should be thanked for resurrecting interest in tablets in 2010, 2011 will see a record breaking surge in the number of vendors bringing new tablets to market. Sean Dubravac, Chief Economist and Director of Research, Consumer Electronics Association, predicted, “While many firms are touting product launches within the tablet sphere for the fourth quarter of 2010, the real action will occur a few weeks after the end of the quarter at CES.” The next few weeks will be telling for the future of the tablet and so far it’s looking quite bright.
The good news for you, the Android developer, is that many of these tablets will be sporting Android OS and, with the recent announcement of the Amazon Appstore Developer Portal, you have a convenient way of offering your apps to both tablet and smartphone users. We’re not mandating that you optimize your apps for tablets as well as smartphones, but it’s definitely something you should consider.
The expected surge in the number of tablets on the market and the number of Android devices a single user will own brings forth new opportunities and challenges. The opportunities are clear—more devices mean more users, more hardware features and more APIs to take advantage of. These new tablets will continue to feature larger screens and supported resolution levels, ample amounts of disk space and extremely fast processer speeds that are not far behind that of a typical laptop. An important thing to remember as a developer is that customers may be using your app across tablets and smartphones – no longer just one or the other.
A quick comparison of the best selling smartphones and tablets on Amazon.com shows that tablets boast 50-100% more screen real-estate and 50% more disk space. Furthermore, many of the tablets demonstrated at CES also feature dual-core CPUs. These differences make it more important than ever for developers to be aware of the device capabilities and limitations. With Amazon.com’s convenient 1-Click purchase and digital locker features, customers will be able to buy your apps and run it on any of their Android devices. Unfortunately, the growth in devices will present one of the biggest challenges for you—you want to continue to build and extend your killer apps and offer it to the tens of millions of Amazon.com customers, but you also want to keep your customers happy by setting expectations on how and where the apps can be run.
The Android SDK requires that each application contain a file called AndroidManifest.xml within the apk. This is where you can let the system know what your app needs at a minimum to run and what resources and services it will use. For instance, if you are building a word processor app that is designed to only run on a tablet, you will want to set the android:largeScreens attribute to “true” on the <supports-screens> property, while explicitly setting the small and normal screen flags to false. If you don’t declare this requirement for your app, then the Android system will assume it works on all screen sizes.
On the other hand, if you are building a game that looks great on any phone or tablet, then you can declare this in the xml file by including the following settings:
One thing to be aware of, however, is that once you declare support for all screen sizes, you will want to check the DisplayMetrics settings at runtime to make important display decisions in your code. This information can be used to make performance optimizations, such as displaying low to medium resolution images on small devices and high resolution images on large screens—a great way to avoid creating multiple versions of your app.
Apps that depend on hardware resources, such as GPS, Wi-Fi or Bluetooth capabilities, can define these requirements by appropriately setting the <uses-features> option.
Furthermore, with last month’s announcement of the Gingerbread release, there are now 6 flavors of Android OS in use. If the trend over the past two years continues, you can expect one more major release (3.0, Honeycomb) and another minor release to be announced before 2012. With major features being added in every new platform version, such as improved copy-and-paste and faster text input processing in Gingerbread, you will want to take advantage of these capabilities and also ensure your apps only run under their supported environment. The manifest provides a way to enforce dependencies on specific SDK features by using the <uses-sdk> flag.
Customer satisfaction is a key driver behind Amazon.com’s success. As you develop and offer your application to Amazon.com’s customers, following these Android development best practices guidelines is a great start towards achieving similar success.