Preparing your app for Instant Apps

The best instant app experiences are focused on helping the user accomplish a task quickly, like watching a video or making a purchase. You can start getting your app ready for Android Instant Apps by working through the following steps. Many of these are considered best practices for Android apps generally.

Implementing runtime permissions from Android 6.0

Android Instant Apps requires using runtime permissions that are introduced in Android 6.0 (API level 23). Instant apps framework ensures that the features operate on devices running Android 5.1.1 (API level 22) or lower. As such, make sure your app targets Android 6.0 (API level 23) or higher and uses runtime permissions. For more information on how to update your app to use Android 6.0 permissions and how to request permissions at runtime, see Requesting Permissions at Run Time.

Supporting Android App Links

Android Instant Apps uses URLs for all navigation. When a user taps a link to your instant app, they go to a specific activity within your app. If the link fails or the user taps the link on an unsupported device, the browser opens and shows your website. Also, an activity cannot launch another activity directly within an instant app; rather, it must request the URL address that corresponds to that activity.

Both your instant and installable versions of your app must implement the Android App Links feature introduced in Android 6.0. App Links provide the primary mechanism for connecting URLs to discrete activities within your app. It is recommended that your app supports both www and non-www domains. To get started with App Links, see the information on Handling Android App Links.

In addition, an instant app cannot launch an activity in another feature directly; instead, it must request the URL address that corresponds to the other other feature's entry-point activity. For more information, see Implement app links.

Defining entry points for your app

You need to use URL entry points or deep links to launch instant apps from a URL. Add intent filters for incoming links to add URL entrypoints or deep links in your application. For more details, see Implementing deep Links

Additionally, to allow Google Play and Android launcher to discover your app, you must provide at least one activity as the entry point for your app. In the app manifest, the entry point activity must have an <intent-filter> element that includes the CATEGORY_LAUNCHER and ACTION_MAIN intents.

You must also define a default URL for your app. Within the same Android manifest as your entry-point activity, define the default URL by adding a <meta-data> element with a value attribute that provides a valid HTTPS URL. The activity should be able to handle the default URL. The default URL must also be a part of the CATEGORY_LAUNCHER activity's intent filter in the installed app.

The following code snippet shows an Android manifest that defines an entry-point activity and default URL for an instant app.

<activity
  android:name=".MainActivity">
    <intent-filter>
      <action android:name="android.intent.action.MAIN" />
      <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="http" />
      <data android:scheme="https" />
      <data android:host="example.com" />
    </intent-filter>
    <meta-data
      android:name="default-url"
      android:value="https://www.example.com/index.html" />
</activity>

Adhering to the Instant apps sandbox restrictions

Instant apps are run within a tighter sandbox for security reasons. Hence they are required to adhere to the policy restrictions of the sandbox:

All declared intent filters in your instant app must support both HTTPS and HTTP protocols.
All declared intent filters must have the categories CATEGORY_BROWSABLE and CATEGORY_DEFAULT.
All declared web intent filters must have the ACTION_VIEW action.
The installable version of your app must be free, cannot be tied to a work profile, and cannot be designated as a kid's app.
You must sign your instant and installable app with the same certificate using the APK signature scheme v2.

Removing any unnecessary bulk from your app

Get rid of any unknown or unnecessary permissions, components, third-party dependencies, and libraries. Removing these items can reduce the size of your app and improve performance significantly. For more information about identifying permissions specified in your app manifest, see <uses-permission> and App Manifest.
For more information about identifying and removing unncessary components from your app, see Reduce APK Size.

Refactoring your app, if necessary

Android Instant Apps need to be structured into URL-addressable modules that are lesser than 4MB in size. For apps that are larger than 4MB, you must refactor the app into smaller modules that can be downloaded and run independently in response to URL navigation. You are free to choose what to include in each module, but it is recommended to isolate distinct user flows into different modules. This gives a fast and responsive experience within a flow and additional modules are downloaded only when the user switches flows. For example, when building a retail experience, you can separate your app into four modules: browse, search, item detail, and checkout to allow the user to download modules as needed throughout the purchase flow.

Implementing Smart Lock for Passwords if your app authenticates users

For instant apps that include login, you must integrate Smart Lock for Passwords. This allows users to quickly and securely sign in by using the credentials they have saved, as well as for users to remain signed in across app visits. For more information about implementing Smart Lock in your app, see Smart Lock for Passwords on Android.

Accepting payments with the Google Payment API

For accepting payments, Android Instant Apps is compatible with Google Play In-app Billing for digital goods and the Google Payment API for physical goods and services.

Implementing the Google Payment API

With the Google Payment API, your app can request any credit or debit card from the user's Google account, as well as Google Pay payment credentials. PAYMENT_METHOD_TOKENIZATION_TYPE_GATEWAY is required for Android Instant Apps

We recommend you use a generic purchase button. For example, use button labels such as "Buy", "Checkout", or "Purchase" to initiate the payment flow with the Google Payment API. If you prefer, you may use an approved “Pay with Google” asset button available here.

findViewById(R.id.buy_button).setOnClickListener(
        new View.OnClickListener() {
            @Override
            public void onClick(View view) {
               PaymentDataRequest request = createPaymentDataRequest();
               if (request != null) {
                       AutoResolveHelper.resolveTask(
                           paymentsClient.loadPaymentData(request), this,
                                            LOAD_PAYMENT_DATA_REQUEST_CODE);
              }
        }
    }
);

private PaymentDataRequest createPaymentDataRequest() {
        PaymentDataRequest.Builder request =
               PaymentDataRequest.newBuilder()
                     .setTransactionInfo(
                              TransactionInfo.newBuilder()
                                 .setTotalPriceStatus(
                                   WalletConstants.TOTAL_PRICE_STATUS_FINAL)
                                 .setTotalPrice("10.00")
                                 .setCurrencyCode("USD")
                              .build())
                     .addAllowedPaymentMethod(
                              WalletConstants.PAYMENT_METHOD_CARD)
                     .addAllowedPaymentMethod(
                              WalletConstants.PAYMENT_METHOD_TOKENIZED_CARD)
                     .setCardRequirements(
                              CardRequirements.newBuilder()
                                 .addAllowedCardNetworks(Arrays.asList(
                                   WalletConstants.CARD_NETWORK_AMEX,
                                   WalletConstants.CARD_NETWORK_DISCOVER,
                                   WalletConstants.CARD_NETWORK_VISA,
                                   WalletConstants.CARD_NETWORK_MASTERCARD))
                               .build());

PaymentMethodTokenizationParameters params =
     PaymentMethodTokenizationParameters.newBuilder()
       .setPaymentMethodTokenizationType(
           //Please refer to your gateway to confirm the parameters to pass
           WalletConstants.PAYMENT_METHOD_TOKENIZATION_TYPE_PAYMENT_GATEWAY)
                        .addParameter("gateway", "yourGateway")
                        .addParameter("gatewayMerchantId",
                                      "yourMerchantIdGivenFromYourGateway")
     .build();

request.setPaymentMethodTokenizationParameters(params);
        return request.build();
}

For more information about implementing Google Payment API, see the Google Payment API developer documentation.

Identifying tested compatible libraries

Android Instant Apps are compatible with a large selection of Google libraries, including those in the following list.

When debugging an instant app that uses a Google Play services library other than those included in the list above, you may see the API_UNAVAILABLE error in your debugging output. The API_UNAVAILABLE error indicates that the library has not been adapted for usage in Android Instant Apps.

Identifying allowed implicit broadcast intents

An instant app can receive the following broadcast intents:

In addition, instant apps can receive broadcast intents that have the Intent.FLAG_RECEIVER_VISIBLE_TO_INSTANT_APPS flag set.

Identifying restricted and unsupported features

User expectations may vary for apps that are installed as opposed to apps accessed via URL. Thus, certain functionality available to installed apps is not available to instant apps. Developers using any of the below functionality must refactor their app to move unsupported features to a separate library module to be included only in their installed app.

Addressing additional app requirements

In addition to other requirements listed on this page and elsewhere in the Android Instant Apps documentation, you must do the following to prepare your instant app:

All declared intent filters in your instant app must support both HTTPS and HTTP protocols.
All declared intent filters must have the categories CATEGORY_BROWSABLE and CATEGORY_DEFAULT.
All declared web intent filters must have the ACTION_VIEW action.
The installable version of your app must be free, cannot be tied to a work profile, and cannot be designated as a kid's app.
You must sign your instant and installable app with the same certificate using the APK signature scheme v2.

Restricted features

Run on the device without users being aware. Foreground services are available. Instant apps can only be started through activities that support App Links, so services, content providers or broadcast receivers won't be able to start your app.
Push notifications are currently not supported in instant apps.
Access external storage on the device. However, instant apps can temporarily use internal storage private to the app.
Discover the list of installed apps on the device, unless the installed apps have made themselves discoverable to instant apps.
Create an activity that doesn't have an associated user interface.
Access device identifiers that:
1. Persist longer than the instant app.
2. Cannot be reset by the user, including Build Serial, Mac Addresses, IMEI, IMSI. Instant apps can access the Advertising ID.
Change device settings such as change the user's wallpaper.
Run unverified software, run arbitrary native code, or load code dynamically other than the code provided by the Instant Apps runtime.

Caution: An instant app cannot use alternate means to bypass the restrictions described above. Do not attempt to use custom APIs or functionality provided by device manufacturers. Google will remove apps that violate these restrictions.

Unsupported features

Long-running background services
Manifest-registered broadcast receivers
Externally accessible content providers
Re-engagement notifications
Access to content providers from other applications

Hardware Acceleration

Android Instant Apps support OpenGL ES 2.0 with the exception of context share groups. The following extensions are supported:

GL_OES_texture_external
EGL_ANDROID_image_native_buffer
EGL_ANDROID_recordable
EGL_KHR_fence_sync

Mar	APR	May
	24
2017	2018	2019

Most visited

Recently visited

Results for