Full Device Coverage with HMS

Getting started with integrating Huawei Mobile Services into an existing app

App development has become increasingly accessible and well-documented in recent years. However, developers still encounter challenges in ensuring compatibility across devices and navigating store policies to release their apps on various publishing channels.

In this article, I’ll provide a comprehensive introduction to incorporating Huawei Mobile Services (HMS) into your existing app, ensuring compatibility with Huawei smartphones. As you may know, recently released Huawei phones can no longer ship with preinstalled Google Play services (GMS). This change has left many developers, including myself, confused about the implications for their apps.

Are Android projects still compatible with Huawei devices?
What happens if a user installs an app from unofficial sources?
How can I continue to reach Huawei phone users in the future?

While these questions might initially seem daunting, they can be effectively addressed with the right information. The main challenge lies in consolidating the necessary knowledge for making informed decisions during your development process, as it’s often scattered across the internet. The following sections will guide you towards successfully integrating additional services into your app and answer some more frequently asked questions:

1. Identifying dependencies and determining resulting requirements.
2. Presenting possible patterns for an effective app expansion.
3. Evaluating the pros and cons of the methods in specific situations.
4. Summarizing key takeaways to consider when planning to extend an app.

Required Dependencies

Typically, an app relies on third-party services like Google for features such as push notifications, in-app purchases, built-in maps, device location acquisition, and user authentication. These are just a few of the many services integrated by developers to enhance the user experience of their apps.

Unfortunately, most of these features will only partially function or not at all in the absence of GMS. To address this issue, Huawei has developed HMS, aiming to offer the same compatibility as Google services and even more.

How can I port an app to be available on Huawei phones?

Since Huawei phones still run on Android, making your app compatible primarily involves software additions to ensure a seamless user experience on the AppGallery, Huawei’s alternative to the Google Play Store. First, identify the GMS dependencies used in your app and determine which of the later discussed approaches is most suitable to implement HMS. It’s beneficial to prioritize mandatory services related to core features, allowing for a phased integration process.

Although the complexity of these changes depends on the number of integrated sevices, the maintenance of additional dependencies should not require substantial efforts when implemented correctly. Once completed, you’re ready to release your app on the AppGallery to reach Huawei phone users.

What if my app is developed using a specific framework?

While the majority of services provided by HMS are available for popular frameworks like Flutter and React Native, some may only be accessible as native Android libraries. Though frameworks are generally capable of executing native platform code, making all functionality theoretically achievable, Huawei emphasizes the importance of first-party framework coverage. There already are numerous solutions alongside the rapidly expanding native support.

Are there any tools to help finding dependencies in my project?

The Huawei Toolkit is a plugin for Android Studio to effectively identify Google dependencies in an existing project. It significantly helps in this process and allows developers to focus entirely on choosing how to deal with broken functionality on phones without GMS. There are also other features, but the mentioned use is undoubtedly the most beneficial.

If you know about your app’s Firebase dependencies, you may visit Google’s official page to determine which ones function without GMS.

Available Approaches

There are two available options to port an app to not just the AppGallery but any third-party app store. These approaches can be thought of as patterns and since this article compares Google services to Huawei services, I’m going to refer to them as G+H and G2H.

With the G+H approach, developers integrate any chosen service with a corresponding kit from Huawei and make availability checks for each different platform dependency. For instance, if GMS is available, use Google’s push function; if not, check if HMS is available and then use Huawei push.

In the second approach, G2H, a developer creates a separate build which only includes the necessary dependencies for its targeted platform. As an example, all the existing services that cannot work on a Huawei device need to either be completely replaced or properly removed from the additional build.

Pros and Cons

An important consideration with G2H is the necessity to change the package name if builds only include dependencies for a targeted store. If the application ID remains unchanged, all the stores offering the app with the same ID will compete for updates. Consequently, a user might receive an update from a different store than the one they initially downloaded the app from, potentially losing functionality that the other store’s application doesn’t offer.

In general, the G2H approach requires more effort in its setup because it involves maintaining two separate build variants. This extra effort is only justifiable if it’s essential to minimize the app’s size, as that, along with proper project separation, are the main advantages of this method.

Nevertheless, specific reasons may lead to choosing the G2H pattern. One reason might be the unavailability of the signing key due to a service that securely signs and stores the key. Another reason could be the requirement to use services from a specific provider to gain app store approval. Moreover, Huawei has a few specifications where a .huawei suffix must be added to an existing application ID.

The G+H approach offers more freedom. You can choose between changing or keeping the package name without worrying too much about unintended consequences. However, it makes more sense to keep the application ID to avoid confusion when downloading identical apps, as they would both show up separately. If you plan on using the same package name, you should also maintain the same signature across all app stores to facilitate automatic updates.

The package name or application ID serves as a unique identifier for apps on Android devices. If a user updates an app through a different source, the device checks if the update has the same signature as the app being updated. If signed with another key, the update is flagged as untrustworthy, warning users and preventing malicious content installation. This way, the signature acts as a guarantee to always download an app from a specific developer or development team.

If you need to use G2H but don’t want to change the application ID as previously recommended, consider checking out my native_flavor example from GitHub. It provides an easy-to-understand example and explains the necessity of incorporating the G+H pattern into the separate build variants while retaining the benefits of using an identical package name.

Two significant advantages of G+H are maintaining only one build variant and choosing which service provider a user should use. For example, if you know that one provider offers a better service, you might want to prioritize its use over others. Implementing this preference would be a lot more verbose with the G2H approach.

In the long run, G+H enforces best practices for handling situations where none of the services are available. The only real downside of this approach is a slight increase in package size which mostly depends on the number of services used.

Summary

1. The best way to reach Huawei devices will be to expand existing apps to be compatible with HMS.
2. G+H should always be favored over G2H unless there are specific reasons that require using the G2H approach.
3. With G+H the package name should remain the same and for G2H it should be changed.
4. The Huawei Toolkit can be used to help developers port an app by identifying Google dependencies.