Note that there are some explanatory texts on larger screens.

plurals
  1. POAndroid - how to design an app that targets all platforms (1.5 and higher)
    primarykey
    data
    text
    <p>I have been developing an Android app and testing with a 1.5 AVD and the manifest setting of </p> <pre><code>&lt;uses-sdk android:minSdkVersion="3" /&gt; </code></pre> <p>My goal is to make this app available to all phones running 1.5 and greater. I had thought that as long as I develop to 1.5 then that was basically all I had to worry about and any phone running 1.5 or higher would see my app in the market and be able to install it. The following documentation however has me concerned that the app may not in fact be visible to all phones in the market unless I go through the following steps to manage various screen sizes and densities.</p> <p>My layout is very basic and I do not manage any alternate layouts for high resolution, I just let android manage the scaling. Do I need to follow these guidelines in order to have my app visible to all phones 1.5 and higher? Or is this only necessary in certain circumstances?</p> <p>From <a href="http://developer.android.com/guide/practices/screens_support.html" rel="nofollow noreferrer">http://developer.android.com/guide/practices/screens_support.html</a></p> <pre><code>Strategies for Legacy Applications If you have already developed and published an Android application based on Android 1.5 or earlier platform version, you need to consider how you will adapt your application so that it is deployable to * Existing devices, which may be running Android 1.5 (or lower) platform version, as well as to * Newer devices that are running Android 1.6 (or higher) and offering various screen sizes and resolutions To support the newer devices and the different screens they use, you might need to make some changes in your app, but at the same time your app may be very stable and so you want to minimize the changes. There are a variety of ways that you can extend your existing application to support new devices with multiple screens and existing devices running older platform versions. You should be able to make these changes to your application such that you can distribute a single .apk to any and all devices. The recommended strategy is to develop against the most recent version of the platform you are targeting, and test on the minimum one you want to run on. Here's how to do that: 1. Maintain compatibility with existing devices by leaving your application's android:minSdkVersion attribute as it is. You do not need to increment the value of the attribute to support new devices and multiple screens. 2. Extend compatibility for Android 1.6 (and higher) devices by adding a new attribute — android:targetSdkVersion — to the uses-sdk element. Set the value of the attribute to "4". This allows your application to "inherit" the platform's multiple screens support, even though it is technically using an earlier version of the API. 3. Add an empty &lt;supports-screens&gt; element as a child of &lt;manifest&gt;. If you need to enable size or density attributes later, this is where you will add them. 4. Change your application's build properties, such that it compiles against the Android 1.6 (API Level 4) library, rather than against the Android 1.5 (or earlier) library. You will not be able to compile your application against the older platform because of the new manifest attribute. 5. Set up AVDs for testing your application on Android 1.6 and higher releases. Create AVDs that use the screen sizes and densities that you want to support. When you create the AVDs, make sure to select the Android 1.6 or higher platform as the system image to run. For more information, see How to Test Your Application on Multiple Screens, below. 6. Set up AVDs for testing your application on Android 1.5 (or earlier platform). You need AVDs running the older platforms you are targeting, so that you can test for compatibility and ensure that there are no functional regressions. 7. Compile your application against the Android 1.6 library and run it on the AVDs you created. Observe the way your application looks and runs, and test all of the user interactions. 8. Debug any display or functional issues. For issues that you resolve in your application code, make certain not to use any APIs introduced in API Level 4 or later. If you are in doubt, refer to SDK reference documentation and look for the API Level specifier for the API you want to use. Using an API introduced in API Level 4 or later will mean that your application will no longer be compatible with devices running Android 1.5 or earlier. 9. For resource-related issues, you can try resolving them by: * Adding a anyDensity="false" attribute to &lt;supports-screens&gt;, to enable density-compatibility scaling. * Creating any size- or density-specific resources you need and placing them in directories tagged with the correct qualifiers. Qualifiers must be arranged in a proscribed order. See Alternative Resources for more information. * Note that if you add size- or density-specific resource directories tagged with any of the resource qualifiers listed in this document, you should make sure to also tag those directories with the v&lt;api-level&gt; qualifier (for example, -v4). This ensures that those resources will be ignored when the application is run on Android 1.5 or lower platform versions. 10. If your application does not offer support (such as custom layouts) for large screens and you want the platform to display your application in screen-compatibility mode on larger screens, add a largeScreens="false" attribute to the &lt;supports-screens&gt; element in the manifest. See Screen-Compatibility Examples for illustrations of how the platform displays your application in this case. 11. If your application does not offer support (such as custom layouts) for small screens (such as on a QVGA low-density screen) and you do not want Android Market to offer the application to users of small-screen devices, you must add a smallScreens="false" attribute to the &lt;supports-screens&gt; element. 12. Continue testing and debugging until your application performs as expected on all of the platforms and screen sizes your application will support. 13. Export, zipalign, and sign your application using the same private key you used when publishing the previous version, then publish the application to users as an update. </code></pre>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload