问题描述
移动推送由于BadDeviceToken导致收不到通知的排查方法。
解决方案
查看app和移动推送注册的BundleId是否一致,环境是否符合预期,近期是否上传了Token。
如果出现BadDeviceToken后,该AppKey+环境再用这个DeviceToken发,会直接不再受理。所以如果在第一次出现BadDeviceToken后修改了BundleId的话,联系技术支持清一下缓存即可。
如果app和推送注册的BundleId是一致的,环境也是符合的,今天也有Token上报。而且客户使用EMAS控制台推送,有的设备是可以收到的。那就拿着上报的那个Token,用Shell脚本和证书直接向APNs推,验证Token是否正确。
运行Shell脚本,如果客户端不能收到通知,客户从端侧排查。
运行Shell脚本,如果客户端能收到通知,客户联系技术支持从服务器端排查。
如果端上能收到Shell脚本推送的通知,需要客户的p12证书MD5码给一下技术支持,这边核对一下是否和我们线上的一致。
如果能收到Shell脚本推送的通知,技术支持这边把那个设备的BadDeviceToken缓存删除,然后客户再试一下推送是否能收到。因为只要有1次BadDeviceToken,就有可能在接下来约90天的时间不再受理,所以客户再怎么试都是未受理。
用Shell脚本测试推送通知的这种方法完全和阿里云无关,直接访问APNs,如果此方法也收不到通知,需要从端侧排查通知的注册流程及APNs返回的Token是否正确;或者换台测试机测试。
Shell脚本如下,客户创建push-ios-example.sh文件,替换对应的信息,终端运行sh push-ios-example.sh
,看客户端上是否能收到消息。
#!/bin/bash
#推送p12证书的路径
CERT_FILE=${cert_filename.p12}
#推送证书的密码
CERT_PASSWORD=${cert_password}
#true是开发环境,false是生产环境
SANDBOX=true
#安装包的bundleId
BUNDLE_ID=${bundle_id}
#安装包获取的APNs的Token
DEVICE_TOKEN=${deviceToken}
if [ "${SANDBOX}" = true ]; then
HOST=api.sandbox.push.apple.com
else
HOST=api.push.apple.com
fi
curl -v \
-d '{"aps":{"alert":"Test Push Message! --EMAS"}}' \
--cert-type P12 \
--cert ${CERT_FILE}:${CERT_PASSWORD} \
-H "apns-topic:${BUNDLE_ID}" \
https://${HOST}/3/device/${DEVICE_TOKEN}
适用于
移动推送
文档内容是否对您有帮助?