Developer Console
Sign In
Sign In
Developer Console

Fire OS 7 for Fire Tablets

Fire OS 7 is based on Android 9 Pie. You can ensure your app's compatibility with Fire OS 7 by following these guidelines.

Devices running Fire OS 7 and previous fire OS releases

Fire OS 7 is based on Android 9 Pie (API level 28). Fire OS 7 was initially released for some Fire Tablet devices in 2019.

Most of the Fire Tablet devices run Fire OS 5 (Android 5.1, level 22). The Fire 7 (2019) Tablet device runs Fire OS 6, which is based on Android Nougat (Android 7.1.2, level 25). Some older Fire Tablet devices remain on Fire OS 4 or earlier releases.

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

Android changes in Fire OS 7

The upgrade from Fire OS 6 to Fire OS 7 requires a transition from Nougat (Android 7.1.2) through Oreo (Android 8.0) to Pie (Android 9).

Changes introduced in Android 8.0 and Android 9 require you to make code changes in your app before the app will work correctly on Fire OS 7 devices.

Android 8.0 changes

Major changes in Android 8.0 include the following:

  • Notification Channels: All notifications (which includes recommendations and partner-managed recommendations) must be associated with a channel. For information about channels, see Android training for Notification Channels. For sample code and additional details, see the Notifications in Fire OS 7 section below.

  • Background Services: Android 8.0 limits the use of background services. As a result, any apps using background services to refresh their recommendations will fail to refresh the recommendations on FOS 7. Android recommends using JobSchedulers as a workaround for the limitation with background services. See Background Services.

  • Native Libraries: Native libraries no longer load if they contain any load segment that is both writable and executable.

  • Permissions: Apps need to explicitly request each permission, even within the same permission group.

  • MediaSession events: Your app needs to use MediaSession correctly to handle audio. See the Android 8.0 documentation on Finding a media session. When Android handles events, if the foreground activity doesn't have an active media session to handle the event, Android will look for other media sessions. See also Requirements for Multimedia Apps on Fire TV.

You can read about most of these changes in Android 8.0 Behavior Changes.

Android 9 changes

Major changes in Android 9 include only the following:

  • Privacy changes: Apps will have restricted access to wifi. Apps will have limited access to user inputs and sensor data while running in the background.

You can read about these changes in Behavior changes: all apps (Pie).

Fire OS 7 parity with Android 9

All features implemented in FOS 7 are at feature parity with Android 9. This doesn't necessarily mean that everything in Android 9 is available in FOS 7, but for those Android 9 features implemented in FOS 7, they have parity. Some Android 9 features, such as split-Screen, notification dots, and adaptive icons, aren't supported in FOS 7.

Also, remember that although Fire OS 7 has parity with Android 9, 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).

Targeting your app for Fire OS 7 devices

Users might run your app on a Fire OS 5, Fire OS 6, or Fire OS 7 device. To maximize your app compatibility with the Fire OS version on the device, we recommend that 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 28 (The Android 9 API level) to target Fire OS 7 devices.

Also see Supporting Different Platform Versions in the Android documentation.

Testing your app's compatibility on Fire OS 7 devices

Currently, you can test your app's compatibility with Fire OS 7 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 6 25
Fire OS 7 28

Set the targetSdkVersion to the highest API level that you've tested your app against.

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

Understanding 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 7 devices are based on API level 28 (Android 9). 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 28), because Android levels are backwards-compatible. API level 28 usually includes all the APIs for levels 1 through 28 (each release adds to the previous).

However, suppose you want to take advantage of APIs in Android 9 (API level 28). If you set your minSdkVersion to 22, your app will install on Fire OS 5 devices that don't have level 28 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:

targetSdkVersion

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

This code checks whether the device's API level is greater than or equal to 28, and if so, runs the code. If not, it falls back on 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 23 or higher (Marshmallow's release), Android will apply the runtime permission checking features included in Marshmallow. But if targetSdkVersion is lower than 23 (prior to the runtime permission checking release in Marshmallow), Android will not apply this behavior to your app.

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

For more information, see the following:

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.

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

  1. 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

  2. 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

  3. 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

  4. 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.

  5. 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.”

  6. 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>

Example:

adb shell settings put secure overridden_backup_throttle_delay_ms 1000

If you’ve already set the tablet to a lower throttling limit, this error may mean you don’t have data to backup. Check to see if your app has set any data to backup. To get some arbitrary backup data, run the following command:

adb shell
cd /storage/emulated/0/Android/data/<your package name>/files

Next, create a test file:

touch test.txt
echo "some test data" >> test.txt
Package not Found

If you see the following in the log:

Package <PACKAGE NAME> with result: Package not found

Check to see if your package is installed on the device.

Notifications in Fire OS 7

As of Android Level 8.0 (API level 26), notifications that your app sends must be assigned to a channel. (Recommendations are a kind of notification.) If your app sends notifications or recommendations, you must create a channel and associate the channel with the notification. A notification without a channel ID will be dropped.

At a high-level, to add a channel to a notification, you do the following:

  1. Step 1: Create the notification channel and register it with the notification manager.
  2. Step 2: Set the channel ID for the notification, using one of the following methods:

The following sections provide more detail and code samples.

Step 1: Create the notification channel and register it with the notification manager

The following is from Create a notification channel in the Android documentation:

Create a notification channel

To create a notification channel, follow these steps:

  1. Construct a NotificationChannel object with a unique channel ID, a user-visible name, and an importance level.
  2. Optionally, specify the description that the user sees in the system settings with setDescription.

  3. Register the notification channel by passing it to createNotificationChannel.

    private void createNotificationChannel() {
    // Create the NotificationChannel, but only on API 26+ because
    // the NotificationChannel class is new and not in the support library
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        CharSequence name = getString(R.string.channel_name);
        String description = getString(R.string.channel_description);
        int importance = NotificationManager.IMPORTANCE_DEFAULT;
        NotificationChannel channel = new NotificationChannel(CHANNEL_ID, name, importance);
        channel.setDescription(description);
        // Register the channel with the system; you can't change the importance
        // or other notification behaviors after this
        NotificationManager notificationManager = getSystemService(NotificationManager.class);
        notificationManager.createNotificationChannel(channel);
    }
}

Step 2: Set the channel ID for the notification

You have two options for setting the channel ID for the notification. You can either use ContentRecommendation and use reflection to set the channel ID, or you can use Notification.Builder.

Option 1: Use createContentRecommendation and use reflection to set the channel ID

Notification notification = createContentRecommendation(largeIcon, notificationId);

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    Log.d(TAG, "SDK version is >= Android O");

    try {
        Field channel = notification.getClass().getDeclaredField("mChannelId");
        channel.setAccessible(true);
        channel.set(notification, StringTerms.CHANNEL_ID);
    }
    catch (Exception e) {
        Log.d(TAG, "Can't set ChannelId", e);
    }
}

Option 2: Use Notification.Builder with channel ID

The following code is adapted from the Android Open Source Project on Google Git.

public Notification getNotificationObject(Context context) {
    Notification.Builder builder = new Notification.Builder(context, "channelId");
    RecommendationExtender recExtender = new RecommendationExtender();

    // Encode all the content recommendation data in a Notification object

    builder.setCategory(Notification.CATEGORY_RECOMMENDATION);
    builder.setContentTitle(mTitle);
    builder.setContentText(mText);
    builder.setContentInfo(mSourceName);
    builder.setLargeIcon(mContentImage);
    builder.setSmallIcon(mBadgeIconId);
    if (mBackgroundImageUri != null) {
        builder.getExtras().putString(Notification.EXTRA_BACKGROUND_IMAGE_URI, mBackgroundImageUri);
    }
    builder.setColor(mColor);
    builder.setGroup(mGroup);
    builder.setSortKey(mSortKey);
    builder.setProgress(mProgressMax, mProgressAmount, false);
    builder.setAutoCancel(mAutoDismiss);

    if (mContentIntentData != null) {
        PendingIntent contentPending;
        if (mContentIntentData.mType == INTENT_TYPE_ACTIVITY) {
            contentPending = PendingIntent.getActivity(context, mContentIntentData.mRequestCode,
            mContentIntentData.mIntent, PendingIntent.FLAG_UPDATE_CURRENT,
            mContentIntentData.mOptions);
        }
        else if (mContentIntentData.mType == INTENT_TYPE_SERVICE) {
            contentPending = PendingIntent.getService(context, mContentIntentData.mRequestCode,
            mContentIntentData.mIntent, PendingIntent.FLAG_UPDATE_CURRENT);
            }
            else { // Default:INTENT_TYPE_BROADCAST{
            contentPending = PendingIntent.getBroadcast(context,
            mContentIntentData.mRequestCode,
            mContentIntentData.mIntent, PendingIntent.FLAG_UPDATE_CURRENT);
            }
        builder.setContentIntent(contentPending);
    }

    if (mDismissIntentData != null) {
        PendingIntent dismissPending;
        if (mDismissIntentData.mType == INTENT_TYPE_ACTIVITY) {
            dismissPending = PendingIntent.getActivity(context, mDismissIntentData.mRequestCode,
            mDismissIntentData.mIntent, PendingIntent.FLAG_UPDATE_CURRENT,
            mDismissIntentData.mOptions);
        }
        else if (mDismissIntentData.mType == INTENT_TYPE_SERVICE) {
            dismissPending = PendingIntent.getService(context, mDismissIntentData.mRequestCode,
            mDismissIntentData.mIntent, PendingIntent.FLAG_UPDATE_CURRENT);
            }
            else { // Default:INTENT_TYPE_BROADCAST{
                dismissPending = PendingIntent.getBroadcast(context,
                mDismissIntentData.mRequestCode,
                mDismissIntentData.mIntent, PendingIntent.FLAG_UPDATE_CURRENT);
            }
        builder.setDeleteIntent(dismissPending);
    }

    recExtender.setContentTypes(mContentTypes);
    recExtender.setGenres(mContentGenres);
    recExtender.setPricingInformation(mPriceType, mPriceValue);
    recExtender.setStatus(mStatus);
    recExtender.setMaturityRating(mMaturityRating);
    recExtender.setRunningTime(mRunningTime);

    builder.extend(recExtender);
    Notification notif = builder.build();
    return notif;
}

For more details, consult the Android documentation on Create and Manage Notification Channels.

Amazon Device Messaging (ADM) compatibility

If your app uses Amazon Device Messaging, you need to update the SDK to avoid crashes on Fire OS 7. In previous releases, ADM used IntentService to send messages to client applications running in the background. In Fire OS 7, IntentService is subject to all the background execution limits imposed with Android 8.0 (API level 26). For example, according to Background Service Limitations in the Android documentation:

IntentService is a service, and is therefore subject to the new restrictions on background services. As a result, many apps that rely on IntentService do not work properly when targeting Android 8.0 or higher. For this reason, Android Support Library 26.0.0 introduces a new JobIntentService class, which provides the same functionality as IntentService but uses jobs instead of services when running on Android 8.0 or higher.

In order for apps to receive ADM messages while running in the background, they must use a JobIntentService. This newer class uses jobs instead of services when running on Android 8.0 or higher.

ADMMessageHandlerJobBase is a new class that will use JobIntentService to deliver messages in the background. You should use this class in place of the old ADMMessageHandlerBase. When creating an app which interacts with ADM, you should extend ADMMessageHandlerJobBase in your handler. To follow along with an example, see Implement Handling for Registration and Messages. Additionally, see also Set Up Amazon Device Messaging and Update your App Manifest, which were also updated as part of the release.

You can download the updated ADM SDK here.

Support

If you notice any issues with your app on Fire OS 7, note the issue in the Fire tablets forums.

Last updated: Mar 01, 2023