Fire OS 8 for Fire Tablets

Fire OS 8 incorporates updates from Android 10 (API 29) and Android 11 (API 30). Below are some of the important changes you should consider while building apps for Fire OS 8 (FOS 8).

Devices running Fire OS 8 and previous fire OS releases
Android 10 updates
Android 11 updates
Fire OS 8 parity with Android 11
Target your app for Fire OS 8 devices
Test your app's compatibility on Fire OS 8 devices
What to set for minSdkVersion and targetSdkVersion
How minSdkVersion affects supported devices
Fingerprint Authentication UI for Apps
- Authentication using your fingerprints
- Application with fingerprints and PIN
Fire tablet Auto Backup
Wake lock changes
Support

Important: API Level 30 - For Fire OS 8 (Android 11) feature compatibility, target API level 30.

Devices running Fire OS 8 and previous fire OS releases

Fire OS 8 incorporates updates from Android 10 (API 29) and Android 11 (API 30). Some older Fire Tablet devices remain on earlier versions of Fire OS.

For a detailed list of Fire Tablet devices and versions, see Tablet Device Specs.

Android 10 updates

The following is a list of important features developers should know for Android 10. For more details, see Android 10 features and APIs.

TLS 1.3 support enabled by default

Fire OS 8 adds support for TLS 1.3 and it is enabled by default for all TLS connections. We recommend updating your app to support TLS 1.3. If you need to use older TLS protocol, you can obtain an SSLContext that has TLS 1.3 disabled by calling

SSLContext.getInstance("TLSv1.2")

Invoke Settings Panel from within app

Settings Panels, an API which allows apps to show settings to users in the context of their app, have been introduced in Android 10.

FOS 8 adds Settings Panel API that allows you to surface key system settings directly in the context of your app, allowing users to access system settings like volume, internet connectivity options and WiFi controls without having to leave the app.

Settings.Panel can take following constants:

ACTION_INTERNET_CONNECTIVITY Displays settings related to internet connectivity, such as Airplane mode and WiFi.
ACTION_WIFI Displays controls for Wi-Fi settings. This is useful for apps needing a Wi-Fi connection to perform large uploads or downloads.
ACTION_VOLUME Displays settings for all volume streams.

There are a couple of sharing improvements for Fire OS 8:

Fire OS 8 introduces support for the Sharing Shortcuts API, which allow apps to publish direct share targets in advance. If your app uses Direct Share APIs to define targets, you will need to migrate to the Sharing Shortcuts API, as ChooserTargetService class has been deprecated with API 30. Incorporate the Sharing Shortcuts API using ShortcutManagerCompat class available in AndroidX library and implement ChooserTargetServiceCompat to ensure backward compatibility.
You can only publish a dynamic shortcut as a Direct Share Target. See Publish direct share targets.

Foreground service type for accessing location

If your app targets Fire OS 8 (API level 29) or higher and accesses location information in a foreground service, declare the location foreground service type as an attribute of your <service> component.

<manifest>
    ...    <service ... *android:foregroundServiceType="location"* /></manifest>

Foreground service type	Example use case for a service that should declare this type
`dataSync`	Download files from a network
`location`	Continue a user-initiated action
`mediaPlayback`	Play an audio book, podcast, or music
`mediaProjection`	Record a video of the device's display over a short period of time

You should add foregroundServiceType to your library manifest.

Access to device location in background

Apps targeting API 29 or higher do not have access to location information when in the background. To receive location information while the app is in the background, you must declare the ACCESS_BACKGROUND_LOCATION permission in your app's manifest.

<manifest ... >  

<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

</manifest>

Restrictions on starting activities from the background

Starting in Android 10, the system places restrictions on starting activities from the background. This behavior change helps minimize interruptions for the user and keeps the user more in control of what's shown on their screen. As long as your app starts activities as a direct result of user interaction, your app most likely isn't affected by these restrictions.

High Efficiency Image File (HEIF) format

Fire OS 8 tablet now has native support for HEIF image format. If your app works with static images, consider adding support for HEIF format. It provides better image quality and smaller file size, compared to the JPEG file format.

Dark theme

Android 10 adds a system-wide dark theme. You can build a custom dark theme for your app or opt-in to the new Force Dark feature that lets the system dynamically create a dark version from your existing theme.

<style name="AppTheme" parent="Theme.AppCompat.DayNight">

For more details, see Android 10 features and APIs.

Android 11 updates

APK Signature Scheme v2 now required

Apps targeting Fire OS 8 (API 30) that are currently signed with APK Signature Scheme v1 only, must now also sign APKs using APK Signature Scheme v2. Users will not be able to install or update apps on Fire OS 8 devices that are only signed with APK Signature v1. To ensure support for devices running on older Fire OS versions, you should sign your APKs using v1 and then v2 or higher.

You can check which signature version you are using on your APK with apksigner.

apksigner verify -v <apkname.apk>

One-time permissions

Starting in FOS 8 (targeting API 30), whenever your app requests a permission related to location, microphone, or camera, the user-facing permissions dialog contains an option called One-time permissions. If the user selects this option in the dialog, your app is granted temporary permissions. Follow the best practices for checking and requesting permissions at runtime to ensure you have necessary permissions.

Package visibility

Apps targeting FOS 8 (API level 30) will see a filtered list of installed apps by default. In order to access a broader list of installed apps, your app can specify information about apps they need to query and interact with directly. This can be done by adding a <queries> element in the Android manifest.

<manifest package="com.yourapp.name">
  …

  <queries>

// If you know package names of app you need to interact with

    <package android:name="com.anotherapp.firstapp" />
    <package android:name="com.someapp.secondapp" />


// If you want to query for all apps with specific intents

    <intent>
      <action android:name="android.intent.action.SEND" />
      <data android:mimeType="image/jpeg" />
    </intent>

  </queries>
  …
</manifest>

Foreground services for accessing camera and microphone

If your app targets API level 30 or higher, and accesses the camera or microphone in a foreground service, declare the camera or microphone foreground service types respectively, as attributes of your <service> component.

<manifest>
    ...
    <service ...
        android:foregroundServiceType="camera|microphone" />
</manifest>

Compressed resource files

Apps that target Android 11 (API level 30) or higher can't be installed if they contain a compressed resources.arsc file or if this file is not aligned on a 4-byte boundary. Check your zipalign logs to ensure resources.arsc file is not compressed if you get an error.

Failure [-124: Failed parse during installPackageLI: Targeting R+ (version 30 and above) requires the resources.arsc of installed APKs to be stored uncompressed and aligned on a 4-byte boundary]

Dynamic Intent Filters

To receive intents, apps must now declare which data types can be received through an intent filter in the app’s manifest. These are called MIME groups, a manifest element introduced in Android 11. To use a MIME group, include a data element in your app manifest with the android:mimeGroup attribute.

Custom toasts from background are blocked

Toasts containing custom views sent from the background are now blocked. However, text toasts are still allowed when using Toast.makeText() , rather than the deprecated setView().

Fire OS 8 parity with Android 11

All features implemented in Fire OS 8 are at feature parity with Android 11, which doesn't necessarily mean that everything in Android 11 is available in Fire OS 8. Some Android 11 features aren't yet supported in all Fire OS 8 devices.

Also, remember that although Fire OS 8 has parity with Android 11, you can't use Google services on Amazon Fire devices. Instead, you must use the Apps & Games Services SDKs for the services you need, such as in-app purchasing.

Target your app for Fire OS 8 devices

Users might run your app on a Fire OS 5, Fire OS 6, Fire OS 7, or Fire OS 8 device. To maximize your app’s compatibility with the Fire OS version on the device, we recommend you target the device based on the SDK level.

In your code, you can check whether the Build.VERSION.SDK_INT is greater than or equal to 30 (The Android 11 API level) to target Fire OS 8 devices.

Also see Supporting Different Platform Versions in the Android documentation.

Test your app's compatibility on Fire OS 8 devices

You can test your app's compatibility with Fire OS 8 by connecting to an actual device.

What to set for minSdkVersion and targetSdkVersion

Set your minSdkVersion to the minimum API level for the applicable Fire OS version.

Fire OS Version	minSdkVersion
Fire OS 5	22
Fire OS 7	28
Fire OS 8	30

Set the targetSdkVersion to the highest API level that you're targeting.

See Device Filtering and Compatibility for more information on minimum API level requirements.

How minSdkVersion affects supported devices

In your app manifest (or build.gradle file), the minSdkVersion attribute sets the minimum SDK level that your app needs in order to function properly. (Devices that don't support that API level won't allow the app to be installed on that device — this is how device filtering and compatibility works with the Appstore.)

Fire OS 5 devices are based on API level 22 (Lollipop 5.1). Fire OS 8 devices are based on API level 30 (Android 11). By setting the minSdkVersion to 22, you're saying that your app requires the device to have at least API level 22 for it to function properly.

By setting the minSdkVersion to 22, your app will also install on any devices that have a higher API level (such as 30), because Android levels are backwards-compatible. API level 30 usually includes all the APIs for levels 1 through 30 (each release adds to the previous).

However, suppose you want to take advantage of APIs in Android 11 (API level 30). If you set your minSdkVersion to 22, your app will install on Fire OS 5 devices that don't have level 30 APIs. Therefore, you must code in a defensive way to check the device level and fall back to alternatives if the device doesn't support that API level. Your code might look something like this:

if (Build.VERSION.SDK_INT >= 30) {
 Log.v(TAG, "Yes, this is an API level 30 or higher device");
} else {
 Log.v(TAG, "No, this is not an API level 30 or higher device");
}

This code checks whether the device's API level is greater than or equal to 30, and if so, runs the code. If not, it falls back on the else logic.

By default, if the targetSdkVersion is not specified, it uses the same value as the minSdkVersion. The targetSdkVersion lets you set the latest API level that you have tested your app against. Based on this value, Android will ensure proper behavior on devices at this level.

For example, if you set your targetSdkVersion to 25 or higher (Nougat’s release), Android will apply the runtime permission checking features included in Nougat. But if targetSdkVersion is lower than 25 (prior to the runtime permission checking release in Nougat), Android will not apply this behavior to your app.

Although not recommended, if you need to prevent older apps from appearing on Fire OS 8 devices, you may set maxSdkVersion to Fire OS 7 (28).

For more information, see the following:

Fingerprint Authentication UI for Apps

Authentication using your fingerprints

To authenticate using your fingerprint, set a negative button while building the biometric prompt.

BiometricPrompt.PromptInfo.Builder promptInfo = dialogMetric();
            promptInfo.setNegativeButtonText("Cancel");
            biometricPrompt.authenticate(promptInfo.build());

What you should see with the biometric login

Application with fingerprints and PIN

For fingerprint authentication with an option to enter the device PIN, remove the negative button and set setDeviceCredentialAllowed to true while building the biometric prompt.

BiometricPrompt.PromptInfo.Builder promptInfo = dialogMetric();
            promptInfo.setDeviceCredentialAllowed(true);
            biometricPrompt.authenticate(promptInfo.build());

The UI will look similar to this:

For more information, see Android Developer documentation.

Fire tablet Auto Backup

Beginning May 31, 2023, Amazon Fire tablet will enable Auto Backup for users who opt-in to a backup and restore on their tablets. Your app will automatically participate, if it targets API 23 or higher, and has not explicitly disabled Auto Backup in the manifest. Although the default value for Auto Backup is true, we recommend explicitly setting the attribute in manifest.

Auto Backup details

Writing custom backup and restore logic for the key/value backup method is no longer required, but it is still supported.
This feature is available on Fire OS 7 and higher, for apps targeting (targetSdkVersion) API 23 or higher.
Application data will be automatically backed up to AWS S3 at no charge.
All of the data files, except for app cache, is automatically backed up including databases, shared preferences, and other content in the app’s private directory unless specified otherwise.
There is a limit of 25 MB per application per device for a customer. If the limit is crossed, the app data will not be backed up, but the older backup which was within the limit will still be available to restore.
Make sure data backed up does not include sensitive data of any end user including, for example, “protected health information” as defined under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), or “PHR identifiable health information” as defined by the Federal Trade Commission’s Health Breach Notification Rule. You should also exclude password tokens or credentials in the backup for security reasons.

Note: Key/value backup and Auto Backup are mutually exclusive, so only one type of backup can be performed. If key/value backup is declared, key/value backup only will be done. If key/value backup is not declared, then Auto Backup will be performed.

For more information, see Android Auto Backup Feature Documentation.

Back up your app

With Auto Backup, your app targeting API 23 or higher and running on Fire OS 7 or higher is automatically backed up. You do not need to implement BackupAgent. Default value for Auto Backup (android:allowBackup) is true, however we recommend that you explicitly set the boolean value in the manifest as shown below:

<manifest ... >
...

	<application android:allowBackup="true" ... >
...
</application>
</manifest>

By default, all files within the application’s data directory, except the cache files, are backed up.

Back up a subset of data

Android allows app developers to customize the files they want backed up by modifying the XML file schema. You can select files to be included or excluded by using patterns in this file. Make sure data backed up does not include sensitive data of any end user including, for example, “protected health information” as defined under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), or “PHR identifiable health information” as defined by the Federal Trade Commission’s Health Breach Notification Rule. You should also exclude password tokens or credentials in the backup for security reasons. If there are any encrypted data files, such as shared preferences, they may not work when transferred to a new device. It is best to exclude these as well.

If your app needs finer control over what data is backed up, or you have a need to listen to backup events like onRestoreFinished() or onQuotaExceeded(), consider implementing Backup Agent.

Disable Auto Backup

If you choose to disable Auto Backup, you can do so by setting android:allowBackup to false in your app's manifest file. See Enable and disable backup for more information.

Transition to Auto Backup from the key/value backup

If you have previously implemented the Key/Value backup by subclassing BackupAgent and setting it in your Manifest (android:backupAgent), add the android:fullBackupOnly="true" attribute on <application/>.

You may want to rework the existing BackupAgent or remove it completely when switching over to Auto Backup. Keep in mind that switching backup options could break backwards compatibility for your app, so plan to handle such situations proactively.

Testing Auto Backup

This is a high level set of steps for how to test the Auto Backup feature on Fire tablets. For more information about AOSP’s documentation for Auto Backup testing, see Android’s backup testing guide.

Option 1: Use Amazon’s Transport

Make sure your transport is set properly.

 adb shell bmgr list transports

The result in your log should look like the following:

 * com.amazon.device.backup/.transport.BackupTransportService
 com.android.localtransport/.LocalTransport

If it is not set to Amazon’s backup transport, it be can be set through the command line.

 adb shell bmgr transport com.amazon.device.backup/.transport.BackupTransportService

Set the global setting force_auto_backup.

To support Auto Backup on your device, set the force_auto_backup flag.
```
 adb shell settings put global force_auto_backup 1
```
As a pre-requsite to running Auto Backup, run a key-value backup. This must be done first.
```
 adb shell bmgr backup @pm@ && adb shell bmgr run
```
Backup the package.
```
 adb shell bmgr backupnow <PACKAGE>
```
Example:
```
 adb shell bmgr backupnow com.example.app
```
You should see a log like the following when the full backup runs.
```
 I PFTBT   : Full data backup pass finished.
```
Note: Full backup and Auto Backup are the same thing, and the terms are used interchangeably.
Query the restore token.

The restore token is a unique ID identifying a backup run.

For example:
```
 adb shell dumpsys backup | grep "Current:"
```
Output:
```
 Current:   3
```
In this example 3 is the “restore token.”

Test the restore token.

 adb shell bmgr restore <token> <PACKAGE>

Example:

 adb shell bmgr restore 3 com.example.app

The following log should be printed if the restore completes successfully.

 I BackupManagerService: Restore complete.

You can also test deleting the data to check whether restore works. Uninstall the app and reinstalling it. Then check if the backed up data is restored.

If you’ve executed all of the steps properly, you should be able to make any changes to your app, and see the changes restored with the data you’ve previously backed up. If you run into any issues, refer to the troubleshooting steps below.

Option 2: Use a local transport

You can test data locally using AOSP’s local transport. This won’t backup any data to a server, but you can use it to test what data will be backed up and restored to your application. Android’s backup testing guide includes information for using the local transport. At a high level, the steps are the same as above. The only difference is you don’t set your transport to Amazon’s transport, but AOSP’s local transport.

adb shell bmgr transport com.android.localtransport/.LocalTransport

About backup transport

A backup transport handles the logic of uploading and downloading device backup data from a server. For Amazon, the transport handles the logic to backup data to AWS S3.

How to get a list of all transports

You can get a list of all transports with the following:

adb shell bmgr list transports

Troubleshooting

Backups are not enabled

If you see the following in the log:

Backup finished with result: Backup is not allowed
Unable to run backup

This means backups are not enabled on your device. To fix this go to Settings > Device Options > Backup & Restore. Then toggle the Backup & Restore to ON. Next attempt to re-run backups.

Transport Rejected

First, make sure your Fire tablet is on the latest version. Then, if you see the following in the log:

Package <PACKAGE NAME> with result: Transport rejected package because it wasn't able to process it at the time

This can have more than one cause, but it is most often due to throttling. Packages are only allowed to backup once per day. To set a lower throttling limit, run the following command

adb shell settings put secure overridden_backup_throttle_delay_ms <delay in milliseconds>