如果还使用 iOS，Google Play 服务 8.4.0 会破坏 Android 的 Google Cloud Messaging [英] Google Play Services 8.4.0 breaks Google Cloud Messaging for Android if iOS is also used
问题描述
有几个帖子描述了这个问题的各个方面，但还没有一个令人满意的答案，所以我试图在这里整理它们，希望得到一个可以解决所有这些问题的权威答案.
There are several posts that describe aspects of this issue, but there hasn't yet been a satisfying answer, so I'm attempting to collate them all here in hopes of getting an authoritative answer that can address all of these issues.
将 Google Play 服务更新为 8.4.0 自己显示的推送通知后
gcm.notification.e=1 在 Android 上的推送通知负载中代表什么?
问题的要点是，如果您仅使用数据创建 GCM 消息(即不使用通知字段，因此不打算让它生成通知)并且您包含 content_available=True(这是获取iOS 客户端所需的行为)，然后从 8.4.0 开始，这会在 Android 中生成不受欢迎的空白通知.在 8.4.0 之前，一切正常.
The gist of the problem is that if you create a GCM message with data only (i.e. not using the notification field, and thus not intending for it to generate a notification) AND you include content_available=True (which is necessary to get the desired behavior from iOS clients), then since 8.4.0, this generates a undesirable blank notification in Android. Prior to 8.4.0, everything worked just fine.
问题的具体情况似乎是，如果Android客户端收到一个它不理解的GCM字段，而不是直接忽略它，它会添加一个e=1"字段(大概e"表示错误?)作为通知即使之前消息中没有通知，导致它触发使通知出现的代码，而不是将其定向到要处理的应用程序的代码.
The specifics of the problem seem to be that if the Android client receives a GCM field it doesn't understand, instead of just ignoring it, it adds an "e=1" field (presumably "e" means error?) as a notification even if there was no notification in the message before, causing it to trigger the code that makes a notification appear, rather than the code that directs it to the application to be handled.
可能的解决方法:我想可以在服务器上跟踪哪些客户端是 iOS 哪些客户端是 Android，并且只包含 iOS 客户端的 content_available 标签，这个问题将得到解决.但是，过去没有必要这样做，而且我的系统的构建理念是，我可以像预期的那样对客户端类型不可知.
Possible workaround: I imagine that one could keep track on the server of which clients were iOS and which clients were Android, and only include the content_available tag for the iOS clients, and this problem would be solved. However, it wasn't necessary to do this in the past, and my system was built with the idea that I could be agnostic to the client types, as it seems was intended.
content_available 标志突然在 Android 上导致这些空白通知的事实似乎是一个新引入的错误，但了解它是否实际上是一个可能在 8.5.0 中修复的错误将非常有用(在在这种情况下，我现在可以使用 8.3.0 构建，直到 8.5.0 出现)，或者如果它打算成为一个永久的解决方案.如果这种情况不会改变，那么正确的解决方案是跟踪哪些 GCM 注册 ID 属于 iOS 设备，哪些属于 Android 设备，然后每次发送两个单独的 GCM 请求?
The fact that the content_available flag suddenly causes these blank notifications on Android seems like a bug that was newly introduced, but it would be very useful to know if it is in fact a bug that might be fixed in 8.5.0 (in which case I could just build with 8.3.0 for now until 8.5.0 comes out), or if it is intended to be a permanent solution. If this is not going to change, is the correct solution to keep track of which GCM registration IDs belong to iOS devices and which belong to Android devices, and then to send out two separate GCM requests every time?
预先感谢 Google 团队对此问题的任何官方答复.
Thanks in advance for any official responses to this question from the Google team.
推荐答案
今天我终于得到了 Google 的确认，这实际上是一个错误，并且修复程序已在本周推出.我还可以确认我在 8.3.0 中看到的行为现在在 8.4.0 中的工作方式相同，因此显然修复完全在服务器端完成.
Today I finally got an acknowledgement from Google that this was in fact a bug, and that the fix was rolled out this week. I can also confirm that the behavior I was seeing in 8.3.0 now works the same in 8.4.0, so apparently the fix was done entirely on the server side.
我还被告知，实际上最佳做法是在服务器端将 GCM 消息分区到 iOS 设备和 Android 设备之间，因为将来可能需要不同的有效负载适用于不同平台.
I was also advised that it is in fact best practices to partition your GCM messages on the server side between those going to iOS devices and those going to Android devices, as there may be times in the future where different payloads may be needed for the different platforms.
这篇关于如果还使用 iOS，Google Play 服务 8.4.0 会破坏 Android 的 Google Cloud Messaging的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
