Re: [Aerogear-users] Trouble sending Android Push Notifications

It's seems to me some config problem. Are you sure you are using the correct project number in "senderID" instead of project id? http://monosnap.com/file/QmMAO1JQ4aWynfmatYat66vipsYxjr On Thu, Nov 26, 2015 at 8:24 AM, Rob Willett <rob.aerogear(a)robertwillett.com > wrote: > Hi, > > We’ve got iOS notifications working well and so we thought we’d > push our > luck and get Android notifications up and running. We’ve had them > working > before with another plugin so it can’t be that difficult…. > > We’ve followed the guide from here > > > https://aerogear.org/docs/unifiedpush/aerogear-push-android/guides/#troub... > > The Google web interface has changed but its still pretty much the > same. > > 1. > > We’ve got and logged the Project Number (which is the Sender Id). > 2. > > We’ve created a new server API key (is this the same as the GCM > Messaging key?) > > This appears to be all thats needed. We have an very old version of > our > app sitting in development in the Google Play Store but its never > been > released as we focussed on the iOS version. That used to linked to > the GCM > information but we have unlinked that now. > > 1. > > We have created a new variant on the UPS for Android. We create a > name, description and where it asks for the Google Cloud Messaging > Key we > enter the Server API key we created in point 2. This is a bit we are > unclear about, is the google Cloud Messaging Key the same as the > Server API > key we generated in Google Play services console? One of the things > we > noticed is that the example Google Cloud Messaging Key in the UPS > dialogue > box starts with a different few header bytes e.g. 5a44 whereas all > the > Server ApI keys start Alza. We are not experts on cryptography but we > thought that *might* indicate a different type of key. It also might > be nothing at all and Google has simply updated something. > 2. > > We add in the Project number. > 3. > > This creates the Android variant in the UPS dashboard. If we click on > the variant we can see the expanded information showing the Server > URL, the > Variant ID and the Variant Secret. > 4. > > This seems to work much the same as the iOS variant. > 5. > > We then update our Cordova app and update the pushConfig field. > > var aeroGearPushConfig = { > pushServerURL: > "https://push-jambuster.rhcloud.com/ag-push/", // Checked that this > matches the Android variant. > ios: { > variantID: “XXXXX-TTTc-OOOO-RRRR-BBBHBHBH”, > // Obscured > variantSecret: > “JKJKJ-HHHH-PPOPIO-sdsds-1231232” // Obscured > } , > android: { > senderID: “XXXXXX” , // Changed to protect > the innocent but checked that the senderID is the same as the Google > Project Id > variantID: “345345-345345-45345-xxxx-zzzzz” > , // Changed but checked to make sure this is the Android VariantId > variantSecret: > "9b762d92-a7f0-4e8b-b6e4-adde4950c7e6" // Changed but checked to make > sure this is the Android VariantSecret > } , > sendMetricInfo: true, > alias: UUID // This is a unique string > }; > > We compile and run it on a real device, a Nexus 5. We create a unique > alias to be sent to be sent as the alias. This is the UUID field > > 1. > > When we run the code and inspect the output in Chrome, the aeroGear > Success Handler is called which we hope means success. > 2. > > When we inspect the variant in the UPS dashboard, we can see that the > a device with the right alias is created. The alias matches the alias > we > sent. > 3. > > This all looks good. We have three real (i.e. non simulator) test > devices in our UPS dashboard, two iOS devices and one Android device. > 4. > > We click on the Send Push icon in the UPS dashboard to create some > sample notifications. We send a simple test message to all variants. > The > two iPhones each get the test message and the Android phone > doesn’t. > 5. > > We click on the Dashboard icon in the UPS console, and then recent > activity. We can see that the UPS server thinks it has sent the test > message to the iOS and the Android variants. with no issues. We get > alerts > for the iOS pop up but nothing for the Android version. > > Notification Receivers Status Timestamp > {"ipAddress”:”XX.YY.ZZ.216","clientIdentifier":"A... 3 > installations Succeeded 26 Nov, 10:09:04, 2015 > Request IP: XX.YY.ZZ.216 Details > Message: test11 > Variants: > Android Jambuster Succeeded 1 installations > Jambuster Development Succeeded 2 installations > > > 1. > > The main UPS console doesn’t report any errors and it states that 3 > installations are registered. We’ve sent 657 notifications since > yesterday > trying to see what the problem is. We though that using the UPS > console > removed any issues with us creating the test message. Since we can > see the > iOS devices getting the test message, we are struggling to understand > why > the Android wouldn’t. > 2. > > We’ve tried with the Android app running in the foreground, > background > and not running at all to see if that makes any difference and still > nothing comes through. > 3. > > If we look at the log files using roc tail, we can see that the > messages get passed on. No error messages are reported. > > 2015/11/26 05:20:38,528 INFO [PushNotificationSenderEndpoint] (EJB > default - 7) Processing send request with &apos;[alert=Test12, > criteria=[aliases=null, deviceTypes=null, categories=null, > variants=null], time-to-live=-1]&apos; payload > 2015/11/26 05:20:38,530 INFO [PushNotificationSenderEndpoint] > (http-/127.3.204.1:8080-5) Message submitted to PushNetworks for > further processing > 2015/11/26 05:20:38,533 INFO [GCMPushNotificationSender] (EJB > default - 7) Sending payload for [1] devices to GCM > 2015/11/26 05:20:38,590 INFO [GCMPushNotificationSender] (EJB > default - 7) Message to GCM has been submitted > 2015/11/26 05:20:38,726 INFO [APNsPushNotificationSender] (EJB > default - 7) Message to APNs has been submitted > > Whilst it is impossible for people to debug our code and we don’t > want > people to, we’re struggling to understand what we could have done > wrong. > The fact we are getting iOS messages through whilst Android messages > are > failing (but with no error) is perplexing. We have rebuild the Server > API > kets in Google, deleted and rebuilt the Android variant but we’ve > now hit a > brick wall. We have a nagging feeling it is something to do with the > GCM > Server API key but everything reports OK. > > Any and all suggestions gratefully received. > > Thanks > > Rob > > _______________________________________________ > Aerogear-users mailing list > Aerogear-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-users > > -- -- Passos _______________________________________________ Aerogear-users mailing list Aerogear-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-users