Which is the best practice way to prepare app for both app gallery and play store release
Searching web i found few approaches:
-(1)using flavors (one for googlePlay and one for appGallery) each defining same boolean field "isHuawei" ( no for googlePlay and yes
for appGallery flavor). Based on this boolean google play services are used or not
productFlavors {
google {
buildConfigField "boolean", "isHuawei", "false"
}
huawei {
buildConfigField "boolean", "isHuawei", "true"
}
}
-(2)adding in gradle for app gallery release :
project.gradle.startParameter.excludedTaskNames.add('processHuaweiReleaseGoogleServices')
Is there any inconvenience if this task is not run for huawei release?
-(3)the following code to find out if running on huawei (with no google play) or phones with google play
FirebaseMessaging.getInstance().token.addOnCompleteListener { task -> if (!task.isSuccessful) { noGMS } else { GMS }}
-(4)using
GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(nContext))
to find out if this build is for phone with GMS or not.
Using 1,3 and 4 from the above on app startup to find out if app is currently running o phone with or without GMS is a good practice?
If all three returns false it can means that the application is running on a phone whitout GMS.
There are huawei phones that can have App Gallery and Google Play Store. How to manage appGallery relase for huawei phone running both stores?
To publish your app in AppGallery on Huawei phones, you will meet two situations:
App runs on Huawei phones with both GMS(Google Mobile Service) and HMS (Huawei Mobile service)
App runs on phones with only HMS (Huawei Mobile service)
If you want to use one APK for both situations: To guarantee your app works on both Huawei phones with GMS+HMS and Huawei phones with only HMS, you can use 1, 3,4 mentioned in your post to tell if the phone is a GMS phone or HMS phone and handle the situation differently in your code. The reason is that: on Huawei HMS-only phones, it does not have GMS to support some of the Google SDKs like IAP， Map, etc. You will need to integrate Huawei HMS IAP, Map, etc. SDKs in your app so to make it work.
You can find all the detailed HMS SDKs info. here: https://developer.huawei.com/consumer/en/hms
Or for complicated business logic and to support future API changes (including deprecation), you can have two code bases: one APK with HMS SDKs integrated for Huawei phones with only HMS and one APK for Huawei phones with both HMS and GMS. This also means you will need to use a different package name and key for the APK you submitted in Huawei AppGallery. This will help to avoid the update conflicts with the version in the Google play store.
Related
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
I have a Mobile App for Both Android and iOS, both are built using Xamarin.
Android - The app is uploaded to the play store on the Beta Track and once testing is completed it is promoted the Production Track.
iOS - The app is uploaded to Test Flight once testing is completed a new release is created in AppStoreConnect, the build is set to the app currently in test flight and then set ready for sale (therefore showing in the Apple AppStore).
Is there a way to detect in the Mobile App if the App was installed from the Beta Track or Production Track in Play Store (for Android). And for iOS detect if the app was installed from Test flight or the App Store?
I also have 2 different WCF Web services that the mobile app connects to, one is the Beta services and the other is the Production services, these endpoints are hard coded in the app.
What I am trying to accomplish is when the app is installed from the Production Track/App Store then connect to the Production services endpoint, when the app is installed from anywhere else (i.e. Beta Track/Test Flight) then use the Beta services.
What I am currently doing is when the app opens the user is given the choice to pick between the 2. When it comes to doing a production release I remove this choice from the user and just make the app go to production only. I would preferably like the choice to be made based upon where the user installed the app from.
To be clear, the purpose of this is to build a single APK/IPA app that can be used for both Beta and Production.
UPDATE - There have been some interesting suggestions using the API to re-route the web services calls based on version number, but these still involve building separate APK files for Beta and Production versions of the app (which doesn't solve the question). As for what I'm trying to accomplish with Detecting installs from the Beta Track, it looks as though this is not currently possible.
I believe it's not possible as of now. But if you want to test your same android build against two different domain sets of API, you can make use of content provider approach. You can create a admin/utility kind of app, which will pass/update the domain in your original app through the use of content providers.
I followed the same practice in one of my product and its really cool.
Might be a bit late for you, but that answer can still help others...
It is possible to find the installation source on iOS as such:
#if DEBUG
// XCODE INSTALL
#else
NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
NSString *receiptURLString = [receiptURL path];
BOOL isRunningTestFlightBeta = ([receiptURLString rangeOfString:#"sandboxReceipt"].location != NSNotFound);
if (isRunningTestFlightBeta) {
// TESTFLIGHT INSTALL
}
else {
// STORE INSTALL
}
#endif
I still don't have an answer for Android though.
We received news from Google, that play store will no longer sho win Huawei.
Huawei has come up with another store called AppGallery . The question is, can same apk upload to Huawei AppGallery and the other still active in Play Store ?
It's possible to upload the same APK file to both Google Play Store and HUAWEI AppGallery. But 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, like Mate 30, P40, and any other new devices. Huawei app reviewers won't set it visible on HUAWEI AppGallery.
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
An annoying challenge arises on devices where both Play Store and Huawei AppGallery are installed. I distribute the same app with the same signature, but different mechanisms for purchasing access to premium functionality. If a user has installed the app from Play Store, and has acquired an in-app purchase, unfortunately the AppGallery updates the app also for this user, thus making him loose the purchase.
You can use absolutely the same *.apk (not *.aab).
The only problem (at least for us) is the absence google services =( So if you use pushes or remote config or smt like this it might be a problem.
When it comes to firebase you can check services which require google services here
Before publishing my app on Google play store, i testing my app on Micromax A63(Android 4.2) it works accurate but after Publishing when i tried to download my app from Google play store it show "device is not compatible "...whats the reason..I'm confused
The possible errors are:
You had another phone on this account (just check it and make login google play with the correct account)
You haven't set correctly something when uploading the apk. Go to the App tab on Google developer console and check if you made available your app for your:
Phone Device
County
Carrier (the mobile network you are paying for your phone service).
I uploaded my signed app to the android market, I made some in app contents that I've published (but not the app).
Now I trying to purchase my own products on a real device: do I need to test with the same signed .apk I uploaded to the market? Or a "normal" one I can launch with Eclipse?
Cause when I launch my app with Eclipse and send a requestPurchase(), a pop up tells me that this app version is not ready for market purchase...
You do not need to publish your application to perform end-to-end testing with real product IDs; you only need to upload your application as a draft application. However, you must sign your application with your release key before you upload it as a draft application. Also, the version number of the uploaded application must match the version number of the application you load to your device for testing.
And as it's write on google's doc, the version number of the app on the market and of the app on the device are the same :/
You need to use a signed APK, the same one you uploaded to the app market.
You also need to use a different gmail account to your developer account to access the market.
There's a good tutorial here: Simple In App Billing with some alternative explanations
The testing developer guide is pretty thorough: Testing Billing Statically
You just need to sign the apk (in Eclipse : Android Tools -> Export Signed Application Package...) and reinstall it on the device (with the device attached to USB : adb install _YOUR_APK_).
There's also a way to test your app on the emulator with your own products before going to the real money : android test billing library.
This library is the In-App billing implementation for the emulator, which was tested in the application Horer horaires de RER.