Recabamos en diferentes foros para así traerte la respuesta a tu duda, si tienes dudas puedes dejarnos tu duda y te contestamos con gusto, porque estamos para servirte.
Solución:
Entonces, me las arreglé para hacerlo así:
Definidos dos sabores
gms
dimension "services"
buildConfigField "String", "SERVICE_USED", '"g"'
hms
dimension "services"
buildConfigField "String", "SERVICE_USED", '"h"'
Utilizo la “g” y la “h” en el código siempre que necesito decidir hacer cosas como: la API requiere una deviceType de “android” o “iOS” y con la inclusión de la compilación de Huawei definimos otro “huawei” constante. yo suelo SERVICE_USED para saber qué constante enviar.
Luego hice esto en la parte superior de build.gradle:
apply plugin: 'com.android.application'
if (getGradle().getStartParameter().getTaskRequests().toString().contains("Hms"))
//*meh*
else
apply plugin: 'io.fabric'
porque estaba usando fabric (y fabric / firebase … realmente no funciona con HMS) y también hice esto en la parte inferior de build.gradle
if (getGradle().getStartParameter().getTaskRequests().toString().contains("Hms"))
apply plugin: 'com.huawei.agconnect'
else
apply plugin: 'com.google.gms.google-services'
para incluir solo el complemento adecuado.
Luego comencé a manejar cada cosa que estaba usando gms (mapas, ubicación, notificaciones push, análisis) haciendo un contenedor y separando el código en cada sabor. es decir, para las notificaciones push, creé un HPushNotif que tiene un getToken método. Defino la misma clase y método en ambos sabores pero los implemento según el tipo de servicio (gms o hms).
Usé este tipo de notación al incluir dependencias en el proyecto:
//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'
los gms y hms antes de Implementation referirse al nombre de los sabores. Esas dependencias solo se cargarán cuando se seleccione el BuildVariant apropiado (es decir, se está construyendo el sabor apropiado).
Básicamente, envolví la lógica para mapas, análisis, ubicación y notificaciones push para ambos casos. Así es como se ve la estructura. Nada especial.
Eso es todo. Cuando crearon HMS, básicamente copiaron GMS clase por clase y método por método. Verá que los nombres de los métodos exactos coinciden exactamente, incluso con los parámetros de llamada y los valores de retorno. Son 99,99% iguales. Eso facilita las cosas. Básicamente, solo necesita copiar el código en dos clases e importar las cosas adecuadas (en la parte superior de la clase). Rara vez necesita cambiar el código que ya ha escrito para GMS.
Espero que ayude a alguien.
Antes de responder a su pregunta, aquí hay una breve explicación de qué es HMS y GMS:
- HMS son las siglas de Huawei Mobile Services
- GMS son las siglas de Google Mobile Services
Puede publicar su aplicación (que utiliza las bibliotecas de Google) en la tienda de aplicaciones de Huawei (llamada AppGallery), pero esta aplicación estará visible y disponible para descargar solo para los dispositivos de Huawei que contengan HMS + GMS (todos los dispositivos hasta 2020 tenían HMS y GMS).
Sin embargo, los teléfonos más nuevos, es decir, la serie Mate 30, P40, solo habrán instalado HMS. Entonces, si desea que su aplicación sea visible para todos los dispositivos Huawei (HMS + GMS y HMS), deberá implementar en su aplicación la función para detectar qué servicio está activado en el dispositivo del usuario. Decidirá qué función adecuada llamar (es decir, inicializar la instancia de Huawei Maps o Google Maps).
Aquí está el código para detectar HMS y GMS:
Para los servicios móviles de Huawei utilizamos:
HuaweiApiAvailability.getInstance().isHuaweiMobileServicesAvailable(context);
https://developer.huawei.com/consumer/en/doc/development/HMS-References/huaweiapiavailability
Para los servicios móviles de Google utilizamos:
GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context);
https://developers.google.com/android/reference/com/google/android/gms/common/GoogleApiAvailability
Aquí está el código de cómo manejar correctamente la detección de HMS y 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, estas clases (HuaweiApiAvailability / GoogleApiAvailability) están disponibles si implementa cualquiera de los kits de Huawei / lib de Google.
Si bien realmente depende de la arquitectura de su aplicación, existen 2 alternativas razonables hasta ahora;
- Usando sabores y variantes, esto le dará más flexibilidad. Establecer la arquitectura y la implementación llevaría relativamente más tiempo, pero es un enfoque limpio que proporciona un buen aislamiento del código. Dado que esos ecosistemas tienen diferentes mercados (AppGallery para Huawei), con sabores y variantes, es muy útil establecer canales de construcción separados. Te da la capacidad de mantener diferentes apk para diferentes ecosistemas.
- Usando un enfoque de envoltura / puente. Simplemente, implemente las clases contenedoras para decidir y reenviar solicitudes a los puntos finales correspondientes. Con este enfoque, es posible mantener un solo para ambos mercados. HMS en realidad proporciona una herramienta robusta para esto. Analiza el código que depende de GMS, luego genera automáticamente clases contenedoras y convierte el código original para usar clases contenedoras. Se llama “HMS Converter” e incluso tiene un complemento de Android Studio. https://developer.huawei.com/consumer/en/huawei-toolkit/
Te mostramos comentarios y puntuaciones
Si entiendes que ha sido de utilidad este artículo, sería de mucha ayuda si lo compartes con otros entusiastas de la programación de esta forma contrubuyes a dar difusión a nuestra información.