Implement and document the way to migrate from GCM to FCM (Both uniqush-push and mobile apps)
TysonAndre opened this issue · comments
- change the URLs directly to https://fcm.googleapis.com/fcm/ , opt in by default (https://developers.google.com/cloud-messaging/android/android-migrate-fcm#update-server-endpoints)
- Verify assumptions by creating a test GCM app with two builds - One with GCM, one with FCM, both in the same project
- Prevent duplicate pushes within uniqush-push (may start being a larger issue when migrating): #145
- Check if assumptions about GCM are true on other clients (e.g. FCM on APNS)
- Research how other projects migrate from GCM to FCM (On the backend and mobile apps)
Maybe uniqush could add an option to convert GCM subscriptions to FCM
FCM may or may not require that a second API key be created, I don't know if that key would work for GCM
Consider documenting the upgrade process for uniqush subscriptions on the wiki if a maintainer successfully does so for GCM subscriptions.
Aside: GCM and FCM don't coexist on clients. I'm not sure if duplicate pushes from GCM/FCM tokens are going to be an issue
This is a serious issue. aliasing "gcm" to route to the "fcm" service can solve this issue once GCM is fully out of service.
It would be great if a migration tool can be created. Google says all GCM tokens will also be valid for FCM, so I think just changing the subscriptions internally to FCM is the only thing that's required in the migration.
Some interactive CLI command would be nice:
- Loop through services that have a GCM PSP but don't have a FCM PSP yet
- Ask whether you want to migrate this service
- Ask for a new key for FCM service
- Create a new FCM PSP with the given keys
- Migrate all the old GCM PSP subscriptions to the FCM PSP
http://uniqush.org/documentation/usage.html has been updated to mention FCM equivalents of GCM functionality. I'm changing this issue to track the migration to FCM as a whole (since this issue already has most of the discussion)
I'll need to set up a test app with GCM/FCM with emulators and real devices to verify that any implementation works as expected (No duplicates, no lost subscriptions, works even if FCM was created beforehand, etc)
Other thoughts:
- It's probably possible to change the URLs directly to fcm.googleapis.com/fcm even before migrating (according to https://developers.google.com/cloud-messaging/android/android-migrate-fcm#update-server-endpoints) , but I would want to have one of the maintainers (or myself) verify that it works first.
- #145 is useful for avoiding potential duplicate pushes (due to gcm and fcm reg ids being different), if clients provide the device id
@TysonAndre according to this https://developers.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html:
What happens to my users who don't update their apps?
As long as users have GCM logic in their apps, they will still receive messages. FCM is backwards compatible with GCM, so even if you don't update your server endpoint now, you can still update your app's logic, and vice versa.
and
But rest assured, your existing GCM tokens will continue to work with FCM so you won't lose the ability to send messages to your existing users.
So I think we can completely ignore my message from April 19.
I read the Google Developers blog like this:
- If you send messages to FCM with GCM tokens, and the client has GCM, it will still receive messages
- If you send messages to FCM with FCM tokens, and the client has GCM, it will still receive messages
- If you send messages to GCM with GCM tokens, and the client has been upgraded to an app version with FCM, it will still receive messages
So I think the only thing that Uniqush needs to do is:
- Change the GCM API URL to the FCM API URL
I see that you already made a commit for that. Is it possible that a test debian package is created? I'm willing to test this on our testing environment. We are currently in the process of upgrading our clients to FCM, so we can do extensive testing with GCM/FCM switching.
2.6.0 was released with the associated packages, which change the GCM API URL to the FCM API URL.
Something that I'd have to look into, but haven't tried yet (e.g. by starting a sample gcm app in an emulator/test device, and turning it into an fcm app, then checking what apikey (server key) can be used to send to old and new builds):
https://developers.google.com/cloud-messaging/gcm#key
Starting from September 2016, you can create new server keys only in the Firebase Console using the Cloud Messaging tab of the Settings panel. Existing projects that need to create a new server key can be imported in the Firebase console without affecting their existing configuration.
Would the new server key for the existing key be the same as the server key for FCM in existing apps?
If that doesn't work out,
another approach that might be possible would be to support both apikey and fcmapikey, and make /subscribe mention is_actually_fcm for GCM projects.
@TysonAndre This is what we did, we turned our existing GCM app into an FCM app.
I think we created a new FCM PSP for people that were newly registered through FCM, old clients are still GCM tokens on FCM.
So in short:
New clients with FCM tokens receive push messages through the FCM PSP
Old clients with GCM tokens receive push messages through the GCM PSP (which is configured with the FCM API url)
I used the legacy API key while creating the FCM PSP.