Android – How To Manage Core App Quality In Android ?

Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Manage Core App Quality In Android ?).

In this article, we will learn about how to manage Core App Quality in Android application. Android users expect high-quality apps. App quality directly influences the long-term success of our app – in terms of installs, user rating and reviews, engagement, and user retention. This article reviews about the core aspects of quality (Core App Quality Guidelines) in our android application, through a compact set of quality criteria and associated tests. All Android apps should meet these criteria.

A famous quote about learning is :

“One learns from books and example only that certain things can be done. Actual learning requires that you do those things.”

So let’s begin.

Overview

Android users expect high-quality apps that should meet the core aspects of quality, through a compact set of quality criteria and associated tests criteria which provides in Core App Quality Guidelines.

Before publishing our apps, we need to test them against these criteria to ensure that application function works well on many devices and meets Android standards for navigation and design, and are prepared for promotional opportunities in the Google Play store.

Core App Quality Guidelines

Handle Visual Design and User Interaction

These criteria ensure that our application provides standard Android visual design and interaction patterns from core app quality guidelines where appropriate, for a consistent and intuitive user experience.

Standard Design

The application follows Android Design guidelines and uses common UI patterns and icons:

• This does not redefine the expected function of a system icon (such as the Back button).
• The application does not replace a system icon with a completely different icon if it triggers the standard UI behavior.
• If the application provides a customized version of a standard system icon, the icon strongly resembles the system icon and triggers the standard system behavior.
• The application does not redefine or misuse Android UI patterns, such that icons or behaviors could be misleading or confusing to users.

Navigation

• The application supports standard system Back button navigation and does not make use of any custom, on-screen “Back button” prompts.
• All dialogs are dismissible using the Back button.
• Pressing the Home button at any point navigates to the Home screen of the device.

Notifications

• Notifications follow Android Design guidelines. In particular:
  • Multiple notifications are stacked into a single notification object, where possible.
  • Notifications are persistent only if related to ongoing events (such as music playback or a phone call).
  • Notifications do not contain advertising or content unrelated to the core function of the app, unless the user has opted in.
• The application uses notifications only to:
  • Indicate a change in context relating to the user personally (such as an incoming message), or
  • Expose information/controls relating to an ongoing event (such as music playback or a phone call).

Manage Functionality

These criteria ensure that our application provides the expected functional behavior, with the appropriate level of permissions.

Permissions

• The application requests only the absolute minimum permissions that it needs to support core functionality.
• The application does not request permissions to access sensitive data (such as Contacts or the System Log) or services that can cost the user money (such as the Dialer or SMS), unless related to a core capability of the application.

Install Location

The application functions normally when installed on SD card (if supported by application). Supporting installation to SD card is recommended for most large apps (10MB+).

Audio

• Audio does not play when the screen is off, unless this is a core feature (for example, the app is a music player).
• It does not play behind the lock screen, unless this is a core feature.
• Audio does not play on the home screen or over another application, unless this is a core feature.
• Audio resumes when the application returns to the foreground, or indicates to the user that playback is in a paused state.

UI and Graphics

• The application supports both landscape and portrait orientations (if possible). Orientations expose largely the same features and actions and preserve functional parity. Minor changes in content or views are acceptable.
• The application uses the whole screen in both orientations and does not letterbox to account for orientation changes. Minor letterboxing to compensate for small variations in screen geometry is acceptable.
• The application correctly handles rapid transitions between display orientations without rendering problems.

User/App State

• The application should not leave any services running when the app is in the background, unless related to a core capability of the application. For example, the application should not leave services running to maintain a network connection for notifications, to maintain a Bluetooth connection, or to keep the GPS powered-on.
• The application correctly preserves and restores user or application state. The application preserves user or application state when leaving the foreground and prevents accidental data loss due to back-navigation and other state changes. This must restore the preserved state and any significant stateful transaction that was pending, such as changes to editable fields, game progress, menus, videos, and other sections of the application or game, when returning to the foreground.
  • The application returns the user to the exact state in which it was last used, when the application is resumed from the Recents application switcher.
  • When this is resumed after the device wakes from sleep (locked) state, the application returns the user to the exact state in which it was last used.
  • When the application is relaunched from Home or All Applications, the application restores the application state as closely as possible to the previous state.
  • On Back keypresses, the application gives the user the option of saving any application or user state that would otherwise be lost on back-navigation.

Manage Compatibility, Performance and Stability

These criteria ensure that applications provide the compatibility, performance, stability, and responsiveness expected by users.

Stability

The application does not crash, force close, freeze, or otherwise function abnormally on any targeted device.

Performance

• The application loads quickly or provides onscreen feedback to the user (a progress indicator or similar cue) if the application takes longer than two seconds to load.
• With StrictMode enabled, no red flashes (performance warnings from StrictMode) are visible when exercising the application, including during game play, animations and UI transitions, and any other part of the application.

Software Development Kit (SDK)

• The application runs on the latest public version of the Android platform without crashing or loss of core function.
• This targets the latest SDK by setting the targetSdk value to minimize the use of any platform-provided compatibility fallbacks.
• The application is built with the latest SDK by setting the compileSdk value.

Battery

The Android application supports power management features in Android 6.0+ (Doze and App Standby) properly. In the case where core functionality is disrupted by power management, only qualified apps may request an exemption.

Media

Music and video playback is smooth, without crackle, stutter, or other artifacts, during normal app use and load.

Visual Quality

• The application displays graphics, text, images, and other UI elements without noticeable distortion, blurring, or pixelation.
  • The application provides high-quality graphics for all targeted screen sizes and form factors.
  • No aliasing at the edges of menus, buttons, and other UI elements is visible.
• The application displays text and text blocks in an acceptable manner.
  • Composition is acceptable in all supported form factors.
  • No cut-off letters or words are visible.
  • No improper word wraps within buttons or icons are visible.
  • Sufficient spacing between text and surrounding elements.

Handle Application Security

These criteria ensure that apps handle user data and personal information safely. In addition to this checklist, applications published on the Google Play Store must also follow the User Data policies to protect users’ privacy.

Data

• All private data is stored in the application’s internal storage.
• External storage data is verified before being accessed.
• All intents and broadcasts follow secure best practices:
  • Intents are explicit if the destination application is known.
  • These intents enforce and use appropriate permissions.
  • Intents that contain data and payload are verified before use.
• No personal or sensitive user data is logged to the system or app-specific log.

App Components

• Only application components that share data with other applications, or components that should be invoked by other applications, are exported. This includes activities, services, broadcast receivers, and especially content providers. Always set the android:exported attribute explicitly, regardless of whether or not we export any of your application’s components.
• All application components that share content with other applications define (and enforce) appropriate permissions. This includes activities, services, broadcast receivers, and especially content providers.
• All content providers that share content between our applications use android:protectionLevel="signature".

Networking

• All network traffic is sent over SSL.
• Application declares a network security configuration.
• If the application uses Google Play services, the security provider is initialized at application startup.

Libraries

All libraries, SDKs, and dependencies are up to date.

WebViews

• JavaScript is disabled in all WebViews (unless required).
• WebViews only load allow listed content if possible.
• WebViews do not use addJavaScriptInterface() with untrusted content. On Android M and above, HTML message channels can be used instead.

Execution

The app does not dynamically load code from outside the app’s APK.

Cryptography

• The application uses strong, platform-provided cryptographic algorithms and does not implement custom algorithms.
• The application uses a properly secure random number generator, in particular to initialize cryptographic keys.

Google Play

These criteria ensure that our applications are ready to publish on Google Play.

Policies

• The application strictly adheres to the terms of the Google Play Developer Content Policy and does not offer inappropriate content, does not use the intellectual property or brand of others, and so on.
• The maturity level of the application is set appropriately, based on the Content Rating Guidelines.
• The application supports power management features in Android 6.0+ (Doze and App Standby) properly. In the case where core functionality is disrupted by power management, only qualified applications may request an exemption.

App Details Page

• The application’s feature graphic follows the guidelines outlined. Make sure that:
  • The application listing includes a high-quality feature graphic.
  • The feature graphic does not contain device images, screenshots, or small text that will be illegible when scaled down and displayed on the smallest screen size that our application is targeting.
  • The feature graphic does not resemble an advertisement.
• The application’s screenshots and videos do not show or reference non-Android devices.
• The application’s screenshots or videos do not represent the content and experience of our application in a misleading way.

User Support

Common user-reported bugs in the Reviews tab of the Google Play page are addressed if they are reproducible and occur on many different devices. If a bug occurs on only a few devices, we should still address it if those devices are particularly popular or new.

Setting Up A Test Environment

To assess the quality of our application, we need to set up a suitable hardware or emulator environment for testing. The ideal test environment would include a small number of actual hardware devices that represent key form factors and hardware/software combinations currently available to consumers. It’s not necessary to test on every device that’s on the market — rather, we should focus on a small number of representative devices, even using one or two devices per form factor.

If we are not able to obtain actual hardware devices for testing, we should set up emulated devices (AVDs) to represent the most common form factors and hardware/software combinations.

To go beyond basic testing, we can add more devices, more form factors, or new hardware/software combinations to our test environment. We can also increase the number or complexity of tests and quality criteria.

Test Procedures

These test procedures help us discover various types of quality issues in our app. We can combine the tests or integrate groups of tests together in our own test plans.

Core Suite

• Navigate to all parts of the application — all screens, dialogs, settings, and all user flows.
  • If the application allows for editing or content creation, game play, or media playback, make sure to enter those flows to create or modify content.
  • While exercising the application, we introduce transient changes in network connectivity, battery function, GPS availability, system load, and so on.
• From each application screen, we press the device’s Home key, then re-launch the application from the All Applications screen.
• We switch to another running application and then return to the application under test using the Recents application switcher from each application screen.
• From each application screen (and dialogs), we press the Back button.
• From each application screen, we rotate the device between landscape and portrait orientation at least three times.
• Switch to another application to send the test application into the background. Go to Settings and check whether the test application has any services running while in the background. In Android 4.0 and higher, we go to the Applications screen and find the application in the “Running” tab.
• We press the power button to put the device to sleep, then press the power button again to wake the screen.
• We set the device to lock when the power button is pressed. Press the power button to put the device to sleep, then press the power button again to wake the screen, then unlock the device.
• For devices that have slide-out keyboards, we slide the keyboard in and out at least once. For devices that have keyboard docks, we attach the device to the keyboard dock.
• We plug-in the external display for those devices that have an external display port.
• Trigger and observe in the notifications drawer all types of notifications that the application can display. Expand notifications where applicable (Android 4.1 and higher), and tap all actions offered.

Install On SD Card

Repeat Core Suite with the application installed to a device’s SD card (if supported by application). To move the application to SD card, we can use Settings > App Info > Move to SD Card.

Hardware Acceleration

Repeat Core Suite with hardware acceleration enabled. To force-enable hardware acceleration (where supported by device), add hardware-accelerated="true"to the <application> in the application manifest and recompile.

Performance and Stability

Review the Android manifest file and build configuration to ensure that the application is built against the latest available SDK (targetSdk and compileSdk).

Performance Monitoring

Repeat Core Suite with StrictMode profiling enabled. Pay close attention to garbage collection and its impact on the user experience.

Battery

Repeat Core Suite across Doze and App Standby cycles. Pay close attention to alarms, timers, notifications, syncs, and so on.

Security

• Review all data stored in external storage.
• We review how data loaded from external storage is handled and processed.
• Review all content providers defined in the Android manifest file for appropriate protectionLevel.
• All permissions review that our application requires, in the manifest file, at runtime and in the application settings (Settings > App Info) on the device.
• Review all application components defined in the Android manifest file for the appropriate export state. The export property must be set explicitly for all components.
• Review the application’s Network Security configuration, ensuring that no lint checks on the configuration fail.
• For each WebView, navigate to a page that requires JavaScript.
• For each WebView, attempt to navigate to sites and content that are outside of our control.
• Declare a Network Security Configuration that disables cleartext traffic then execute the application.
• Run the application and exercise all core functionality, while observing the device log. No private user information should be logged.

Google Play

• Sign into the Google Play Developer Console to review developer profile, app description, screenshots, feature graphic, content rating and user feedback.
• Download feature graphic and screenshots and scale them down to match the display sizes on the devices and form factors we are targeting.
• Review all graphical assets, media, text, code libraries, and other content packaged in the application or expansion file download.
• Review Support for other use cases in Doze and App Standby.

Payments

Navigate to all screens of our app and enter all in-app purchase flows.

Testing with StrictMode

For performance testing, we recommend enabling StrictMode in our app and using it to catch operations on the main thread and other threads that could affect performance, network accesses, file reads/writes, and so on.

We can set up a monitoring policy per thread using StrictMode.ThreadPolicy.Builder and enable all supported monitoring in the ThreadPolicy using detectAll().

Make sure to enable visual notification of policy violations for the ThreadPolicy using penaltyFlashScreen().

That’s all about in this article.

Conclusion

In this article, we understood about how to manage Core App Quality in Android application. This article reviewed about the core aspects of quality (Core App Quality) in our android application, through a compact set of quality criteria and associated tests.

Thanks for reading! I hope you enjoyed and learned about Core App Quality Guidelines concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolMonkTechie as below link :

• Android Articles
• CoolMonkTechie Home Page

You can also follow official website and tutorials of Android as below links :

• Android Developers

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???