The pitfalls of developing Google Play Instant

From the sandbox

Hi, Habr! My name is Kamo Spertsyan, I am engaged in Android development in PROFI.RU. I recently wrote an application with instant launch for our clients. If you are not familiar with the technology, I invite you to first visit the Android Developers .

More than two years have passed since the presentation of Instant Apps (Google Play Instant) on Google I / O 2016. There are many articles on the web on how to create applications with instant launch. Judging by them, nothing complicated about it. But in fact, this is not entirely true. I will try to describe the main difficulties that I had to go from creating an empty project to publishing the Instant App on Google Play. I hope the article will be useful to developers who still have this way.

Choice of approach

Most sources describe the process of converting the entire main application to the Instant App. However, our application didn’t meet the 4MB limit and provided much more functionality than was required to familiarize with the service before installation. Now Google in test mode has increased the allowable size of the application with an instant launch of up to 10 MB.

I had a choice of two approaches to creating an Instant App. The first is to take the finished application and cut out unnecessary functionality from it. The second is to create an empty project and transfer into it the functionality that is needed. Considering the first option fast, my colleagues and I tried it on a local hackathon and at the same time we were convinced that it was hopeless. First, it took a lot of time (about 40 man-hours). Secondly, the size of the application turned out to be very large due to the extra code and resources. Thirdly, the extra code complicated maintenance. We frantically tried to fit the resulting application of 4 MB during the hackathon, and in the end we still did not have time.

Migration of functionality

Having learned from bitter experience, I created an empty project and began to copy into it only the necessary application modules. We have a modular architecture, so it was easy to do. Here I ran into the first problem - in Instant Apps you cannot use services. In my case, this restriction was not critical: we used the service to upload photos, and in the Instant App, we rejected this feature, motivating users to download the main application. But this point should be taken into account if your application also uses services.

To my surprise, the application obtained by copying only the necessary pieces of code still did not fit into the allowable 4 MB and weighed about 5 MB. In this articleGoogle gives advice on this case, but they helped me a little. The only thing we could refuse was custom fonts, but their weight did not significantly affect the size of the APK.

Then I remembered that ProGuard in our project is disabled in debug builds. Simple inclusion

minifyEnabled true

reduced the size of the application almost doubled. About a miracle - the limit of 4 MB is met!

Data migration

Next was to solve the issue with the migration of data. As you know, Instant Apps are supported by the Android operating system from version 5.0. At the same time, automatic data migration works only starting from Android 8.0. To do this, it is enough to use the shared names in the two applications with the same name. For versions from 5.0 to 7.1, you need to write the migration manually using the Cookie API or Storage API . I took advantage of the cookie and did not encounter any special problems - however, this required changes not only on the Instant App side, but also in the installed application. So in the end I had to release a new version of the application and roll it out to the entire audience for the release of Instant App.

Debugging

With debugging, everything was not so simple.

First, Google Play Instant does not support unprotected network connections, so forget about http, only https. For me, this meant testing on production-servers, since all the test benches worked on http. Not critical, but pleasant enough.

Secondly, the launch of the Instant App itself: you can test the application as usual, installed, but only for a while. When running via Android Studio, it is impossible to check the update of the Instant App to a “full-fledged” application. For example, test how well the user data is transferred. To do this, you need to run the application with an instant launch just like the Instant App. This can be done in two ways:

run the application using a special utility from the Android SDK;
put it in the console for internal testing and run through the Play Market.

The first method is quite convenient. The utility is included in the Android SDK, but is not installed by default. To install in Android Studio, follow these steps:

go to Preferences -> Appearance & Behavior -> System Settings -> Android SDK ;
select the SDK Tools tab ;
put a tick near the Google Play Instant Development SDK and click Apply .

In the last step, pay attention to the directory where the utility will be installed. Further, regarding this path, we will be interested in the ./extras/google/instantapps/ia file . With it, you can simulate an instant application launch by running the command

ia run <путь к APK-файлу, bundle-у или URL>

Until the moment I came across this utility, I used the second method, with the constant publication of the application in the Google Play Console. But since the published application does not appear in the store immediately, but after an indefinite time (it took me from half an hour to a day), this method of testing was worthless. However, it is not intended for this. By the way, if you publish the Instant App in the Google Play Console with great frequency, I advise you to provide the ability to determine the application version code after launch. Otherwise, it is difficult to understand whether the last published version or the previous one was launched.

Publication

Finally, when your application is tested and ready for publication, do not rush to relax! First, the version code ( versionCode ) of the Instant App should not exceed the version code of the application being installed. I recommend giving space for creativity in advance: when you release the main application, indicate the obviously great value of the code so as not to tie your hands. Delete released Instant App from the console in order to “release” the version code for the other assembly will not work. Formally, you have the N-Mopportunity to release Instant App while you have a main application with versionCode = Nand an application with instant launch from Google Play versionCode = M.

Also for the release of Instant App make sure that it will be available to no larger audience than the main application. In other words, every Instant App user should be able to install the main application.

The audience’s permissions are primarily affected by the permissions of the application, specified in the Manifest file ( permissions ) - they must be the same for both applications (except for permissions that do not affect the audience). For example, if your main application requires permission to determine geo-location, and in the Instant App it is not necessary, you still need to specify it there and there.

Also some auxiliary libraries can narrow down the circle of end users. So it was in our case. The console gave an error "targeting apk difference"although the resolutions of both applications were the same. In search of a solution, I came across this question from Stack Overflow, where it is advised to run the APK application files through the aapt utility . It will display detailed information about the files, including all dependencies. Having calculated the difference in the output for both files, I noticed a clue: the application being installed had a line uses-gl-es: '0x20000'that was missing in the Instant App. A brief surfing on the net led me to a clue: this line says that the application uses the OpenGL library, which, in turn, is used in maps. Indeed, our main application used the library play-services-maps, but the Instant App did not. Adding this dependency to the Instant App allowed me to finally release the application.

Summarize

In Instant Apps, you cannot use services and unprotected networks (http). The size of the final APK-file should not exceed 4 MB (perhaps soon this limit will be simplified to 10 MB).
To reduce the size of the APK file, you can use optimizers and code obfuscators (for example, ProGuard).
The transfer of SharedPreferences from the Instant App to the main application happens automatically for Android 8.0+, for earlier versions it is necessary to write manually through the Cookie API or the Storage API . It is necessary to take into account the need to release an application that is prepared for migration before the release of Instant App.
To debug the Instant App, you can use a special utility from the Google Play Instant Development SDK, included in the Android SDK.
The appearance of the instant app published in the console on end devices can occur with a delay of half an hour to a day. It is necessary to take care of the possibility to unambiguously determine which version of the Instant App has now been launched from the Play Market.
The version code of the Instant App should not exceed the version code of the main application.
The list of devices to which Instant App will be available should not exceed the list of devices to which the main application is available. To do this, specify the same permissions in the Manifest files, and also pay attention to possible restrictions due to the auxiliary libraries.

That's all. I hope this information will be useful to you. I would appreciate any feedback!

Useful sources:

Tags: