Google makes another effort for limiting Bloatware

The guidelines concerning the Android OEMs were revised in August in another effort by Google to reduce the number of pre-installed apps on Android devices. The tech giant is once again taking steps for limiting the bloatware on Android marshmallow. With the launch of Android, Google has given the permission to its OEMs to modify the operating system as per their requirements but with certain conditions if they require accessing Google Play Store. But since the past few years the company has been focusing on tying these loose ends. Manufacturers are allowed to tweak the Android version below Lollipop. However, all this is going to change with the Android 6.0 Marshmallow. Apps for this flavor of Android will require requesting for the permissions before protected features can be accessed. This has been mentioned through the Compatibility Definition Document. Also it has been mandatory that every app should use a dialogue box for seeking permissions.

From now on the OEMs won’t be able to grant any run time permissions to the apps that come pre-installed i.e., the bloatware. All these permissions can be set through the Settings app so that the user can view and set them later. Various smartphone manufacturers including LG, Samsung and Xiaomi ship their phones with a number of pre-installed apps. This gets bad as the user is not allowed to delete the bloatware. While the manufacturers can still have pre-installed apps on the devices, at the end users get to decide what an app does. With the release of Android Marshmallow, Google has taken a number of steps to the address many concerns of the users. Also the full disk encryption will be enabled by default and from now on all smartphones running Android 6.0 will have to include the ‘Doze mode’.

Below is a portion of the document.
9.1 Permissions:
Permissions with a protection level of dangerous are runtime permissions. Applications with targetSdkVersion > 22 request them at runtime. Device implementations:

MUST show a dedicated interface for the user to decide whether to grant the requested runtime permissions and also provide an interface for the user to manage runtime permissions.
MUST have one and only one implementation of both user interfaces.
MUST NOT grant any runtime permissions to pre-installed apps unless: the user’s consent can be obtained before the application uses it or the runtime permissions are associated with an intent pattern for which the pre-installed application is set as the default handler.

Image Source: cyberscylla.com