App Compatibility

Develop apps keeping app compatibility in mind!

Every Android device differs in 2 aspects: hardware and software.

• Hardware components such as Screen size, CPU architecture & sensor( like bluetooth, GPS etc) availability. 
• Software components such as Android version and some OEM level modifications.

Therefore your app should be flexible enough to handle these changes and should have workarounds on limitations.

Lets further divide the compatibility into 2 broad types:

App level Compatibility

• Files such as app bundles, native libraries & app resources, the static files – drawable xhdpi, xxhdpi, layout files .xml(land), dimens for resources attributes etc). These files are provided by the App and
• Android system loads these files based on device config.
• Even Play Store compares these files and device features with the required features of app(in manifest) and then delivers the optimised version of the app to the device.

Device level Compatibility

This is more of OEM specific!

• Android – For OEMs like Samsung, Vivo, Nothing, The device should have passed CTS(Compatbility Test Suite) to be Android Compatible.
• Hardware – Hardware components, native libraries, cpu architecture (x64)

Places where compatibility exits;

• App Manifest file
  • Features (camera,bluetooth etc)
  • Android version
  • Hardware support
  • App libraries
• Play Console
  • Target Device Country
  • Carrier

Where does compatibility exist in app?

App Manifest

• <uses-feature> eg. camera, bluetooth(usually bluetooth is implicitly handled when its permission is declared)
• <uses-sdk> tip: overridden by build.gradle (app level)
• <uses-permission> eg. location, microphone, bluetooth, read_external_STORAGE files, 
• <supports-screen> based on screen size
• <compatible-screen> screen size and density

Resources based on screen size

Categories of screen size: small < normal < large < xlarge

Pixel density: mdpi, hdpi, xhdpi, xxhdpi, others like no-dpi (by default)

With each successive update to the Android version, the app can support higher target sdk versions, and the android system makes backward compatibility support to run the apps. Example android sdk 19 will still run the same in latest versions as they would run back in their version.

UI resizing goes hand in hand: both android system and app developers work to handle it.

Screen size is calculated on the basis of size, split mode, multi mode, device type, orientation.

Tip: develop with flexibility in mind, don’t hard code the position of views

Develop stretchable layouts, bitmaps and 9-patch bitmaps, where some part is not stretchable

More on screen densities

Dp – density independent pixels (dip) for layout views

Sp – Scalable pixels for text, by default is dp, but changes as per user’s preferred text size

Dpi – Dots-per-inch

• Based on screen density (resources.displayMetrics()), ldpi, mdpi(160dpi), x,xx,xxx, nodpi, android scales the closest image asset.
  • 1 dp = 1 px on mdpi with 160 dpi
  • On any screen density px = dp * (dpi / 160).
• Vectors and bitmaps, vectors define paths and color, good for illustrations,
• Bitmaps and image assets for user images
• Mipmap for launchers

android:resizeableActivity to ensure well organized controls for complete app and activity.

On API levels 30 and below, if you do not want your app or activity to run in multi-window mode, set resizeableActivity=false, as of api level 30 defaults to multi mode.

maxAspectRatio if large screens don’t properly handle app resizing.

System calculates minHeight and minWidth to check if we can resize and then it will check manifest if its allowed.