Currently, in order to push notifications to an android app on the android operating system, it appears the app needs to integrate Google Cloud Messaging (GCM) APIs. The App Server currently pushes data through GCM and GCM will push data to specific devices.
This is a silly question, but I was wondering if it is possible to replace GCM in this process? In other words, is it possible to have an alternative server as opposed to GCM? The motive is to hide the data from the GCM server.
Before:
App Server ==> GCM ==> Android App
New:
App Server ==> Custom Cloud Messaging ==> Android App
You can use app-directed sms/ port-directed sms.
Send sms from the server(SMS gateway) to a particular port on which your app will be listening.This sms will act as GCM message.
Using this approach you don't have to worry about long running service draining the battery. Also sms are almost real time and doesn't require internet connection.
However there are some phones don't support port directed sms.
For port directed sms you need to register a broadcast receiver something like below:
<receiver
android:name = ".SmsReceiver">
<intent-filter>
<action android:name="android.intent.action.DATA_SMS_RECEIVED" />
<data
android:scheme="sms"
android:host="*"
android:port="8095" />
</intent-filter>
The port directed sms does not appear in user's sms inbox if properly supported by phone.
Replacing GCM is actually not a trivial task. I would have to strongly advise against doing a long-polling mechanism as suggested earlier - the truth is that going down that path would be extremely expensive in terms of resources (battery life) and managing it would be a nightmare. There are going to be tons of error conditions that you're gonna need to address - from network drops to managing guaranteed delivery.
Full Disclosure: I work for Magnet Systems which has a product - Magnet Message - that provides these capabilities and more.
What we did was create a persistent socket to the server. (BTW, this is what GCM does as well as Apple's APNS). This socket is used to be able to "push" messages to the device. By understanding the connectivity on the socket, you'll understand the presence of devices and know if you can send messages to them.
Nevertheless, it's still a challenge to address things like pushing to an app that is offline or killed - and across platforms (probably don't want to forget the other 40% of iOS users) - so there are different challenges there. To address this, we send a "signal" via GCM to notify that there is a pending message and have a Broadcast Receiver that can go to our server and fetch the messages securely.
Since we allow you to deploy our server code in your environment, we don't have to see anything that you send. (Of course, we have a SaaS model as well).
At any rate, you can take a look at what we've done at http://developer.magnet.com. It's free to play with and we've got a bunch of open source stuff.
It is not recommended to bypass GCM since any other mechanism you might use will require a persistent connection from the phone to your server which will be a battery hog. GCM already has one connection open all the time so it should be reused as much as possible.
It is however understandable that you want to hide data from the GCM servers. In that case it should be simply encrypted. The Chrome team (which uses GCM) has decided to do the same (hide payloads from the GCM server) and perhaps their solution for encryption would work for you as well. You can see what they did in
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Ship$3A$20Push$20Messaging$20Payloads/blink-dev/Vga32co0YMQ/4i6qXvfeAwAJ
The same link contains a demo and the code for it.
Note that the purpose of those examples is to implement it in chrome which is not exactly what you want. However the actual encryption method could be reused for Android.
Related
I implemented a chat client using GTalk servers and (a)Smack library. So far so good. Now, what I can't wrap my head around is how to notify the user of received chats when the app is closed, the same way all other chat apps do. I was reading into push notifications but all examples I find have a server component as well, which I obviously don't since my app is just a client for GTalk.
Should I be using GCM and implement the server side for this? Should I instead attempt to start a service that will listen for incoming messages at boot time (similar to this example)?
Service is definitely the way to go, you can keep it running so that your XMPP connection remains open.
From the server you can receive the messages and through a Broadcast Receiver you can show your notification if the app is closed, when it's opened you disable the previous Broadcast Receiver and you register a new one to manage messages in your activity for example.
This is pretty much my implementation.
Thumbs up appreciated!
Enjoy
You should use an Android Service that holds the XMPPConnection.
See also:
- aSmack as a service
- https://github.com/Flowdalic/asmack/wiki/Should-applications-using-aSmack-use-foreground-Services%3F
You already have service that listens for messages, maintain network connection, etc., and it is Google Messaging Service. You want to reinvent the wheel, and duplicate existing functionality. It makes sense when you are using device without Google or other vendor services, but on typical device your service will be co-exist with Google (Amazon, Nokia) one, and maintaining multiple network connections will do much more cpu wakeups, wasting memory and that will cause battery drain.
So, using GCM/GMS is a must. Maybe fallback to self-made service will help you on the device without GCM.
Note about "GTalk client". Your application can not be full-featured GTalk client: Google Talk was a part of Google Platform (now rebranded as Hangouts). It uses many Google proprietary XMPP extensions, which you can't use from third-party client: you don't have access to message history/sync, groupchats, you can't register device in GCM for GTalk notifications, voice/video features are only partially accessible. And with GTalk deprecation in favour of Hangouts - you lost basic XMPP compatibility too and don't have modern API at all.
So, if you want to build messaging/voip application, you should have your own server, with own users database, authentication (your app still be able to authenticate users as Google users and import their contacts too), messaging storage and sync, and of course your messaging server should register users in GCM and forward messages to Google services when your client app is not connected.
There are some commercial platforms (like Parse, but I have not tested it) which gives you that "third-party server component" and SDK you should plug in to your client app and they will care about all "server-side" part of your project, including GCM.
What is the best way to enable Push Notifications in AOSP?
- One possible way is to use custom Service which opens a persistent websocket connection.
According to the comment in the answer in this question they used Parse.com PPNS push service. It is an option but it creates an always on PushService. I don't think it is battery efficient.
- Other option is to add Google Play Services into the AOSP ROM.
After Android 4.0.3, devices don't need Google Account set-up to get push notifications. But the devices should have GoogleServicesFramework to be installed at least.
When we include all Google Apps into the ROM, it enables push notifications. Google Apps package includes lots of Google APKs.
Which ones are required for push notification?
And is it legal to just add Google applications into the AOSP built?
create a lightweight background service that listens to network change actions, and in the service send any ip address change of devices to push server. You will also need a unique identifier for each device, may be mac-address or some other hw UUID. Push server needs to maintain a mapping of registered clients, their uuid, and ip address.
This background service can bind to network socket and listen for connections coming in from push server. There will be no persistent connections, just a lightweight service/daemon running in background.
For power efficient way of handling this service, please take a look at Android L JobScheduling. This SO question answer can give you some ideas. You may need to handle socket (re)binding as needed.
This solution can work if you are ok with slight delay in push notifications. Push server needs to retry connections, you may use some heuristics like letting the device inform server of its background-service running state(s).
You will need to have this service installed/running on all your devices. Once a message is received on the device, it is easy to make it look like a regular push notification.
It is illegal to include Google libraries within an AOSP build without obtaining a proper license.
This makes it impossible to send notifications with Google Cloud Messaging on AOSP devices.
What you could do instead is send notifications to devices without using GCM. You could use Pushy (https://pushy.me/) which is a highly-reliable push gateway for Android apps that works independently from GCM, using its own background MQTT connection.
Full disclosure: I founded Pushy.
I am trying to use GCM service, Every thing is OK except of the long delay that GCM push notification or deliver payload... some times it take to my App 5 minutes receive notification or payload.
I need Immediate delivering...
I know about the roles of GCM, that wait until the other device got online, but in my case I hold two devices and they are online, but I got Delayed notifications!
How does WhatsApp(as example of app that uses GCM) overcome this problem.. and send Immediately?
[ i.e (message of the type: typing, online - last seen) cannot be delayed...]
the GCM Delayed Push is known problem : this issue
my question is: How other app that use GCM overcome this issue
The big players
Lets focus on WhatsApp from a scale point of view. Their scale is global and one of the largest in terms of the market share. For players like these it becomes necessary to provide a consistent and smooth user experience no matter what the circumstances are. This means that the "small fish developers" like us are left with pre-defined rules by the big fish companies. Sometimes, it is the implementation that is challenging enough that a lot of the small time developers have to do with whatever is available.
I would like to take WhatsApp's Push Notification as an example to illustrate the above.
First of all, we must stop associating Push notification with Google's services(i.e, Google Play Services) exclusively. Would a device without Google Play services won't receive Push notifications? No, of course it can -- try focusing on the core mechanism of a push notification
How do Push Notifications work - Sockets!
Contrary to a protocol like HTTP which assumes a client-server architecture and is a uni-directional protocol(server can't initiate communication by itself), a plain socket enables communication bi-directionally.
You want to implement your own File transfer protocol over socket? You can!
You want to implement your own Chatting protocol over socket? You can!
You want to implement your own Push notifications protocol over socket? You can!
A socket is the canvas of communication over a network. You can pretty much do anything. Personally we have developed a custom request-response protocol in our organization.
Multiple implementations
Don't stick with default GCM/FCM notification messages protocol or implementation. You can deploy a mechanism to maintain a persistent socket connection with the device and can listen to whatever the server wants to push.
WhatsApp uses both GCM/FCM as well as their proprietary XMPP server implementation for Push notifications
WhatsApp(and several other Apps) rely upon GCM/FCM(as option 1 - the default) as it is present as a system App on lot of devices and therefore holds a special status where it is very less likely to be killed unlike a normal App.
For devices that do not have play services, your custom socket connection is relied upon. It may be that FCM is preferred over socket when the former is available but those are upto you to manage.
From WhatsApp's latest build(2.19.203):
Notice that the relevant permission for FCM is present.
Suspected socket implementation: https://android.stackexchange.com/questions/43970/how-is-whatsapp-able-to-receive-messages-when-not-in-use
XMPP based Push Notifications
From, https://www.quora.com/Does-WhatsApp-use-GCM-to-exchange-messages
No, whatsapp doesn't use GCM[NOT entirely true]. It uses a modified version of XMPP
called FunXMPP instead. It changes the XML keywords in message frames
to save bandwidth as it's users aka mostly mobile network users,
doesn't have a good internet connection. The replacements can be found
here: mgp25/Chat-API (I am not the author though)
They have even asked for whitelisting of any port(custom) in use by them.
So, WhatsApp does it. Facebook does it. Google does it. A lot of these companies do this. You can do it as well(to an extent) using Ejjaberd, Openfire or some other technology and having a proper client side implementation for the same.
Chinese ROMs
Some chinese ROMs have taken it even further and radically changed the way the memory and processes are managed in Android. As an example, in Oppo if the Application doesn't have Auto Start turned on, it will not let you do anything once your App is killed. No hopes of any experience whatsoever except hoping that the user will open the App again. In these cases, these OEMs have whitelisted WhatsApp, Facebook, Google and other players selectively. So, who suffers?
Us. Period.
When sending your notification you could set the priority-parameter to "high".
From the docs:
By default, messages are sent with normal priority. Normal priority optimizes the client app's battery consumption, and should be used unless immediate delivery is required. For messages with normal priority, the app may receive the message with unspecified delay.
When a message is sent with high priority, it is sent immediately, and the app can wake a sleeping device and open a network connection to your server.
I know this answer comes late, nevertheless if you are still facing this issue (or anyone else) please tell me if it helps.
First of all, I know GCM service and I have questions about it too.
If I want to implement a push service, is this the right way; Server waits for connections, Android client connects server and waits for data all the time. So server can send data anytime. Connection is always open with keep alive messages.
About GCM;
Is GCM uses this logic?
Is GCM works on all Android devices? I mean is it guaranteed that if a device using Android OS, it also supports this Google service?
If GCM is not a guaranteed service on Android, how should I handle the case that there is no GCM support on device. Or is this a negligible case?
Is GCM uses this logic?
Generally yes, though bear in mind that there are a lot more details.
is it guaranteed that if a device using Android OS, it also supports this Google service?
No. It is only going to be on devices that legitimately have the Play Store and the rest of Google's proprietary app suite. It will not be on the Kindle Fire, the OUYA, or other devices that are using Android purely from the open source project.
how should I handle the case that there is no GCM support on device
Amazon has a GCM equivalent for the Kindle Fire series, IIRC.
Beyond that, since GCM is not a guaranteed delivery service, you need a fallback plan even for "normal" Android devices.
For example, let's suppose that you are writing an app to show news headlines to the user. In the absence of any push notification, you poll for new headlines every four hours, or when the user presses a "refresh" button in the UI. With GCM, your server can push down headlines as they arrive, which your app can pick up. This gives users on "normal" devices fresher data, but still covers cases where you miss some GCM messages or for devices that do not support GCM.
Adding to what CommonsWare mentions about GCM, you may want to look at MQTT as another pub/sub mechanism; It works on any device that can run Java. Here is a link where I try to explain how it works.
That links applies to LAN messaging but it works over the internet as well. It is the mechanism that the Facebook chat app uses. On that link you will find another link to a git where I show MQTT in use on a simple home automation project. If you have any questions, I can try to answer them.
I recently learned about the ability of iPhone apps to receive nearly instantaneous notifications to apps notifications to apps.
This is provided in the form of push notifications, a bespoke protocol which keeps an always on data connection to the iPhone and messages binary packets to the app, which pops up alerts incredibly quickly, between 0.5 - 5 seconds from server app send to phone app response time. This is sent as data - rather than SMS - in very very small packets charged as part of the data plan not as incoming messages.
I would like to know if, using Android, there is either a similar facility, or whether it's possible to implement something close to this using Android APIs. To clarify, I define similar as:
Not an SMS message, but some data driven solution
As real time as is possible
Is scalable, i.e., as the server part of a mobile app, I could notify thousands of app instances in seconds
I appreciate the app could be pull based, HTTP request/response style, but ideally I don't want to be polling that heavily just to check for notification; besides which it's like drip draining the data plan.
Firebase Cloud Messaging FCM FAQ is the new version of GCM. It inherits GCM’s core infrastructure to deliver messages reliably on Android, iOS and Chrome. However they'll continue to support GCM because lot of developers are using GCM SDKs today to handle notifications, and client app upgrade takes time.
As of June 26, 2012, Google Cloud Messaging is the preferred way of sending messages to applications running on devices.
Previously (and now deprecated), the service was called Cloud To Device Messaging.
XMPP is a good solution. I have used it for a push enabled, realtime, Android application. XMPP is powerful, highly extensible and easy to integrate and use.
There are loads of free XMPP servers (though out of courtesy you shouldn't abuse them) and there are open source servers you can run on one of your own boxes. OpenFire is an excellent choice.
The library you want isn't Smack as noted above, it's aSmack. But note, this is a build environment - you will have to build the library.
This is a calculation I did on battery life impact of an XMPP solution:
The Android client must maintain a persistent TCP connection by waking up periodically
to send a heartbeat to the XMPP server.
This clearly imposes a cost in terms of power usage. An estimate of this cost is
provided below:
Using a 1400mAh battery (as supplied in the Nexus One and HTC Desire)
An idle device, connected to an 3G network, uses approximately 5mA
The wake-up, heartbeat, sleep cycle occurs every 5 minutes, takes three seconds
to complete and uses 300mA
The cost in battery usage per hour is therefore:
36 seconds 300mA = 3mAh sending heartbeat
3600 seconds 5mA = 5mAh at idle
4:95 + 3 = 7:95mAh combined
A 1400mAh battery lasts approximately 11.6 days at idle and 7.3 days when
running the application, which represents an approximate 37% reduction in
battery life.
However, a reduction in battery life of 37% represents the absolute worst case
in practice given that devices are rarely completely idle.
I recently started playing with MQTT http://mqtt.org for Android as a way of doing what you're asking for (i.e. not SMS but data driven, almost immediate message delivery, scalable, not polling, etc.)
I have a blog post with background information on this in case it's helpful http://dalelane.co.uk/blog/?p=938
(Note: MQTT is an IBM technology, and I should point out that I work for IBM.)
Have a look at the Xtify platform. Looks like this is what they are doing,
Google is depreciating C2DM, but in its place their introducing GCM (Google Cloud Messaging) I dont think theirs any quota and its free! It does require Android 2.2+ though! http://developer.android.com/guide/google/gcm/index.html
If you can depend on the Google libraries being there for you target market, then you may want to piggy back on GTalk functionality (registering a resource on the existing username - the intercepting it the messages as they come in with a BroadcastReceiver).
If not, and I expect you can't, then you're into bundling your own versions of XMPP. This is a pain, but may be made easier if XMPP is bundled separately as a standalone library.
You may also consider PubSubHubub, but I have no idea the network usage of it. I believe it is built atop of XMPP.
I have been looking into this and PubSubHubBub recommended by jamesh is not an option. PubSubHubBub is intended for server to server communications
"I'm behind a NAT. Can I subscribe to a Hub? The hub can't connect to me."
/Anonymous
No, PSHB is a server-to-server
protocol. If you're behind NAT, you're
not really a server. While we've
kicked around ideas for optional PSHB
extensions to do hanging gets ("long
polling") and/or messagebox polling
for such clients, it's not in the core
spec. The core spec is
server-to-server only.
/Brad Fitzpatrick, San Francisco, CA
Source: http://moderator.appspot.com/#15/e=43e1a&t=426ac&f=b0c2d (direct link not possible)
I've come to the conclusion that the simplest method is to use Comet HTTP push. This is both a simple and well understood solution but it can also be re-used for web applications.
There is a new open-source effort to develop a Java library for push notifications on Android, using the Meteor comet server as a backend. You can check it out at the Deacon Project Blog. We need developers, so please spread the word!
Google recently(18May2016) announced that Firebase is now it's unified platform for mobile developers including near real time push notifications.It is also multi-platform :
The company now offers all Firebase users free and unlimited
notifications with support for iOS, Android and the Web.
source
I cannot find where I read it at, but I believe gmail utilizes an open TCP connection to do the e-mail push.
As GTalk is gone from the SDK, it might be a good idea to make a 'standard' push messaging system. That way, only one service has to run, only one extra tcp connection needs to be open. Applications should talk to this service using Intents and should first request permission to send and receive notification from the service. The service should then notify the user a new application wants to send and receive messages. The user will then grant or deny permission, so he stays in control. The application will then register an action + category to the service, so the service knows how to deliver the pushed message.
Would the a good idea or not?
Why dont you go with the XMPP implementation. right now there are so many public servers available including gtalk, jabber, citadel etc. For Android there is one SDK is also available named as SMACK. This we cant say a push notification but using the XMPP you can keep a connection open between client and server which will allow a two way communication. Means Android client and server both can communicate to each other. At present this will fulfill the need of Push in android. I have implemented a sample code and it really works great
I have recently developed http://pushdroid.org its a single application that should be installed on the phone just like google has implemented it in 2.2 this works from 1.5 and is broadcasting via intent.
The problem with GCM is that there is a lot of configuration involved in the process:
You have to add a lot of boilerplate to you Android app
You need to configure an external server to comunicate with the GCM server
You will have to write tests
If you like simple things (like me) you should try UrbanAirship. It is (IMHO) the easiest way to use GCM in your app without doing a lot of configuration. It also gives you a pretty GUI to test that your GCM messages are being delivered correctly.
You can find the docs and getting started guide here
You can find a sample application here
Note: I am not afiliated with UrbanAirship in any way
https://github.com/Guti/Google-Cloud-Messaging--Titanium-/blob/master/src/com/google/android/gcm/GCMRegistrar.java
Its reaily good and working solution for push.
Please try it
They have their listeners which has to be used by you by using their library classes in your code. You need not to bother about pushing. You have to send the message to server server will push the message to the device. They use OAuth. Regarding Protocols, there are two methods using CCS and XMPP. CCS just uses XMPP as an authenticated transport layer, so you can use most XMPP libraries to manage the connection. To send notifications to device you can write code in android app to send as well as your server code. the message sending will be done only by your code. Rest will be taken care by Google Server in GCM case. You can check detail at this link
http://developer.android.com/google/gcm/server.html
Also, for security issues
google cloud messaging security https://groups.google.com/forum/#!topic/android-gcm/M-EevBitbhQ
In case your app is not running then also devices can recieve notification because you have to write code for broadcast listeners. In background it will be listening to server and whenever any message packet will be there it will recieve the message as notification. Android has service you need to not to bother about it. You have only to use those resources using the library class that makes your work easier and let them write if your app is not running then also it recieve notification. Obviously, there would be some listener whick make the app to recieve.Check "Recieve the message" section in this link
http://developer.android.com/google/gcm/client.html
It will acccept request from users also. For GCM it will do. Please check "Send a message"
http://developer.android.com/google/gcm/client.html