If you want to create DPS folios for Android devices, you should understand a few things about the platform before making design decisions.
Note: If you’re creating a Single Edition app, ignore this article. See this one instead.
(This article was written in October 2012. As the Android platform evolves, I’ll try to update this article.)
Update: New Native Android Viewer
The first public release of the native Android viewer is now available. It supports both phones and tablets that run Android 4.0.3 or later. As with the v28 legacy Android viewer, content is scaled up or down to fit within the display area of any supported device.
The program team is still working on adding support for several features supported on other platforms. For details on supported features, limitations, and how-to instructions, see Building native DPS apps for Android devices.
Update: New Scaling Up Feature in v28
With the v28 release, the Android viewers now scale up the selected rendition when the folio is smaller than the device dimensions. That’s a game changer that can dramatically simplify your approach to creating folios for the numerous different Android devices. For example, if you create a single folio, such as 1024×768 or 1280×800, the viewer will scale that folio up or down on any device on the market. The Android viewer scales up folios as long as they’re no more than three times smaller than the device’s dimensions.
If you’re using renditions, note that this new scale-up logic doesn’t affect the way renditions are picked. The viewer continues to select the smaller rendition instead of the larger rendition if the larger rendition requires scaling—even a minimal amount of scaling.
[When I get a chance, I'll change my guidance below to account for the new v28 scaling feature. I need to do some testing first...]
Differences Between Android and iOS Devices
You should be aware of a few key differences between how folios are displayed on iOS and Android.
In native Android viewers, HTML articles, several overlay types, and several other features are not supported or only partially supported. In legacy Android viewers, panorama overlays and inline (non-fullscreen) videos are not supported, along with a few other features.
With any Android viewer, be careful with HTML articles and Web Content overlays. HTML content that works great on an iPad may be sluggish or unresponsive on Android devices.
In many Android models, the system navigation bar cuts into the folio view area, causing the content to scale unless you plan ahead, as I discuss later. To make matters more complicated, the system bar has a different size on different devices and on different platforms. For example, the Motorola Xoom and the Galaxy Tab 10.1″ devices have a 48-pixel system bar, while the Google Nexus 7 has a 75-pixel system bar in portrait view and a 64-pixel system bar in landscape view. These system bar sizes can change whenever Google updates the OS.
Note that viewers on Kindle Fire models do not display system bars. Also, older Android devices that still use Froyo (OS 2.2) do not display system bars.
The folio view of a Nexus 7″ has a system bar, while the folio view of the Kindle Fire does not. (Click to enlarge.)
On iOS, all iPad and iPhone devices are supported. With the native Android viewer, any phone or device that runs Android 4.0.3 or later is supported. With the legacy Android viewer, only tablet devices are supported.
Matching Folio/Article Aspect Ratios
One key similarly between iOS and Android viewers is that the aspect ratio of the folio and its articles must be identical (unless the article is Smooth Scrolling). You cannot add 1024×768 articles to a 1024×600 folio. However, you can add 480×320 articles to a 1200×800 folio, because they both have 3:2 aspect ratios. While the viewer does not scale up content on Android viewers, the DPS tools can scale the content of source files to match the folio size. This ability to scale content allows you to take a single-source shortcut, which I’ll discuss later.
Android Operating Systems
Native Android viewers support Android 4.0.3 or later. The native viewer does not support the first generation Kindle Fire.
Legacy Android viewers support Android 2.3.3 API level 10 or higher. Although legacy viewers can currently run on Android 2.2 (Froyo), it’s no longer officially supported.. Beginning with OS 3.x (Honeycomb), the system bar is displayed at the bottom of all apps. The newest Android devices use OS 4.0 (Ice Cream Sandwich) or OS 4.1/4.2 (Jelly Bean).
Note that Kindle Fire models use a modified Android OS. The first Kindle Fire SD (1024×600) uses a modified version of Froyo. The Kindle Fire HD (1280×800 HD) and the Kindle Fire HD 8.9 (1920×1200 HD) use a modified version of Ice Cream Sandwich. What’s particularly significant about these Amazon devices is that the system bar does not affect the folio design area. A 1024×600 folio displays on the Fire SD and a 1280×800 folio displays on the Fire HD without being scaled for the system bar. When users are viewing an article, they can exit the viewer app by returning to the library and then tapping a button in the system bar.
Popular Android Device Sizes
As of October 2012, manufacturers appear to have settled on several model sizes for Android tablet devices: 1024×600, 1280×800, 1920×1200, and 2560×1600.
1024×600 devices include the Samsung Galaxy Tab 7″, Kindle Fire 7″ SD, and Acer Iconia Tab.
1280×800 devices include the Samsung Galaxy Tab 10.1, Samsung Galaxy Tab 8.9, Motorola Xoom, Nexus 7, Kindle Fire 7″ HD, and Sony Tablet S. With the 1280×800 devices, the SD sizes (e.g. Xoom) include a 48-pixel system bar in folio view, while the HD devices (e.g. Nexus 7) include system bars that are 75 pixels in portrait view and 64 pixels in landscape view. Again, the Kindle Fire models do not display the system bar in folio view.
When manufacturers want to display HD content on the newest 8.9″ devices, they appear to be using 1920×1200 dimensions. The Kindle Fire 8.9″ HD device has 1920×1200 dimensions, as do the Asus Transformer Pad Infinity and the Acer Iconia Tab devices. Unfortunately, I don’t have access to either of these devices, and I haven’t been able to locate the size of the system bar on these devices. (Please leave a comment if you have info.)
As I mentioned, 2560×1600 Android devices are starting to come out. With the v27 release, you can create large folios that target these large HD devices. With earlier releases, 2048×2048 was the maximum size.
I’m not aware of any popular Android models with a 1024×768 resolution. I heard rumors that Sony was offering a 1024×768 device, but the Sony Tablet S is 1280×800.
Now that native Android viewers support phones, I should mention popular phone sizes: 480×320, 800×480, and 960×540. Android phones come in all shapes and sizes, and we’re even seeing much larger hybrid phones that some people are calling “phablets.”
Creating folios for Android devices
With the DPS tools, you can create different folio renditions so that the viewer on a particular device displays only the folio that best matches the device dimensions. If you’re unfamiliar with renditions, please read this Folio renditions article, and then come back.
What folio sizes should we create for the Android devices, and what’s the easiest way to create them? Now that viewers scale content up or down, creating renditions is optional.
Which rendition is used?
Before we get into different scenarios, I wanted to point out a system bar-related issue that confuses publishers who create the basic renditions. Let’s suppose you create two renditions: 1024×600 and 1280×800. On the Kindle Fire devices, everything works as expected. The 1024×600 rendition shows up on the SD device and the 1280×800 rendition shows up on the HD device.
But what about Android devices such as the Xoom or Nexus 7? On those 1280×800 devices, the 1024×600 renditions are displayed, not the 1280×800 rendition. That’s because the system bar causes the 1280×800 rendition to be scaled, which reduces performance, so the viewer chooses the smaller folio that doesn’t require scaling.
First, I recommend that you stick to a single-orientation design for Android viewers. For one thing, the new native viewer doesn’t fully support dual-orientation folios—it shows only one folio. Furthermore, a lot of designers believe that it’s not worth the extra effort to create both horizontal and vertical layouts for every article of every folio. While I prefer landscape orientation for larger devices such as the iPad, I think portrait orientation works better for one-handed devices such as phones and smaller tablets. If possible, pick a single orientation that works for your design and stick with it.
Second, learn to live with letterboxing. Many publishers already have 1024×768 folios that they’ve designed for iOS, and don’t want to spend the time or effort to redo the design for a different aspect ratio. When 4:3 content is displayed on 16:9 tablets, you see letterboxing. You can minimize letterboxing by creating a folio (such as 1280×800) that’s pretty close to the display size of target devices, but you’ll still see some black edges. If you want to create a bunch of renditions that account for the different devices and the different system bars, you’ll drive yourself crazy.
Third, take advantage of the fact that folios are now scaled up and down. You can create a single folios—such as 1280×800 or 1024×768—that will work on nearly every device.
Fourth, consider creating a smaller rendition that works well for phones. I’ll have more to say about this later. The DPS team is looking into adding a mapping or threshold feature in the Web-based DPS App Builder that will help determine which folios appear on which devices.
What about the Nook?
The Nook doesn’t have the equivalent of an open App Store where publishers can submit their apps. If you’re interested in making your app available on the Nook, you need to contact Barnes & Noble directly. Adobe provided Barnes & Noble with an SDK that allows them to build custom DPS apps and fulfill folios to which customers are entitled. If Barnes & Noble is willing to work with you, create 1024×600 folios, use Folio Producer to export the .zip file, and send the .zip file to Barnes & Noble. At this time, Barnes & Noble is using the v21 SDK.
The bottom line is that if you want to publish a DPS app for the Nook, contact Barnes & Noble.
What about the Surface tablet and Windows Store?
It’s now supported. See Building DPS apps for Windows Store.
Did I miss anything? Please leave a comment.