Migrate Android* Phone Apps to Tablets


One of the problems that has occurred over the last few years of rapid mobile device proliferation is because smartphones came out before tablets, developers designed applications for smartphones first. When tablets came out with similar operating systems but different screen sizes, developers had a new market for their software; however, most did not change their approach to user interaction. The Android* OS is capable of adjusting most smartphone applications to tablet-sized screens, but usually the app doesn’t look right and doesn’t provide the experience users expect from a tablet application.

When developers build applications for tablets, they need to redesign and redeploy the application for tablets to match with visual and user experience expectations. In this article, we give advice and perspective to developers who want to migrate their Android smartphone application to Android tablet.

How to Begin

First, we need to come up with a methodology to make the migration as efficient as possible, without spending too much time and resources.

To do this, we will walk through the hardware and software differences between smartphones and tablets as well as user experience scenarios for both of the devices.

The diagram below shows the steps to follow:

Device Analysis: Tablets vs Smartphones

HW Differences

The most obvious hardware difference between smartphones and tablets is the screen size. Devices with screens larger than 7-inches are considered tablets, and smartphones have smaller screen sizes like 3.5”, 2.5”, 4.2”, etc. Tablets’ larger screen size creates different resolutions, user experience, and human-computer interaction that developers need to be aware of.

(Motorola Razr-i* Smartphone with 4.3” screen size, Asus Fonepad* with 7” screen size, and Android* tablet with 10.1” screen size, respectively.)

People tend to use tablets with their larger screen sizes for tasks that are more intensive and where they tend to spend more time within an application, like more lengthy reading, more interaction with games, and watching movies. Phones are smaller, hence more mobile to carry around and convenient for getting quick information. Smartphone applications are designed to navigate application features quickly and supply small chunks of information on smaller screens.

Device size affects how people hold the device, how many fingers they use at the same time, or in what situation they use the device, like standing, sitting, walking, etc. These differences determine the human-computer interaction.

In addition to the user experience issues, screen resolutions change between devices so developers should consider screen resolution differences and how they affect user habits when migrating smartphone applications to tablets.

Another hardware difference to account for is that most tablets do not have cellular network connection like smartphones do. So application developers should assume the absence of cellular network when designing their tablet applications.

SW Differences

The Android OS was originally designed and developed for smartphones. Then Google created v3.0, a.k.a Honeycomb*, for tablets. But since Android v4.0, a.k.a Ice Cream Sandwich*, the same OS is used on smartphones and tablets, and the releases following v4.0 have been released for both. The pictures below show a phone and tablet with the Ice Cream Sandwich home screen. They show the basic interface differences users encounter on the two devices.

(Android* Ice Cream Sandwich* 4.3” Phone and 10.1” Tablet Home Screen)

The main differences between the home screens are:

  • The notification area is above the screen on smartphones, while it is mostly in the right bottom corner on tablets (changes according to tablet screen size or the manufacturer’s UI design)
  • The Applications menu icon is at the bottom center of the smartphone screen, while it is mostly in the top right corner of the tablet.
  • The Quick navigation buttons are at the bottom of the screen on smartphones, but they are in the bottom left corner of the screen on tablets.

If your Android smartphone application was developed for Android v4.0 or later versions, the software stack is the same for tablets but if your smartphone application was developed for an earlier version, even though Android* is backward compatible, you should visit the SDK version history to see the changes, detect the deprecated methods, implement, and rebuild the code.

User Experience: Human-Computer Interaction with Tablets

As it has been mentioned in the hardware differences section, people use phones and tablets differently. People usually carry smartphones around with them, so they tend to use them for communication (calls, messaging, tweeting, etc.) and for short reading instead of concentrated actions like reading books, articles, etc., writing long emails, and other entertainment or productivity applications. It is common to show short information on the small phone screen. But when you move your app to tablets, you can show more information on the screen, and users tend to dwell longer while looking at the screen instead of a quick scan of information.

It is also more common to use tablets instead of smartphones for production tasks, including writing longer notes, photo and video editing, creating presentations, writing long emails, etc. These uses mean that people tend to use tablets in more static situations instead of mobile conditions since tablets are larger, have larger screens to enjoy and larger soft keyboard to make typing easier, and so on.

Tablets are designed to be rotated more than phones as both landscape and portrait mode are large enough on a tablet to legibly show text and graphics in either mode. Designing the application user interface on a tablet to optimize for both landscape and portrait states of the screen is important as the application can present an enhanced user experience when compared with a smartphone. One suggestion is to give more data space to an application window so users can more easily enter text or follow the state of the application.

Design Decisions

After analyzing the hardware, software, and user interaction differences between tablets and smartphones, it is easier to see what the design decisions are for tablet applications. Here’s a list of the most common actions that need to be considered:

  • Redesigning the user interface to account for how people use the application on a tablet.
  • Adding more visuals and text on the screen.
  • Recreating of some visual content for the user interface due to differences in screen resolution. To fill the larger screen, the OS would have to stretch some visual resources, distorting them. It’s likely going to be better to replace an image that would be stretched with a higher definition one.

Android UI Development

In most cases Android adjusts your application layout to fit the current device screen. In some cases it works fine, but in other cases the UI might not look as good and might need some adjustments. Even if you designed a dynamic UI, scaling images and widgets might not be so user friendly. Since the XML files were designed for smartphones, you need to create new XML files and design for tablet-sized devices.

Here we have some quick tips for designing the user interface for tablets.

  • Use new high-res image resources instead of low-res ones to improve the quality of user interface. Otherwise, your app images will be pixellated and your application will look bad. Rescaling the low-res images;

  • Letting the OS stretch the user interface widgets could look worse than you think. Try to centralize the user interface elements. Below is a sample user interface for a phone app that was stretched to fit on a tablet.;

    (TextField Widget on phone being adjusted to show on a tablet)

  • Using absolute layouts is hard to manage since you need to specify exact locations of the user interface elements, making it hard for your application to accommodate different screen sizes and adjust for landscape and portrait modes. It is advised to use linear or relative layouts.

Developing the new User Interface

The Android SDK allows developers to create multiple UIs with XML files for different sizes of screens. The system handles most of the work to render your application properly on each screen configuration by scaling layouts to fit the screen size and density with scaling bitmap drawables for the screen density as appropriate.

In the Android project you can use these folders to ensure your app uses appropriate screen design.

res/layout/my_layout.xml “regular screen size”

res/layout-large/my_layout.xml “larger screen size”

Or declare the specific resolution screen with:

res/layout-sw600dp/main_activity.xml For 7” tablets (600dp wide and bigger)

res/layout-sw720dp/main_activity.xml For 10” tablets (720dp wide and bigger)

(Android Project Folder Structure shows resource folders for different resolutions)

Using Fragments

The Android SDK provides fragments for creating more dynamic user interfaces. Using fragments, developers can include more functionality on a tablet application screen, giving users more benefits. Developers can create sub-activities for different parts of the screen by defining a fragment for each sub-activity in an Android activity class.

(Fragments Visualization on devices)

Fragments have their own lifecycle similar to an activity with stack, state, and back-stack.

When an activity creates a fragment, it is attached to the activity, so the developer can define what the attached fragment does.

public void onAttach(Activity activity){  	

Multiple fragments can be attached and detached to an activity so developers can add more functionality to one screen by managing the fragments. Fragment APIs provide the FragmentManager class to manage fragment objects within an activity.

Using Fragments, you don’t have to start a new activity and switch to a brand new window. The user can stay on the same screen and continue to interact with the same UI. Using the same screen fragments can mean that your app runs faster also.

(Fragments Lifecycle)

Fragments also have subclasses like DialogFragment, ListFragment, PreferenceFragment that are similar to activity correspondence, e.g., ListActivity. By using the appropriate subclass, you can design more dynamic applications.

The Android SDK comes with sample fragment applications for both phones and tablets. The screenshots below are from a sample that uses list fragments to dynamically change the reading pane without changing the window and starting a new activity.

(ListFragment on tablet)

(ListFragment on Phone)

Android Tablet Application Deployment

When declaring the support for multiple screens for your application, you need to edit your application’s AndroidManifest.xml file and add the <supported-screen> tag. The tag supports `android:requiresSmallestWithDp, android:compatibleWidthLimitDp, androidLargestWidthLimitDp`. Your manifest file will then look something like this:

<manifest ... >
  <supports-screens 	android:requiresSmallestWidthDp="600" />



Migrating your application from smartphone to tablet is suggested to present best user experience to users and take more attention than an adjusted smartphone application on tablet. As mentioned in the article Android* SDK is helpful to make your work easier during migration and redesign of your application if you decide the new tablet design of your application.

Other Related Articles

  1. “User Experience Design Guidelines for Tablets running Android*” article helps you to build a User Interface that looks great and accomplishes your goals.

  2. “Designing for User Experience, Power, and Performance on Tablets” article helps you by giving issues to consider when working out your User Interface and overall user experience.

  3. “Intel for Android* Developers Learning Series #4: Android Tablet Sensors” article provides you a sensor based application development on Android tablets, it is a good read to review application development process on Android tablets.

  4. “Mobile OS Architecture Trends” article gives an overview of mobile OS design and architecture such as user experience, power management, security design, cloud support and openness design.


About Author

Onur is working as Software Engineer for Intel® Corporation more than 3 years. He has worked on Android* and Linux* systems with various Intel platforms and technologies. He is currently working in Intel Labs Istanbul as Software Development Engineer.

Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.

Copyright © 2014 Intel Corporation. All rights reserved.

*Other names and brands may be claimed as the property of others.

For more complete information about compiler optimizations, see our Optimization Notice.