If you want to create DPS folios for Android devices, you should understand a few things about the platform before making design decisions. It’s important to consider the different device sizes and dimensions and how DPS folios are displayed on these devices. I would usually provide a quick summary of what you should consider, but in this particular case, I think it’s better to ask you to sit down, grab a juice box, and spend 10 minutes trying to understand the intricacies of working with DPS on Android. No shortcuts.
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 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 iOS viewers, content is scaled up to fit in the screen. For example, a 1024×768 folio is scaled up to fit in the 2048×1536 iPad HD screen. However, on Android, viewers never scale up the content. A 1024×600 folio is displayed on a 1280×800 device with big black bars on all sides. Furthermore, on iPad viewers, only folios with a 4:3 aspect ratio will appear. On Android, any folio of practically any size will appear.
In this example, a 1024×600 folio is displayed on a 1280×800 Nexus. Instead of scaling up the content, the viewer adds black bars. (Click to enlarge.)
Although viewers can scale down content on Android devices, it’s a good idea to avoid it for performance reasons.
In Android viewers, panorama overlays, and inline (non-fullscreen) videos are not supported. (Starting with v26, articles with PDF image format are supported.) Also, 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. For a detailed list, see Differences between iOS and Android viewers.
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. On Android, only large tablet devices are supported. Android phones are not supported. DPS viewers do not appear in the Google Play Store of Android phones and small tablets.
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
DPS viewers support Android 2.3.3 API level 10 or higher. Although DPS 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.
It would greatly simplify matters if we could remove the system bars from Android devices or add a “safe zone” to the source files, but as my English Lit teacher would say, “Alas, ’tis not to be.”
Popular Android Device Sizes
As of October 2012, manufacturers appear to have settled on three model sizes for Android devices: 1024×600, 1280×800, and 1920×1200. In addition, manufacturers are creating HD 10″ devices which have double the resolution of SD 10″ devices (2460×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.
Folio Rendition Sizes
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? I wish I had an easy answer to that question. Unfortunately, the answer depends on several variables, including the design of your content, the amount of time you’re willing to spend on creating renditions, and which folios you’ve already created for iOS. So let’s discuss a few different workflow scenarios.
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.
That’s why we recommend creating special renditions that account for the system bar in the following scenarios.
Scenario 1: Lazy Susan
You created a 1024×768 folio for the iPad, and now you want to make that same folio available for Android devices. Will this approach work? Sure, it works if you avoid features that aren’t supported on Android (panoramas, inline videos, certain HTML content), and if your interactivity is basic enough to handle the extra processing that occurs when the viewer scales down the folio. You’re basically slapping 4:3 content onto 16:10 / 16:9 devices, so you’ll get the black bars from letterboxing (top and bottom) or pillarboxing (left and right), or both. This is an option, but the folios look amateurish in most cases. If you take this route, you can now use any image format—including PDF—for your one-size fits all folio.
What if you created both 1024×768 and 2048×1536 iPad renditions? An odd thing can happen with the HD 10″ devices such as the Nexus 10. Because of the system bar in landscape view, the 2048×1536 folio needs to be scaled, so the 1024×768 rendition is used instead, and it looks ridiculously small in the middle of the black screen. One workaround is to create additional renditions that still have a 4:3 aspect ratio. For example, you can create a 1600×1200 folio and import your 1024×768 source documents.
Scenario 2: The Whole Hog
With this scenario, you’re going to do everything you can to maximize screen space and avoid making the viewer scale down the folio content. With unlimited time and resources, you would create the following folio renditions for Android devices:
- 1024×600 – This rendition works on the Galaxy Tab 7″ and Amazon Fire SD.
- 1205×725 – This dual-orientation rendition works well on the 1280×800 7″ HD devices with the 75/64-pixel system bar. For a single-orientation rendition, use either 1280×736 for landscape (64-pixel system bar) or 1205×800 for portrait (75-pixel system bar). If you’re wondering whether you can use both 1280×734 and 1205×800 articles in a folio, you can’t. The aspect ratios of folios and articles need to match.
- 1232×752 – This dual-orientation rendition works well on the 1280×800 10″ SD devices with the 48-pixel system bar. For a single-orientation rendition, use either 1280×752 for landscape or 1232×800 for portrait.
- 1280×800 – This rendition works well for the Kindle Fire 7″ HD.
- 1920×1200 – This rendition will work well for the Kindle Fire 8.9″ HD. You can use the same source files you use for the 1280×800 folio. Both 1280×800 and 1920×1200 devices have the same aspect ratio (8:5).
- 1820×1100 (?) – I’m not sure about this one, so I’m leaving room for a 100-pixel system bar for the 1920×1200 devices. I’m not even sure whether DPS viewer apps will work on these devices. I’ll come back and edit this once I have more information.
If you’re combining your Android renditions with iOS renditions for entitlement reasons, you could end up with as many as ten renditions for each folio. Ugh.
Here’s a table in progress:
|1024×600||Amazon Fire SD, Galaxy Tab 7″||1024×600||1024×600||1024×600|
|1280×800 (Android SD 10″)||Xoom, Galaxy Tab 10″||1232×752||1232×800||1280×752|
|1280×800 (Android HD 7″)||Nexus 7″||1205×725||1205×800||1280×734|
|1280×800 (Amazon HD 7″)||Kindle Fire 7″ HD||1280×800||1280×800||1280×800|
|1920×1200 (Amazon HD 8.9″)||Kindle Fire 8.9″ HD||1920×1200||1920×1200||1920×1200|
|2560×1600 (Android HD 10″)||Asus Transformer Pad Infinity, Acer Iconia Tab||?x?||?x?||?x?|
Scenario 3: Sensible Shortcuts
First, I recommend that you stick to a single-orientation design for Android viewers. 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—at least not until we have access to liquid HTML articles. While I prefer landscape orientation for larger devices such as the iPad, I think portrait orientation works better for one-handed devices such as the iPhone and Kindle Fire. If possible, pick a single orientation that works for your design and stick with it.
Second, take advantage of single-sourcing files. If you structure your folders properly, it’s easy to import the same set of files into multiple folios. The key thing to remember is that the aspect ratio of the source files must match the aspect ratio of the target folio. Some publishers take an existing set of source files and create multiple renditions based on that one set of files. While the content doesn’t end up filling the screen in all cases, you can get pretty close, and you limit the amount of redesign.
For example, let’s suppose that you already created a 960×640 portrait-only rendition for the iPhone. This 3:2 aspect ratio might translate well to Android devices. If you use those same source files to create a 1200×800 portrait-only rendition, you’ll be in good shape for the 1280×800 devices. You might want to copy and edit the source files to change font sizes and tweak the layout, but you have a good starting point. You would also want to create a separate 1024×600 folio rendition. With InDesign CS6, new features such as Alternate Layouts help simplify the layout conversion.
Here’s another example. Let’s suppose that you start with 1024×600 source files. Rather than creating new source files for the larger renditions, just stick to one set of source files, and import them into a larger folio that has the same aspect ratio. For example, you could create an 1152×675 folio and import the 1024×600 articles. You would end up with both letterboxing and pillarboxing on tablets such as the Nexus 7 and Xoom, but the appearance—while not ideal—might be passable. Here’s an 1152×675 folio displayed on a Nexus:
The 1152×675 folio displayed on a 1280×800 device includes letterboxing and pillarboxing, but no scaling.
Another approach focuses on the Amazon Fire devices as the primary target and the Android devices with the system bar as secondary targets. In this workflow, you would create source files for 1024×600 and 1280×800, and use the same source files for both 1280×800 and 1920×1200 folios, which both have an 8:5 aspect ratio. The folios you create from these source files should look great on the Kindle Fire. To avoid scaling on Android devices, you would then use the same source files to create a folio rendition that matches the aspect ratio without causing scaling. For example, the 1280×800 source files you created could be imported into an 1160×725* folio. This rendition might be passable on the Android models that have system bars.
* If my Math teacher asked me to show the math, 1280×800 factors down to an 8:5 aspect ratio. Multiplying both 8 and 5 by 145 gives us 1160 and 725. By the way, if you wanted to use the same 1280×800 source files for the 1024×600 devices, multiply both 8 and 5 by 120 = 960×600. That would leave 32-pixel black bars on two sides.
With the v22 release, the DPS App Builder included a new option called “Strict rendition for 7″ Android devices.” This option is useful if you’re using the same Application Adobe ID (Title ID) for your iOS and Android apps, and you want only 1024×600 or 1280×800 folios to appear on 7″ Android devices. Selecting this option prevents folios designed specifically for the iPhone or iPad—especially folios with PDF articles or elaborate web content—from appearing on Kindle devices.
While we’re on the subject of using the same Title ID for both iOS and Android apps, I suggest that you do it only if you’re an Enterprise customer and you’ve set up a custom entitlement server. That way, you can make sure that customers who purchased a subscription on an iPad are entitled to your content from Android devices as well.
In my experience, I’ve found it’s better to use separate Title IDs for iOS apps and Android apps. With DPS Tips, I got tired of having to create dummy Android folios for content that worked only on the iPad. With my newest version, I fixed that problem by re-creating Android-only folios using a different Title ID. If you download the newest version, you’ll see there is no longer a dummy version of the “Single Edition” folio in the library.
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?
Adobe DPS does not yet support the Surface tablet. Full support for the Surface tablet is on the roadmap.
Did I miss anything? Please leave a comment.