問題描述
項目中同時擁有 GMS 和 HMS (Have both GMS and HMS in the project)
如何在應用中同時擁有 Google 移動服務和 華為 移動服務？
因為 華為 已經失去了許可證GMS，看來我們需要將應用中使用的所有GMS服務替換為華為提供的服務。什麼是“最佳實踐”？是為了這個？使用風味並以某種方式單獨處理每個類，還是複制粘貼項目並開始替換？或者......更好的是，有沒有辦法同時擁有兩者和......以某種方式讓應用程序根據它所在的設備決定使用哪個服務？顯然，最後一個假設會增加 APK 文件大小。
有什麼想法嗎？
參考解法
方法 1:
So, I managed to do it like this:
Defined two flavours
gms {
dimension "services"
buildConfigField "String", "SERVICE_USED", '"g"'
}
hms {
dimension "services"
buildConfigField "String", "SERVICE_USED", '"h"'
}
I use the "g" and "h" in the code whenever I need to decide on doing things like: the API requires a deviceType of "android" or "iOS" and with the inclusion of the Huawei build we defined another constant "huawei". I use SERVICE_USED to know what constant to send.
I then did this at the top of the build.gradle:
apply plugin: 'com.android.application'
if (getGradle().getStartParameter().getTaskRequests().toString().contains("Hms")) {
//*meh*
} else {
apply plugin: 'io.fabric'
}
because I was using fabric (and fabric / firebase ... don't really work with HMS) and I also did this at the very bottom of the build.gradle
if (getGradle().getStartParameter().getTaskRequests().toString().contains("Hms")) {
apply plugin: 'com.huawei.agconnect'
} else {
apply plugin: 'com.google.gms.google‑services'
}
to only include the proper plugin.
I then started handling each thing that was using gms (maps, location, push notifications, analytics ) by making a wrapper and separating the code in each flavour. i.e. for push notifications i created a HPushNotif which has an getToken method. I define the same class and method in both flavours but I implement them according to the type of service (gms or hms).
I used this type of notation when including dependencies in the project:
//GMS stuff
gmsImplementation 'com.crashlytics.sdk.android:crashlytics:2.10.1'
gmsImplementation 'com.google.firebase:firebase‑core:16.0.9'
gmsImplementation 'com.google.firebase:firebase‑messaging:18.0.0'
gmsImplementation 'com.google.firebase:firebase‑crash:16.2.1'
gmsImplementation 'com.google.android.gms:play‑services‑maps:16.1.0'
gmsImplementation 'com.google.android.gms:play‑services‑location:16.0.0'
gmsImplementation 'com.google.android.gms:play‑services‑tagmanager:16.0.8'
//HMS stuff
hmsImplementation 'com.huawei.agconnect:agconnect‑core:1.0.0.300'
hmsImplementation 'com.huawei.hms:push:4.0.3.301'
hmsImplementation 'com.huawei.hms:maps:4.0.1.301'
hmsImplementation 'com.huawei.hms:location:4.0.3.303'
The gms and hms before the Implementation refer to the name of the flavours. Those dependencies will only be loaded when the appropriate BuildVariant is selected (i.e. appropriate flavour is being built).
Basically I wrapped the logic for maps, analytics, location and push notifications for both cases. This is how the structure looks. Nothing special.
That's it. When they created HMS they basically copied GMS class by class and methd by method. You'll see that the exact method names match exactly, to the calling parameters even and returning values. They're 99.99% the same. That makes things easier. Basically you just need to copy the code in two classes and import the proper things (at the top of the class). You rarely need to change the code you've already written for GMS.
Hope it helps someone.
方法 2:
Before I answer your question here is short explanation what is HMS and GMS:
- HMS stands for Huawei Mobile Services
- GMS stands for Google Mobile Services
You can publish your app (which is using Google's libraries) in Huawei's app store (named AppGallery) but this app will be visible and available to download only for Huawei's devices containing HMS+GMS (all devices till 2020 had HMS and GMS).
However the newer phones i.e. Mate 30 series, P40 ‑ will have installed only HMS. So if you want to make your app visible for all Huawei devices (HMS+GMS and HMS) then you will have to implement in you app function for detecting what service is on on user's device. It will decide what proper function to call (i.e initialize instance of Huawei Maps or Google Maps).
Here is the code for detecting HMS and GMS:
For Huawei Mobile Services we use:
HuaweiApiAvailability.getInstance().isHuaweiMobileServicesAvailable(context);
https://developer.huawei.com/consumer/en/doc/development/HMS‑References/huaweiapiavailability
For Google Mobile Services we use:
GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context);
https://developers.google.com/android/reference/com/google/android/gms/common/GoogleApiAvailability
Here is the code how to properly handle detecting HMS and GMS:
public static boolean isHmsAvailable(Context context) {
boolean isAvailable = false;
if (null != context) {
int result = HuaweiApiAvailability.getInstance().isHuaweiMobileServicesAvailable(context);
isAvailable = (com.huawei.hms.api.ConnectionResult.SUCCESS == result);
}
Log.i(TAG, "isHmsAvailable: " + isAvailable);
return isAvailable;
}
public static boolean isGmsAvailable(Context context) {
boolean isAvailable = false;
if (null != context) {
int result = GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context);
isAvailable = (com.google.android.gms.common.ConnectionResult.SUCCESS == result);
}
Log.i(TAG, "isGmsAvailable: " + isAvailable);
return isAvailable;
}
AFAIK these classes (HuaweiApiAvailability/GoogleApiAvailability) are available if you implement any of the Huawei's kit/Google's lib.
方法 3:
While it really depends on architecture of your app, there are 2 reasonable alternatives so far;
- Using flavors and variants, this will give you more flexibility. Establishing the architecture and implementation would be relatively more time consuming yet it is a clean approach providing a nice isolation of code. Since those ecosystems has different markets (AppGallery for Huawei), with flavors and variants, it is quite handy to establish separate build pipelines. It gives you the ability of maintaining different apk for different ecosystem
- Using a wrapper/bridge approach. Simply, implement the wrapper classes to decide and forward requests to corresponding endpoints. With this approach, it is possible to maintain single for both markets. HMS actually provides a robust tool for this. It analyzes the code which depends on GMS, then automatically generates wrapper classes and converts the original code to use wrapper classes. It is called "HMS Converter" and has an Android Studio plugin even. https://developer.huawei.com/consumer/en/huawei‑toolkit/
方法 4:
Synthetizing all the good answers given before: https://github.com/abusuioc/from‑gms‑to‑hms#step‑5‑integrate‑hms‑sdks‑in‑your‑app
For most apps, a single build with dependencies on both GMS and HMS SDKs + deciding at runtime (based on the availability on the device) which one to use is the recommended way.
方法 5:
Both @AndreiBogdan and @deadfish's answer are correct. I'd like to add a little more:
First, you need to select a proper solution (G+H or G2H) based on the application scenario and development/test costs.
- If you choose G+H solution, you need to check whether the GMS is available. If the GMS interface cannot be used properly, HMS is required. For details, refer to @deadfish’s answer. You are advised to use this solution, which can
- Reduce the complexity of app packaging. A package can be released to both Google Play and AppGallery.
- Reduce the code maintenance cost. The HMS+GMS adaptation layer code is added to the original logic code. In this way, proper code can be automatically called based on the mobile phone. That is, you only need to invoke the method to check whether GMS is available on the existing logic code, and you don’t need to maintain two sets of code.
If you choose G2H solution, the workload of compatibility test is small. You only need to test the new APK on Huawei phones. Release your app both on HUAWEI AppGallery and Google Play, with different packages. The app you release on AppGallery contains only Huawei's logic code. You may refer to @AndreiBogdan's answer, or see docs Supporting Multiple Channels.
As @captaink say, you can use HMS Toolkit Convertor. It supports G+H and G2H conversion. Currently, HMS Toolkit supports Java and Kotlin. Supported Android Studio versions: 3.3.2～4.1.
(by AndreiBogdan、AndreiBogdan、deadfish、captaink、Adi B、zhangxaochen)