Soon new Huawei phones will stop supporting Google Play and Google Mobile Services.
Huawei is preparing its own ecosystem called HMS https://developer.huawei.com/consumer/en/service/hms/developer.html
Their app store is called "Huawei App Gallery" and has its documentation here: https://developer.huawei.com/consumer/en/doc/30202
They are now sending messages to developers (including me) that encourage them to release an app to their store. They are claiming that they only need an APK file and no changes to the application are needed.
My questions are:
Is a react-native app going to work without code changes?
Is Firebase SDK going to work?
What is the real hidden cost of maintaining an app in another Android ecosystem?
Huawei has already released its Huawei Mobile Services and is currently progressively updating its services to closely match with Google and Apple. As for the questions your asking
Is the react-native app going to work without code changes?
Yes, as long as you can generate an apk to upload to their Huawei App Gallery. You do not have to make any code changes.
Is Firebase SDK going to work?
This depends on the type of service you are trying to incorporate into your application for instance if your trying to use Google Login using the authentication module provided by Firebase then it will not be supported only on the phones that do not include GMS (Google Mobile Services) which is the Huawei Mate 30 Pro.
However, if you are looking at notifications. Google has Firebase Cloud Messaging and Huawei has its Huawei Push Notification. You can use either one as this is dependant on the architecture of the backend services and will be supported on all android devices.
What is the real hidden cost of maintaining an app in another Android eco-system?
This completely depends on how you architect the system and the services that are required within your application. Let say you want to include Huawei Sign in to be incorporated within your application and you also need to include HMS, But these you want to maintain in the Huawei App Gallery and For Google you have FCM and Google Login and Maps implemented then you would have to maintain two different branches which share the common core functionality which is time and cost consuming.
If the app is just going to use only the bare functionality which is purely dependant on logic and very little or no GMS/HMS, then you do not have to maintain separate branches for your project, just one would suffice. You just need to submit a version to your Google Play Publish and Huawei App Gallery.
If you would like to use a single repo for both GMS and HMS then you have to check the service available to enable the functionality.
For GMS
val gmsAvailable = GooglePlayServicesUtil.getInstance().isGooglePlayServicesAvailable(mContext)
For HMS
val hmsAvailable = HuaweiApiAvailability.getInstance().isHuaweiMobileServicesAvailable(mContext)
So when trying to use Google Login or Huawei Login or any other services, It would be.
if gmsAvailable {
// execute GMS Code
} else if hmsAvailable {
// execute HMS Code
}
Note* The above code is in Kotlin
Huawei has begun to build an HMS ecosystem to make top apps available on its new devices without access to GMS, such as Mate 30 and P40 devices, improving user experience on these devices. It is recommended that you use GMS if the device has access to GMS and use HMS if the device has no access to GMS.
As for your questions:
1.
Is a React-Native app going to work without code changes?
If your app uses any GMS plugins for React Native, such as Google Sign-in and Firebase Cloud Messaging, your app may not work properly on devices without access to GMS. Therefore, you need to make some code changes to your app.
Huawei has provided some HMS Core kit plugins for React Native. For details, visit the following links:
Push Kit plugin for React Native
Analytics Kit plugin for React Native
Location Kit plugin for React Native
Map Kit plugin for React Native
Health Kit plugin for React Native
Is Firebase SDK going to work?
This depends on which GMS service you use. For example, if your app uses the push notification/Location/map service of GMS, your app may not work properly. In this case, you need to use relevant HMS SDK instead. You can choose what HMS Core services to use.
3.
What is the hidden cost of maintaining an app in another Android
ecosystem?
There indeed some hidden workload, for example, maintaining code, releasing your app to HUAWEI AppGallery, and modifying both GMS and HMS to provide new functions. Of course, this depends on the complexity of your app. If your app uses many GMS services, the workload is relatively high. If your app uses few GMS services, the workload is relatively low. To reduce your workload, you are advised to use both GMS and HMS in your project. The method is as follows:
Check whether the device supports GMS
Check whether the device supports HMS
In your app, you can use the following pseudocode to use both GMS and HMS:
if isGMSAvailable {
// execute GMS Code
} else if isHMSAvailable {
// execute HMS Code
}
By doing so, you can reduce subsequent workload for maintaining code and adding new functions.
Regarding:
Is Firebase SDK going to work?
You could use this service from Huawei called QuickHMS - you simply search for a dependency/framework/library and find out if it can run as it is on HMS devices: https://quickhms.com/en/compatibility-check/
The list of current ReactNative HMS plugins can be found here: https://developer.huawei.com/consumer/en/doc/development/HMS-Plugin-Library-V1/reactnative-plugin-0000001050155850-V1
Related
I am able to build a small EMM project using new android management APIs. My use case is dedicated users device management, where we manage both hardware and the apps for our clients. All the app updates part I have been reading is using public apps or the private apps where the client will update on their device. But In our case we want up load a private app and provide updates programmatically. I have tested public app from google play store and it works fine with device policy controller. How do I access my private apps ? Also most of the documentation you see is for device admin Management related where google used to host the EMM . I am looking for the latest Android Management API solution where there is no console and we have to build one.
Update:
I am able to private publish to managed google console using this link
https://support.google.com/googleplay/work/answer/9146439
But when I apply (DPC)device policy controller to install this app .it is not happening. I tested with one of our own public apps using DPC and it installs and uninstalls instantly . Any one knows where am I going wrong ?
Any help is appreciated ....
Make sure that your private app is distributed to your enterprise. You can check this link to know more about distributing your private app to an enterprise. You can also use check this ApplicationPolicy which can push apps as part of the enterprise policy.
The Background
My app is heavily dependent on Firebase. I use most of the services like Authentication, Realtime database, Storage, Analytics, Crash Reporting and more.
Everything works fine so far, but I have a doubt regarding a particular scenario.
The Problem
As Firebase was introduced in Play Services 9, what will happen to those devices who have still not updated to Play Services 9.
How will my app work on those devices as my app is heavily dependent on Firebase?
How does Firebase cater to the scenario of backporting?
Or should the developers some how check the version of Play Services and request the user to update?
How will my app work on those devices as my app is heavily dependent on Firebase?
When installing the application, it will prompt them a message saying that this app requires a higher version of Play Services. So it will work properly.
How does Firebase cater to the scenario of backporting?
Firebase needs a minimum API of 9. If the device doesn't support anything that's missing from the device, it will simply tell them, so you don't have to worry.
Or should the developers some how check the version of Play Services and request the user to update?
NO, Android does this for you.
i have edited my answer to make things a bit more clear
1. How will my app work on those devices as my app is heavily dependent on Firebase?
Android automatically checks for the play services version that is currently installed in the user's device and prompts the user to update to the play services version that the application was built with Firebase.
2. How does Firebase cater to the scenario of backporting?
Firebase explicitly outlines the latest version of play services as a prerequisite for building with it, there is no information on the docs about back porting so I don't think it is possible at the moment.
3. Or should the developers some how check the version of Play Services and request the user to update?
I wouldn't recommend this as Android already checks and pops up a play services error. However it is quite possible to check the version of play services and request the user to first update it in order to use your application, more info on this can be found on this link isGooglePlayServicesAvailable(Context)
This is the Android version of App for limited or restricted audience
The project
I'm going to start a brand new project for one of our customers that will be deployed to our customer's suppliers to track on-field activity. I am skilled enough on Java/Android development so this question is only about deployment.
Owned vs provided devices
Our customer will either provide a Samsung Galaxy Ace 4 device to the suppliers or will allow the supplier to use their own Android 4 smartphone without warranties from us. Our customer currently has a Google for Business organization set up, but we cannot rely on that (see partial answer).
Technical (non functional) requirements
Ability to easily distribute application and updates across enterprise users.
Application should not be visible to the public
Application must be able to send crash reports so our team can inspect and investigate
The question is
Given the above "should not be visible to the public" statement, what is the most effective and efficient way to deploy an Android app targeted only for enterprise users?
I'll post a partial answer below. I'm asking others to enrich it with other possible means, including using Alpha/beta channels for which I don't have experience about
Currently, limited-audience Android applications can be deployed like this:
Publishing on Google Play as a free app for the public
Maybe adding a limitation to our country
Advantages:
Simplemost and well documented
Auto deployes updates as soon as no new permission is enforced
Collects crash reports on Dashboard
Disadvantages:
Everyone can download the app
This has the disadvantage that some organizations may not be happy as publicly available code might in some cases help exploit vulnerabilites on remote systems (but it is almost impossible if app is well-written and obfuscated)
If country limitation is enforced, imported devices won't download
Distributing the APK direct URL
Advantages:
The app remains private (enterprise users are surely not going to redistribute the app to friends as it's no use without enterprise credentials)
Disadvantages:
No crash reports unless implementing a third-party library
No auto updates unless implemented by custom code or third party library. Implementing auto updates prevents the app from being published to Google Play in the future, even on a private channel, as Play prohibits apps that auto-update themselves via third-party channels. Or, to be precise, the auto-update feature and Play publishing require, in order to exist together, maintaining two APKs
Google Play for Enterprise
As mentioned on this link, Google Play provides a private channel for app deploying for users withing a Google for Business organization. This is the perfect approach for applications that organization's users must use
Advantages:
Same as publishing for the public (simple, auto update, crash report)
Visible only to restricted audience
Disadvantages:
Every device must come with a Google account within the organization, and it will be economically unfeasible to [request the Sysadmin to] enable Google accounts for every external supplier in our target organization
Permanently in Alpha/Beta
I haven't tested this yet, as it is also very tricky. Basically, it involves using testing mode without ever going to production. With Google Play, one can deploy artifacts into Alpha (e.g. test server environment) and Beta (a trick to point to production server environment) without ever moving the app to Google Play's Production stage.
All requires setting up special moderated Google+ groups
Potential advantages:
Same as publishing to enterprise
Disadvantages:
Only telling users to subscribe to Google+ and joining a community
From your requirements, I would suggest distributing the APK via a direct URL and integrating a service such as HockeyApp (see their Android SDK for more) to manage both the crash reports and app updates.
"Ability to easily distribute application and updates across enterprise users"
Many services allow .apk files to be uploaded directly to their service for deployment. A direct download link is then generated for that build.
Crash information is collected and updates are automatically displayed if the app implements the Android SDK provided by the service.
"Application should not be visible to the public"
Services such as HockeyApp do not publicise direct download links publicly. This link can therefore be distributed as required.
"Application must be able to send crash reports so our team can inspect and investigate"
Full stack-trace and device information is sent along with crash reports and can be viewed online by technicians.
From my experience there are a few pros and cons:
Pros:
App distribution is super easy, as simple as visiting a website.
Bug reports are comparable to those received through Google Play
Cons:
Crash report's aren't sent automatically and updates aren't automatic
By default, updates and crashes appear as system dialogs prompting users to either send the crash report/update the app or cancel. Ideally, no user interaction should be required to perform the desired actions. I am sure it is possible but have not found relevant documentation for it.
Cost. These services aren't free.
Would require the removal of the service SDK from the app if uploaded to Play Store
I'm working on SDK for Android app developers.
My idea is to provide interface to app developers and have implementation on Service side.
I want to deploy the service as standalone through Google Play.
Is it possible to deploy app to Google Play that contains only service (no activity)?
From what I understand this is perfectly fine, an app doesn't need to have a main intent action, such as live wallpapers etc.
I remember reading about the Account Sync system in android and that actually encourage you to create a separate APK for your service if it's going to be used by multiple apps rather than deploying the same service into multiple APKs
Google Play services is an Android library whose goal is to provide:
OAuth 2.0 authentication
Google+ sign-in
Google+ +1 button
various other goodies
If I were to use it (for instance because I want Google+ sign-in), what would happen to users whose device does not have Google Play? (Nook, Cyanogenmod, China Mobile, old devices, maybe Huawei?, etc)
QUESTION: Will my app become incompatible with such devices? Will it be displayed as compatible but then crash, or not work?
Is there a best practice to keep this in mind when using Google Play services?
GooglePlayServicesUtil.isGooglePlayServicesAvailable(android.content.Context)
is deprecated!
Use:
GoogleApiAvailability api = GoogleApiAvailability.getInstance();
int code = api.isGooglePlayServicesAvailable(activity);
if (code == ConnectionResult.SUCCESS) {
// Do Your Stuff Here
} else {
AlertDialog alertDialog =
new AlertDialog.Builder(activity, R.style.AppCompatAlertDialogStyle).setMessage(
"You need to download Google Play Services in order to use this part of the application")
.create();
alertDialog.show();
}
If the feature from Google Play Services is essential for your app there would be no way to get your App working.
You can check if the services are enabled from within your app with GooglePlayServicesUtil.isGooglePlayServicesAvailable(android.content.Context)
which returns ConnectionResult.SUCCESS if Play Services is available.
You can now try to convince the user to install it (if possible) or disable the feature that is using the service.
As the Google Play Services is not a feature declared in the manifest your app should install fine on any device but may crash later on if you are using the APIs without checking if they are available.
You can try the behaviour with the emulator. Just create an AVD without the Google APIs and put your App on it.
As others stated, your code should ideally check for Google Mobile Services. If you don't, it will crash with a java.lang.RuntimeException wrapping android.content.ActivityNotFoundException because you'll be invoking a function on a non-existing activity.
Good apps don't crash but instead spam users with notifications in all the places they rely on on play services as other answers suggested. If possible send only a single notification to users instead of spamming them with the same notification in every place you rely on play services - or close the app after a dialog explaining why it's closing.
Better apps (e.g. Signal) contain alternative logic for handling things like notifications without making play services a hard requirement.
To which degree you can make your app work without play services is almost entirely up to your use case. If you use Firebase for instance it will be very hard to make your app work without GMS.
In most cases it's possible to avoid GMS, in some cases it's maybe not the best idea (e.g. allowing users to use arbitrary location on a dating app).
Try searching for alternatives before you lock yourself in though: OpenStreetMap will work on more devices than Google Maps, it's not as complete as Google Maps in some regions though (it's good enough for picking a delivery location though).
The recommendation that you use GMS comes from Google. I'd personally recommend you to support more devices, vendors and OSs if it doesn't require doubling your code base.
If you are somehow required to use Play Services, or if you maintain a legacy app that makes calls to Play Services, then I would recommend this strategy:
On app start, check whether Play Services is available or not
If not available, redirect Play Services calls to microG
microG is an open source implementation of Google Play Services.
It lacks many features, but is under active development. Many features are still stubs.
For location services, there is also LOST, a drop-in replacement for the Google Play services location APIs.
You app might not work perfectly, but at least it is better than crashing.
Of course, the best is to NOT use Google Play Services, from the start.
If your app uses GMS features like Google Sign-In or Firebase Cloud Messaging, it won't work well on the devices that don't have GMS.
It's recommended that you use GMS if a device supports GMS; otherwise, use HMS (Huawei Mobile Services).
Please refer to the following links:
To check whether GMS is available
HMS Overview
HUAWEI Account Kit
So you can use Google+ Sign-In on the devices where GMS is available; otherwise, use HUAWEI Account Sign-In.