Tech-Forward - Achieving Business Readiness For Copilot in Microsoft 365
Optimizing your Android App for Mass Market Devices
1. The Motorola Developer Network
Optimizing Your Android AppOptimizing Your Android App
For Mass Market DevicesFor Mass Market Devices
Lori Fraleigh
Director, Developer Platforms,
Tools & Technical Services
Motorola Mobility
2. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Sample Device Differences
DROID XTM
Platform: Android 2.1
Input: Touch, h/w buttons
Display: 4.3” 480 X 854
(FWVGA)
Orientation: Portrait
Navigation: touch display
Notifications: Tri-color
LED, vibration,
status bar, sound
FLIPOUTTM
Platform: Android 2.1
Input: Qwerty keyboard,
touch, h/w buttons
Display: 2.8” 320X240
(QVGA)
Orientation: Landscape
Navigation: touch display,
5-way rocker
Notifications: Flashing
buttons, vibration,
status bar, sound
CHARMTM
Platform: Android 2.1
Input: Qwerty keyboard,
touch, h/w buttons
Display: 2.8” 320X240
(QVGA)
Orientation: Landscape
Navigation: touch display,
5-way rocker, rear
touchpad
Notifications: White LED,
vibration, status bar,
sound
DROID 2/Milestone 2TM
Platform: Android 2.2
Input: Qwerty keyboard, touch,
h/w buttons
Display: 3.7” 480 X 854
(FWVGA)
Orientation: Portrait
Navigation: touch display, 5-
way rocker
Notifications: Tri-color LED,
vibration, status bar,
sound
3. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Differentiating Areas
• Platform Version
– SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1, SDK 2.1, SDK 2.2
• Display
– QVGA vs HVGA vs WVGA
• Orientation
– Landscape or Portrait
• Camera
– Flash and Focus
4. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Device Dashboard
This data is based on the number of
Android devices that have accessed
Android Market within a 14 day period
ending on 9/1/2010.
Android
Platform
Percent
of Devices
Android 1.5 (3) 12.0%
Android 1.6 (4) 17.5%
Android 2.1 (5,6,7) 41.7%
Android 2.2 (8) 28.7%
5. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
API Level
<uses-sdk android:minSdkVersion=“<API Level>”
android:targetSdkVersion=“<API Level>”/>
minSdkVersion
• Required; defaults to 1 indicating your app is compatible
with all versions of Android. Use caution!
• Set to the lowest possible number of the platform you want
to deploy your application on
• Used by adb when app is installed to verify device is
running at same API level or higher (for example sideways
install)
• Also used by Android Market to filter what applications are
available on devices
6. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
API Level (con’t)
<uses-sdk android:minSdkVersion=“<API Level>”
android:targetSdkVersion=“<API Level>”/>
targetSdkVersion
• Optional; set to API level that application has been
tested against
• Enables or disables compatibility mode
– targetSdkVersion = 3
• Want app to look the same on all devices and display at 160
• However, defaults for other manifest values will preclude app
from QVGA devices
– targetSdkVersion > 3
• Want app to run at resolution of device; avail on all screens
sizes
7. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Differentiating Areas
• Platform Version
– SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1, SDK 2.1, SDK 2.2
• Display
– QVGA vs HVGA vs WVGA
• Orientation
– Landscape or Portrait
• Camera
– Flash and Focus
8. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Display
• QVGA vs HVGA vs WVGA/FWVGA?
• Size doesn’t matter (well sort of doesn’t matter)
• Density does matter
– Device Independent Pixels (dip or dp /density independent)
– Physical pixels
– Logical Density : Scale factor between DIP and PIX
• Density determines what the application looks like
across devices
• You can determine what density your app runs at
through a few mechanisms
9. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Range of Densities
Logical
Density
Dpi (Resolution) Screen Size Android Devices
0.75 120 Small (QVGA)
Motorola:
-- FLIPOUT
-- CHARM
1.0 160
Normal
(HVGA)
Motorola:
-- CLIQ/DEXT
-- Motorola i1
-- BACKFLIP
1.5 240
Large
(WVGA)
Motorola:
-- DROID/Milestone
-- DROID X
10. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Coding for Different Displays
• Enabling or disabling compatibility mode through your
AndroidManifest file
• Using density-independent pixel values in your
application and pre-scaling your background
• Including XML resources!
• Creating multiple resource files at different densities
and screen sizes
• drawable-ldpi, drawable-mdpi, drawable-hdpi
11. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Filtering on Display Sizes
• Can limit the application from installing on devices with
different screen sizes
<supports_screens
android:smallScreens=“true|false“ // qvga
android:normalScreens=“true|false“ // hvga
android:largeScreens=“true|false“ // wvga
android:anyDensity=“true|false" /> // dpi
• Market will block application from displaying on device
where screensize = false
12. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Differentiating Areas
• Platform Version
– SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1, SDK 2.1, SDK 2.2
• Display
– QVGA vs HVGA vs WVGA
• Orientation
– Landscape or Portrait
• Camera
– Flash and Focus
13. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Orientation
• Two devices in our portfolio, CHARM and FLIPOUT,
have a default orientation of landscape
• Most keyboard enabled devices rotate to landscape
when keyboard is opened
• To account for different configurations, every application
should:
− Create layouts that handle rotation
− Set the rotation behavior in your AndroidManifest file
− Handle rotation in your application code by saving state or
caching data
14. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Orientation (con’t)
• Create layouts that handle rotation ….
15. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Orientation (con’t)
• Let your activity auto-rotate
<activity android:name=".MainActivity”
android:label="@string/app_name”
android:screenOrientation="unspecified" >
• When an activity display rotates, the activity is destroyed
and re-created. To avoid delay’s in reloading data…..
− cache data before the screen rotates using
onRetainNonConfigurationInstance()
− restore it from onCreate() after rotation using
getLastNonConfigurationInstance()
16. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Sensor-Based Orientation
• Additional tips for games that use the accelerometer or
other motion-based sensors
• Android Developer Blog
• One Screen Turn Deserves Another http://android-
developers.blogspot.com/2010/09/one-screen-turn-deserves-
another.html
• MOTODEV Technical Library
• Handle Sensor-Based Screen Orientation
http://developer.motorola.com/docstools/library/FLIPOUT_Pr
ogramming_Tips/
17. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Differentiating Areas
• Platform Version
– SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1, SDK 2.1, SDK 2.2
• Display
– QVGA vs HVGA vs WVGA
• Orientation
• Landscape or Portrait
• Camera
– Flash or Focus
18. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Camera
• Many mass market devices will not have the same type
of camera as a high-end smartphone
• If your app manifest declares the CAMERA permission
<uses-permission android:name=“CAMERA” />
• You should also specify
<uses-feature
android:name=“android.hardware.camera” />
• If you do not specify any uses-feature elements for
camera, your app is assumed to use both autofocus and
flash
19. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Camera (con’t)
• If your app does require either flash and/or autofocus
capabilities, make sure you declare them
<uses-feature
android:name=“android.hardware.camera.autofocus
” />
<uses-feature
android:name=“android.hardware.camera.flash” />
20. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Differentiating Areas
• Platform Version
– SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1, SDK 2.1, SDK 2.2
• Display
– QVGA vs HVGA vs WVGA
• Orientation
– Landscape or Portrait
• Camera
– Flash and Focus
21. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
Device Configuration: How to tell?
• Programmatically getting device configurations
− android.content.res.Configuration
− android.util.DisplayMetrics
− android.os.Build etc…….
• Technical Specifications page for every Motorola device
− developer.motorola.com/products
− As of today there are specs on 26 Android devices
− Tracks between 50 – 60 configuration options that developers
would be interested in
22. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.DEVELOPDESIGN DISCOVER DISTRIBUTE
For More Information
23. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
THANK YOU
24. Copyright 2010 Motorola Mobility, Inc. All rights reserved unless otherwise noted.
License
• Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file
except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0.
• Unless required by applicable law or agreed to in writing, software distributed under the
License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied. See the License for the specific language
governing permissions and limitations under the License.
• Portions of this presentation are modifications based on work created and shared by
Google and used according to terms described in the Creative Commons 3.0 Attribution
License.
Editor's Notes
Software Differences
Platform Versions
Densities and Compatibility Mode
Hardware Differences
Device Configurations
So lets get started. Here I’ve listed 4 different devices and the some of the features that vary across different Android handsets.
1. Platform Version
SDK 1.1, SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1
2. Display
QVGA vs HVGA vs WVGA
3. Orientation
- Portrait or Landscape
4. Camera
Flash and Focus
Let’s start with Platforms. What does the landscape look like?
Google now collects data on it’s platform numbers and publishes that data on a “Device Dashboard”.
This data itself is collected from number of apps downloaded from the Android Market to each different OS version.
May or may not be an accurate data point for your region but it does show that there are multiple releases of Android available in the consumer space.
As more phones are released in your region you will start to see the same type of distribution.
When each platform version is released, new features are added that will not be available on previous versions.
Be aware of this.
So lets look at the how you set the API Level. It’s specified in the &lt;uses-sdk&gt; element of the application manifest file. There are three properties associated with this tag.
minSdkVersion=1 but application uses APIs at level higher may or may not work across phones. The app will install. The app will not run on platforms that don’t support newer APIs used in your application. The app will crash. Not good from a consumer standpoint to be allowed to install an application that will not work.
This is where compatibility mode comes into play.
Compatibility mode came along when Android began supporting high resolution screens (same time that 1.6 came out).
If you set the targetSdkVersion to 3 or lower it means you want your application to look the same on all devices and display at a resolution of 160. It’s “compatibile” on all phones.
If you set the targetSdkVersion to higher than 3 (4, 5, 6, 7) it means you want to run your app at the same density that’s on the phone. It could be 160, or 240.
In order to set this, the build target must match or be greater than the targetSdkVersion.
Size of the screen doesn’t matter, it’s the density that matters. The density affects the scaling of your application.
There are 3 components which are the building blocks for building graphical components.
Because the first Android devices were running at a 160 resolution, Google has defined 160 as a “normal” or baseline value from which all other densities are compared.
160 * .75 = 120
160 * 1.5 = 240
Applications created against SDKs at API levels 1, 2, and 3 only run at a density of 160 no matter what device they run on. The property you need to set for the other densities does not exist in these SDKs. This property was introduced in SDK 1.6.
Applications created against SDKs at API level 4 and above have the option of running at a density of 160 _OR_ the native density of the device.
Apps running at a density of 160 on all devices are said to be running in compatibility mode. This is independent of the device you are running on.
Applications running at the density of the device are not running in compatibility mode.
There are three ways to code for the different densities……..
Compatibility Mode On (runs at density of 1.0/160 dpi)
Your application looks/runs the same on different resolutions
Tells platform to automatically scale
Compatible on all resolutions
Issues with new tablets
Compatibility Mode Off (runs at density of device)
Your application looks/runs differently on different resolutions
Tells platform that you want to control the display and scaling
It is optimized for higher resolution; looks okay on lower resolution devices
&lt;supports_screens&gt; tag does not exist in SDK 1.5 or earlier but the framework uses default values for these settings with apps that are built against SDK 1.5 or lower. If you are compiling your application against a build target of 1.6 or higher, then you need to explicitly set these values.
anyDensity == true disables auto-scaling by framework and relies on application to use dp or scaled values
anyDensity == false tells framework to try and scale application to fit display – works ok on high res screens, not as well on low res screens.
In your res/layout/main.xml and res/layout-land/main.xml file specify where the UI elements should go relative to each other and to the dimensions
For instance, in layout/main.xml you can get away with LinearLayout where the buttons place from top to bottom. However in layout-land/mail.xml it may be better to use RelativeLayout and position the buttons in relationship to each other.
In onRetainNonConfigurationInstance() implementation, initialize variables or arrays with data that you want to preserve for your future-self.
Then in your onCreate() method call getLastNonConfigurationInstalnce(). If not null you can pull the data from the preinitialized variables or arrays.
In onRetainNonConfigurationInstance() implementation, initialize variables or arrays with data that you want to preserve for your future-self.
Then in your onCreate() method call getLastNonConfigurationInstalnce(). If not null you can pull the data from the preinitialized variables or arrays.
Specs categories:
General data (platform version, navigation type)
Display-specific data (resolution, physical screen)
Connectivity (voice bands, bluetooth profiles)
Multimedia data (supported media formats)
Processor and Memory data (chipset, RAM and ROM values)
Sensor data (Types supported)
Additional information (supports flash or LBS)
Coming soon: Graphics (openGL extensions)
