5:24 a.m.
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.
3. 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.
4. We add in the Project number.
5. 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.
6. This seems to work much the same as the iOS variant.
7. 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
8. When we run the code and inspect the output in Chrome, the aeroGear
Success Handler is called which we hope means success.
9. 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.
10. 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.
11. 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.
12. 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
```
13. 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.
14. 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.
15. 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 '[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-/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
9:27 a.m.
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 '[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-/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
9:33 a.m.
Hi Rob,
Maybe obvious but just to be sure : have you enabled "Google Cloud
Messaging for Android" API ?
You also mention that you are using an old project, I have seen before
issues with my old projects, could you create a new google project to see
if that helps ?
Last point : have you checked in the Android logs (logcat) that the message
really dies not arrive ?
On Thu, Nov 26, 2015 at 3:27 PM, Daniel Passos <dpassos(a)redhat.com> 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(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 '[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-/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
9:41 a.m.
Sebastian
Excellent questions to which we have no answers :)
Let us work through them and we’ll come back to you here.
Rob
On 26 Nov 2015, at 14:33, Sebastien Blanc wrote:
Hi Rob,
Maybe obvious but just to be sure : have you enabled "Google Cloud
Messaging for Android" API ?
You also mention that you are using an old project, I have seen before
issues with my old projects, could you create a new google project to
see
if that helps ?
Last point : have you checked in the Android logs (logcat) that the
message
really dies not arrive ?
On Thu, Nov 26, 2015 at 3:27 PM, Daniel Passos <dpassos(a)redhat.com>
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(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 '[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-/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
>
>
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
10:36 a.m.
Sebastien,
We’ve checked and Google Cloud Messaging is enabled
We’ve created a whole new Google project and started again. We’ve
created the Google GCM Server API key again, we’ve deleted the old
variant and created a new one with the new server API key and the new
Google project number. I’m going to start publishing the keys and the
secrets as it makes it difficult to follow exactly what has been done
and where. Once we have it working, I’ll remove the old Google project
and start again.
We’ve updated our Cordova project with the new variant information and
restarted up our Cordova app. We can see the Alias we created in our
Android version in the Android Push variant along with a Device Token.
The alias matches our Android alias that we uploaded.
We fire up android and look at the logcat output. Rather scary…
We send a new Push from the UPS console with the app in foreground,
background and not fired up.
```
E/WifiStateMachine( 740): WifiStateMachine CMD_START_SCAN source -2
txSuccessRate=2.06 rxSuccessRate=2.05 targetRoamBSSID=30:85:a9:6d:dc:fc
RSSI=-78
E/WifiStateMachine( 740): WifiStateMachine starting scan for
“XXXX”WPA_PSK with 5240
I/wpa_supplicant( 939): wlan0: CTRL-EVENT-SCAN-STARTED
I/art ( 740): Explicit concurrent mark sweep GC freed 159875(7MB)
AllocSpace objects, 8(128KB) LOS objects, 29% free, 37MB/53MB, paused
1.177ms total 96.881ms
I/EventLogService( 1730): Opted in for usage reporting
I/EventLogService( 1730): Aggregate from 1448549400100 (log),
1448549400100 (data)
I/SyncAdapterService(24506): Ignoring sync request for inactive user
I/ServiceDumpSys( 1730): dumping service [account]
E/WifiStateMachine( 740): WifiStateMachine CMD_START_SCAN source -2
txSuccessRate=0.76 rxSuccessRate=2.76 targetRoamBSSID=30:85:a9:6d:dc:fc
RSSI=-77
E/WifiStateMachine( 740): WifiStateMachine starting scan for
“XXXXX”WPA_PSK with 5240
I/wpa_supplicant( 939): wlan0: CTRL-EVENT-SCAN-STARTED
E/WifiStateMachine( 740): WifiStateMachine CMD_START_SCAN source -2
txSuccessRate=1.65 rxSuccessRate=2.54 targetRoamBSSID=30:85:a9:6d:dc:fc
RSSI=-78
E/WifiStateMachine( 740): WifiStateMachine starting scan for
“XXXXX”WPA_PSK with 5240
I/wpa_supplicant( 939): wlan0: CTRL-EVENT-SCAN-STARTED
```
Nothing obvious appears in the logcat output.
We have looked in the log of the Push server and can see the message
being sent to GCM
```
2015/11/26 10:22:00,265 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n]
(http-/127.3.204.1:8080-3) RESTEASY000235: Field clientConnection of
subresource org.keycloak.services.resources.TokenService will not be
injected according to spec
2015/11/26 10:22:12,244 INFO [PushNotificationSenderEndpoint]
(http-/127.3.204.1:8080-3) Message submitted to PushNetworks for further
processing
2015/11/26 10:22:12,244 INFO [PushNotificationSenderEndpoint] (EJB
default - 6) Processing send request with '[alert=Test 16,
criteria=[aliases=null, deviceTypes=null, categories=null,
variants=null], time-to-live=-1]' payload
2015/11/26 10:22:12,364 INFO [APNsPushNotificationSender] (EJB default
- 6) Message to APNs has been submitted
2015/11/26 10:22:12,487 INFO [GCMPushNotificationSender] (EJB default -
6) Sending payload for [1] devices to GCM
2015/11/26 10:22:12,546 INFO [GCMPushNotificationSender] (EJB default -
6) Message to GCM has been submitted
2015/11/26 10:22:15,267 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n]
(http-/127.3.204.1:8080-3) RESTEASY000235: Field providers of
subresource org.keycloak.services.resources.TokenService will not be
injected according to spec
```
The Aerogear Console also reports that the test pushes have gone AND
that they succeeded.
I can’t believe that we have missed a simple configuration issue on
the UnifiedPush server.
We’ll try and bypass the UPS console and write direct to GCM now
through curl or something. Do you know if the device token in the UPS
console is the Android token to use?
Thanks
Rob
On 26 Nov 2015, at 14:33, Sebastien Blanc wrote:
Hi Rob,
Maybe obvious but just to be sure : have you enabled "Google Cloud
Messaging for Android" API ?
You also mention that you are using an old project, I have seen before
issues with my old projects, could you create a new google project to
see
if that helps ?
Last point : have you checked in the Android logs (logcat) that the
message
really dies not arrive ?
10:49 a.m.
On Thu, Nov 26, 2015 at 4:36 PM, Rob Willett <rob.aerogear(a)robertwillett.com
wrote:
Sebastien,
We’ve checked and Google Cloud Messaging is enabled
We’ve created a whole new Google project and started again. We’ve created
the Google GCM Server API key again, we’ve deleted the old variant and
created a new one with the new server API key and the new Google project
number. I’m going to start publishing the keys and the secrets as it makes
it difficult to follow exactly what has been done and where. Once we have
it working, I’ll remove the old Google project and start again.
We’ve updated our Cordova project with the new variant information and
restarted up our Cordova app. We can see the Alias we created in our
Android version in the Android Push variant along with a Device Token. The
alias matches our Android alias that we uploaded.
We fire up android and look at the logcat output. Rather scary…
We send a new Push from the UPS console with the app in foreground,
background and not fired up.
E/WifiStateMachine( 740): WifiStateMachine CMD_START_SCAN source -2 txSuccessRate=2.06
rxSuccessRate=2.05 targetRoamBSSID=30:85:a9:6d:dc:fc RSSI=-78
E/WifiStateMachine( 740): WifiStateMachine starting scan for “XXXX”WPA_PSK with 5240
I/wpa_supplicant( 939): wlan0: CTRL-EVENT-SCAN-STARTED
I/art ( 740): Explicit concurrent mark sweep GC freed 159875(7MB) AllocSpace
objects, 8(128KB) LOS objects, 29% free, 37MB/53MB, paused 1.177ms total 96.881ms
I/EventLogService( 1730): Opted in for usage reporting
I/EventLogService( 1730): Aggregate from 1448549400100 (log), 1448549400100 (data)
I/SyncAdapterService(24506): Ignoring sync request for inactive user
I/ServiceDumpSys( 1730): dumping service [account]
E/WifiStateMachine( 740): WifiStateMachine CMD_START_SCAN source -2 txSuccessRate=0.76
rxSuccessRate=2.76 targetRoamBSSID=30:85:a9:6d:dc:fc RSSI=-77
E/WifiStateMachine( 740): WifiStateMachine starting scan for “XXXXX”WPA_PSK with 5240
I/wpa_supplicant( 939): wlan0: CTRL-EVENT-SCAN-STARTED
E/WifiStateMachine( 740): WifiStateMachine CMD_START_SCAN source -2 txSuccessRate=1.65
rxSuccessRate=2.54 targetRoamBSSID=30:85:a9:6d:dc:fc RSSI=-78
E/WifiStateMachine( 740): WifiStateMachine starting scan for “XXXXX”WPA_PSK with 5240
I/wpa_supplicant( 939): wlan0: CTRL-EVENT-SCAN-STARTED
Nothing obvious appears in the logcat output.
We have looked in the log of the Push server and can see the message being
sent to GCM
2015/11/26 10:22:00,265 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n]
(http-/127.3.204.1:8080-3) RESTEASY000235: Field clientConnection of subresource
org.keycloak.services.resources.TokenService will not be injected according to spec
2015/11/26 10:22:12,244 INFO [PushNotificationSenderEndpoint] (http-/127.3.204.1:8080-3)
Message submitted to PushNetworks for further processing
2015/11/26 10:22:12,244 INFO [PushNotificationSenderEndpoint] (EJB default - 6)
Processing send request with '[alert=Test 16, criteria=[aliases=null,
deviceTypes=null, categories=null, variants=null], time-to-live=-1]' payload
2015/11/26 10:22:12,364 INFO [APNsPushNotificationSender] (EJB default - 6) Message to
APNs has been submitted
2015/11/26 10:22:12,487 INFO [GCMPushNotificationSender] (EJB default - 6) Sending
payload for [1] devices to GCM
2015/11/26 10:22:12,546 INFO [GCMPushNotificationSender] (EJB default - 6) Message to
GCM has been submitted
2015/11/26 10:22:15,267 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n]
(http-/127.3.204.1:8080-3) RESTEASY000235: Field providers of subresource
org.keycloak.services.resources.TokenService will not be injected according to spec
The Aerogear Console also reports that the test pushes have gone AND that
they succeeded.
I can’t believe that we have missed a simple configuration issue on the
UnifiedPush server.
Yes, strange, looks like you are doing everything the correct way
We’ll try and bypass the UPS console and write direct to GCM now
through
curl or something. Do you know if the device token in the UPS console is
the Android token to use?
That is good test indeed and yes the token in UPS is the one you can use
for your GCM test.
Thanks
Rob
On 26 Nov 2015, at 14:33, Sebastien Blanc wrote:
Hi Rob,
Maybe obvious but just to be sure : have you enabled "Google Cloud
Messaging for Android" API ?
You also mention that you are using an old project, I have seen before
issues with my old projects, could you create a new google project to see
if that helps ?
Last point : have you checked in the Android logs (logcat) that the message
really dies not arrive ?
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
11:35 a.m.
Sebastien,
Well we have created and deleted variants and various Google Projects
all with the result. No notification but no errors.
We have validated the server API key using another curl script
We have managed to write a curl script that almost works but not quite
:) We get a MismatchSenderId error.
Grepping for this on the intertubes shows a lot of Stackoverflow
nonsense and some stuff from Google.
What we are now wondering if the device token that we are using, that
reported by the AeroGear UPS console is actually out of date.
When we delete the variant we create a new variant and register with
that. The device token created and reported by the UPS console is the
same as the old variant. We are wondering if this is incorrect and it
should be a new device token. We’re trying to delete it but you
can’t seem to delete it from the console and trying to delete it from
our app calls the Javascript error function.
We’ll keep trying, but our other Android phone packed up yesterday and
we only one left. We’re pulling out an old Samsung S3 on the off
chance it might work :)
Any thoughts on invalid device tokens?
Rob
> I can’t believe that we have missed a simple configuration issue
on
> the
> UnifiedPush server.
>
Yes, strange, looks like you are doing everything the correct way
> We’ll try and bypass the UPS console and write direct to GCM now
> through
> curl or something. Do you know if the device token in the UPS console
> is
> the Android token to use?
>
That is good test indeed and yes the token in UPS is the one you can
use
for your GCM test.
> Thanks
11:56 a.m.
New subject: Trouble sending Android Push Notifications [Solved]
Got the problem.
The device token that was being reported by the UPS Push Console was
invalid or out of date.
We wrote a quick JavaScript script to register the device and then
unregister it.
We then forced our app to register again. The device token was changed
in the UPS console variant. We tried to do a Send Push from the console
and it came
through fine.
We now can see notifications :)
Of course its almost the last thing we tried…
Now the issue is should the UPS server have got a new device token if
the variant was deleted AND the GCM project was deleted? We are not
clear when the device token is renewed but either
1. The UPS server should do this automatically when variants are deleted
or some other way of detecting that things have changed.
OR
2. Should the app do it. In which case when should push.unregister() be
called. Should we unregister and register every time the app starts up
to make sure the device token is valid. Seems excessive which is why my
first thought is that this should be server side not client side.
I don’t know what the answer is, but stale Android device tokens have
been an issue for us. The fact they survive multiple different Google
Projects AND multiple different UPS variants makes me think this is an
issue.
Anybody care to comment?
Rob (who is now going got a coffee as he’s earn it)
On 26 Nov 2015, at 16:35, Rob Willett wrote:
Sebastien,
Well we have created and deleted variants and various Google Projects
all with the result. No notification but no errors.
We have validated the server API key using another curl script
We have managed to write a curl script that almost works but not quite
:) We get a MismatchSenderId error.
Grepping for this on the intertubes shows a lot of Stackoverflow
nonsense and some stuff from Google.
What we are now wondering if the device token that we are using, that
reported by the AeroGear UPS console is actually out of date.
When we delete the variant we create a new variant and register with
that. The device token created and reported by the UPS console is the
same as the old variant. We are wondering if this is incorrect and it
should be a new device token. We’re trying to delete it but you
can’t seem to delete it from the console and trying to delete it
from
our app calls the Javascript error function.
We’ll keep trying, but our other Android phone packed up yesterday
and
we only one left. We’re pulling out an old Samsung S3 on the off
chance it might work :)
Any thoughts on invalid device tokens?
Rob
>> I can’t believe that we have missed a simple configuration issue
>> on
>> the
>> UnifiedPush server.
>>
> Yes, strange, looks like you are doing everything the correct way
>
>> We’ll try and bypass the UPS console and write direct to GCM now
>> through
>> curl or something. Do you know if the device token in the UPS
>> console
>> is
>> the Android token to use?
>>
> That is good test indeed and yes the token in UPS is the one you can
> use
> for your GCM test.
>
>> Thanks
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
12:01 p.m.
New subject: Trouble sending Android Push Notifications [Solved]
Great to hear ! And looks like my previous answer was sent while you were
sending this answer :)
As said in my previous answer, we have some running jobs that cleans up
invalid tokens but seeing your issues we need to make that more robust, at
least on our side because maybe things are getting wrong on Google's side
as well.
On Thu, Nov 26, 2015 at 5:56 PM, Rob Willett <rob.aerogear(a)robertwillett.com
wrote:
Got the problem.
The device token that was being reported by the UPS Push Console was
invalid or out of date.
We wrote a quick JavaScript script to register the device and then
unregister it.
We then forced our app to register again. The device token was changed
in the UPS console variant. We tried to do a Send Push from the console
and it came
through fine.
We now can see notifications :)
Of course its almost the last thing we tried…
Now the issue is should the UPS server have got a new device token if
the variant was deleted AND the GCM project was deleted? We are not
clear when the device token is renewed but either
1. The UPS server should do this automatically when variants are deleted
or some other way of detecting that things have changed.
OR
2. Should the app do it. In which case when should push.unregister() be
called. Should we unregister and register every time the app starts up
to make sure the device token is valid. Seems excessive which is why my
first thought is that this should be server side not client side.
I don’t know what the answer is, but stale Android device tokens have
been an issue for us. The fact they survive multiple different Google
Projects AND multiple different UPS variants makes me think this is an
issue.
Anybody care to comment?
Rob (who is now going got a coffee as he’s earn it)
On 26 Nov 2015, at 16:35, Rob Willett wrote:
> Sebastien,
>
> Well we have created and deleted variants and various Google Projects
> all with the result. No notification but no errors.
>
> We have validated the server API key using another curl script
>
> We have managed to write a curl script that almost works but not quite
> :) We get a MismatchSenderId error.
>
> Grepping for this on the intertubes shows a lot of Stackoverflow
> nonsense and some stuff from Google.
>
> What we are now wondering if the device token that we are using, that
> reported by the AeroGear UPS console is actually out of date.
>
> When we delete the variant we create a new variant and register with
> that. The device token created and reported by the UPS console is the
> same as the old variant. We are wondering if this is incorrect and it
> should be a new device token. We’re trying to delete it but you
> can’t seem to delete it from the console and trying to delete it
> from
> our app calls the Javascript error function.
>
> We’ll keep trying, but our other Android phone packed up yesterday
> and
> we only one left. We’re pulling out an old Samsung S3 on the off
> chance it might work :)
>
> Any thoughts on invalid device tokens?
>
> Rob
>
>>> I can’t believe that we have missed a simple configuration issue
>>> on
>>> the
>>> UnifiedPush server.
>>>
>> Yes, strange, looks like you are doing everything the correct way
>>
>>> We’ll try and bypass the UPS console and write direct to GCM now
>>> through
>>> curl or something. Do you know if the device token in the UPS
>>> console
>>> is
>>> the Android token to use?
>>>
>> That is good test indeed and yes the token in UPS is the one you can
>> use
>> for your GCM test.
>>
>>> Thanks
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
2:02 p.m.
New subject: Trouble sending Android Push Notifications [Solved]
Sebastien,
Unclear to me what needs to be done.
If its client side then we need to understand what we do to deregister
and register. e.g. do we do this overtime the user starts the app? That
doesn’t feel right, though thats just a feeling with nothing to back
it up.
It feels like this should be a server side activity, though thats not
because I’m trying to avoid work. I have no idea what the problem is
(or even if there is a problem). It may well be we have misunderstood
what needs to happen. I am certainly no expert on Push notifications
(though we do know an awful lot more than this morning).
We’re putting things on hold for four days as we have a vacation here,
so we’ll do nothing until Tuesday now. After the last 24 hours I want
a break to be honest :)
Happy to test ideas out or code, please ask if necessary.
Rob.
On 26 Nov 2015, at 17:01, Sebastien Blanc wrote:
Great to hear ! And looks like my previous answer was sent while you
were
sending this answer :)
As said in my previous answer, we have some running jobs that cleans
up
invalid tokens but seeing your issues we need to make that more
robust, at
least on our side because maybe things are getting wrong on Google's
side
as well.
On Thu, Nov 26, 2015 at 5:56 PM, Rob Willett
<rob.aerogear(a)robertwillett.com
> wrote:
> Got the problem.
>
> The device token that was being reported by the UPS Push Console was
> invalid or out of date.
>
> We wrote a quick JavaScript script to register the device and then
> unregister it.
>
> We then forced our app to register again. The device token was
> changed
> in the UPS console variant. We tried to do a Send Push from the
> console
> and it came
> through fine.
>
> We now can see notifications :)
>
> Of course its almost the last thing we tried…
>
> Now the issue is should the UPS server have got a new device token if
> the variant was deleted AND the GCM project was deleted? We are not
> clear when the device token is renewed but either
>
> 1. The UPS server should do this automatically when variants are
> deleted
> or some other way of detecting that things have changed.
>
> OR
>
> 2. Should the app do it. In which case when should push.unregister()
> be
> called. Should we unregister and register every time the app starts
> up
> to make sure the device token is valid. Seems excessive which is why
> my
> first thought is that this should be server side not client side.
>
> I don’t know what the answer is, but stale Android device tokens
> have
> been an issue for us. The fact they survive multiple different Google
> Projects AND multiple different UPS variants makes me think this is
> an
> issue.
>
> Anybody care to comment?
>
> Rob (who is now going got a coffee as he’s earn it)
>
> On 26 Nov 2015, at 16:35, Rob Willett wrote:
>
>> Sebastien,
>>
>> Well we have created and deleted variants and various Google
>> Projects
>> all with the result. No notification but no errors.
>>
>> We have validated the server API key using another curl script
>>
>> We have managed to write a curl script that almost works but not
>> quite
>> :) We get a MismatchSenderId error.
>>
>> Grepping for this on the intertubes shows a lot of Stackoverflow
>> nonsense and some stuff from Google.
>>
>> What we are now wondering if the device token that we are using,
>> that
>> reported by the AeroGear UPS console is actually out of date.
>>
>> When we delete the variant we create a new variant and register with
>> that. The device token created and reported by the UPS console is
>> the
>> same as the old variant. We are wondering if this is incorrect and
>> it
>> should be a new device token. We’re trying to delete it but you
>> can’t seem to delete it from the console and trying to delete it
>> from
>> our app calls the Javascript error function.
>>
>> We’ll keep trying, but our other Android phone packed up yesterday
>> and
>> we only one left. We’re pulling out an old Samsung S3 on the off
>> chance it might work :)
>>
>> Any thoughts on invalid device tokens?
>>
>> Rob
>>
>>>> I can’t believe that we have missed a simple configuration issue
>>>> on
>>>> the
>>>> UnifiedPush server.
>>>>
>>> Yes, strange, looks like you are doing everything the correct way
>>>
>>>> We’ll try and bypass the UPS console and write direct to GCM now
>>>> through
>>>> curl or something. Do you know if the device token in the UPS
>>>> console
>>>> is
>>>> the Android token to use?
>>>>
>>> That is good test indeed and yes the token in UPS is the one you
>>> can
>>> use
>>> for your GCM test.
>>>
>>>> Thanks
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
5:29 a.m.
New subject: Trouble sending Android Push Notifications [Solved]
Has this been resolved? I appear to be having the same issue even when
registering, deregistering and registering again I receive the same token in
UPS. Is this possibly linked to AGDROID-486
<https://issues.jboss.org/browse/AGDROID-486> ?
--
View this message in context:
http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Trouble-sendin...
Sent from the aerogear-users mailing list archive at Nabble.com.
5:33 p.m.
New subject: Trouble sending Android Push Notifications [Solved]
Daniel,
What aerogear-android-push version are you using?
On Sat, Jan 30, 2016 at 8:29 AM, Daniel Orton <
daniel.orton(a)d2electronics.co.uk> wrote:
Has this been resolved? I appear to be having the same issue even
when
registering, deregistering and registering again I receive the same token
in UPS. Is this possibly linked to AGDROID-486
<https://issues.jboss.org/browse/AGDROID-486>?
------------------------------
View this message in context: Re: [Aerogear-users] Trouble sending
Android Push Notifications [Solved]
<http://aerogear-users.1116366.n5.nabble.com/Aerogear-users-Trouble-sendin...
Sent from the aerogear-users mailing list archive
<http://aerogear-users.1116366.n5.nabble.com/> at Nabble.com.
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
--
-- Passos
11:57 a.m.
On Thu, Nov 26, 2015 at 5:35 PM, Rob Willett <rob.aerogear(a)robertwillett.com
wrote:
Sebastien,
Well we have created and deleted variants and various Google Projects
all with the result. No notification but no errors.
We have validated the server API key using another curl script
We have managed to write a curl script that almost works but not quite
:) We get a MismatchSenderId error.
Grepping for this on the intertubes shows a lot of Stackoverflow
nonsense and some stuff from Google.
What we are now wondering if the device token that we are using, that
reported by the AeroGear UPS console is actually out of date.
When we delete the variant we create a new variant and register with
that. The device token created and reported by the UPS console is the
same as the old variant. We are wondering if this is incorrect and it
should be a new device token.
The device token is not generated by UPS but by the GCM server who pass it
to the device and the device pass it to UPS when it registers. So even with
a new variant, the device will still returns its allocated device token,
I'm not expert in gcm tokens, I hope Daniel will be able to help more on
this. Maybe uninstalling and wiping all the data of the app will force gcm
to deliver a new and "fresh" token ?
We’re trying to delete it but you
can’t seem to delete it from the console and trying to delete it
from
our app calls the Javascript error function.
We’ll keep trying, but our other Android phone packed up yesterday and
we only one left. We’re pulling out an old Samsung S3 on the off
chance it might work :)
Any thoughts on invalid device tokens?
We have a crone job running on UPS that cleans up the invalid tokens.
Rob
>> I can’t believe that we have missed a simple configuration issue on
>> the
>> UnifiedPush server.
>>
> Yes, strange, looks like you are doing everything the correct way
>
>> We’ll try and bypass the UPS console and write direct to GCM now
>> through
>> curl or something. Do you know if the device token in the UPS console
>> is
>> the Android token to use?
>>
> That is good test indeed and yes the token in UPS is the one you can
> use
> for your GCM test.
>
>> Thanks
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
9:38 a.m.
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.
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(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 '[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-/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
9:45 a.m.
On Thu, Nov 26, 2015 at 3:38 PM, Rob Willett <rob.aerogear(a)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_...
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(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 '[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-/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
>>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
10:09 a.m.
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?
Rob
On 26 Nov 2015, at 14:45, Sebastien Blanc wrote:
On Thu, Nov 26, 2015 at 3:38 PM, Rob Willett
<rob.aerogear(a)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_...
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(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 '[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-/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
>>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
_______________________________________________
Aerogear-users mailing list
Aerogear-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users
10:16 a.m.
On Thu, Nov 26, 2015 at 4:09 PM, Rob Willett <rob.aerogear(a)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(a)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_...
> 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(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
> <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(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
>
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
9:32 a.m.
On Thu, Nov 26, 2015 at 11: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.
A member of our docs team is already on it:
https://issues.jboss.org/browse/AGPUSH-1536
-M
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 '[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-/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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3007
days inactive
3072
days old
aerogear-users@lists.jboss.org
17 comments
6 participants
participants (6)
-
Daniel Orton -
Daniel Passos -
Matthias Wessendorf -
Rob Willett -
Rob Willett -
Sebastien Blanc