[Aerogear-users] Trouble sending Android Push Notifications

Thu Nov 26 10:16:33 EST 2015

On Thu, Nov 26, 2015 at 4:09 PM, Rob Willett <rob.aerogear at robertwillett.com
> wrote:

> Sebastien,
>
> Thats good to know that your key starts the same as mine. Can I suggest
> that we have a standard name for what this key is?
>
> The docs refer to ‘Client ID’, ‘Server Key’ and ‘Google Cloud Messaging
> Key’
>
> ”In the Wizard after you create a PushApplication, click the Add Variant
> button and fill out the Android options. You will want to use the *Client
> ID* and Project Number from the Google API Console in their appropriate
> fields:”
>
> “On the last screen we are finally get to see the actual value of the
> generated *Server Key*, which we will use later:”
>
> ‘Google Cloud Messaging Key’ is on the dialogue box that pops up when you
> create the Android Variant.
>
> I think that ‘Client ID’, ‘Server Key’ and ‘Google Cloud Messaging Key’
> are actually all the same key, the one created in this attachment
>
> Are they all the same k,ey?
>
Yes there are and you are right it's really confusing, I add a comment to
the existing ticket about the  doc polishing
Thx again.

> Rob
>
> On 26 Nov 2015, at 14:45, Sebastien Blanc wrote:
>
> On Thu, Nov 26, 2015 at 3:38 PM, Rob Willett <
> rob.aerogear at robertwillett.com
>
> wrote:
>
> Daniel,
>
> Thanks for the reply and the diagram.
>
> We are definitely sending the right project number.
>
> and here’s the same thing in the UPS console. We’ve obscured the Google
> Cloud messaging Key. Thats the one thing we are not certain on. Do you mind
> saying if your GCM Key starts 5xxxxx or AlZa as ours does. The UPS docs are
> little unclear here.
>
> I can confirm that my keys starts also with AIza , you're saying that the
> placeholder in this screenshot
>
> https://aerogear.org/docs/unifiedpush/aerogear-push-android//img/variant_01.png
> is confusing ? I agree, let me fill a ticket for that.
>
> Rob
>
> On 26 Nov 2015, at 14:27, Daniel Passos wrote:
>
> 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 at 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/#troubleshooting
>
> 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
> <http://EJB%0Adefault%20-%207> Processing send request with
> '[alert=Test12,
> criteria=[aliases=null, deviceTypes=null, categories=null, variants=null],
> time-to-live=-1]' payload
> 2015/11/26 05:20:38,530 INFO PushNotificationSenderEndpoint
> <http://http-/127.3.204.1:8080-5> Message submitted to PushNetworks for
> further processing
> 2015/11/26 05:20:38,533 INFO GCMPushNotificationSender
> <http://EJB%20default%20-%0A7> Sending payload for [1] devices to GCM
> 2015/11/26 05:20:38,590 INFO GCMPushNotificationSender
> <http://EJB%20default%20-%0A7> Message to GCM has been submitted
> 2015/11/26 05:20:38,726 INFO APNsPushNotificationSender
> <http://EJB%20default%0A-%207> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> --
> -- Passos
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151126/70c42761/attachment.html