In a certain situation, I'd like my app to be able to "fake" an incoming SMS on the user's device, as a sort of notification. This would save me money when I'd normally use Twilio to send a text to my users but I know they already have my app. Is there any way to do this? I imagine it would have something to do with Intents and Content Providers but I don't really know where to start.
To clarify:
I'm not new to Android and I do respect all of the normal Notification methods. However, my app will have an opt-in for text messages and I'd like to be able to trigger them for free rather than paying for it. This is for SMS-specific uses and not as a substitute for a normal Notification.
Yes (although I really don't support doing this) it is, in theory possible by creating and broadcasting the proper intent. Specifically, they android.provider.Telephony.SMS_RECEIVED intent will be received by anybody who is listening for SMS messages, including the default SMS application. This will in turn cause the notification to be displayed.
All of that said, I've only ever done this in a custom version of Android from within the system process. I'm really not sure if a generic application can do this (in fact, I kinda doubt it). The other caveat is that you will need to formulate your data into PDU's which represent the binary data format of an SMS message. You can look this up, but it's nontrivial.
A far better approach would be to simply have your application display a notification in the tray, the way well behaved applications are supposed to notify the users of events. Take a look at the Notification class.
If you install the apk named ApiDemos-debug.apk that usually comes installed with your choosen platform for the SDK, you will find an example in
<Api Demos> > App > Notification > IncomingMessage
the complete source for this package is usually under
<SDK root>/samples/android-xx/ApiDemos
Related
I am creating a native social app which includes features such as Direct Messages, Voice and Video Calls etc and I have been trying to find a way to be able to receive data payloads from Firebase Cloud Messaging containing values such that I create a custom notification based on the type values from the data payload eg for VOIP calls I’d like to set a remoteInput action to see if a person declines or accepts a call or for direct messages add a remoteInput action for a quick reply and so far I haven’t had any luck especially with background services not being allowed anymore ever since the release of Android 8.1. So I would like to know if there’s a workaround I’ve been missing or if it’s even possible and if it is how do these popular apps do it. Thank you in advance.
Its same as your mentioned, once after the release of 8.1 apps are now more strict in regarding the background running process. There are actually two insights I had received while developed some projects. 1) More the app is used by the user, the app is sort of whitelisted and can receive more notifications, i.e., the system actually tracks the frequency of app usage. 2) You have the possibility to ignore your app from battery optimization process hence more chance of background process to run.
I read that it is possible to use the Web SDK to build a sender app that would run on Chrome in iOS or Android. Is it possible to make that same app being also the receiver to cast to a web enabled TV? So instead of having multiple apps, I'd only have one PWA?
Same codebase? Yes. Same app? No.
The sender and receiver do very different jobs. It's not a bad idea to write your sender and receiver as part of the same project, or to serve them from the same server, but if make your own receiver app then your receiver needs its own URL. (To publish a receiver app, you tell Google your receiver URL, and then Chromecast devices load that url whenever you cast to them.)
Your sender app is complicated. It's responsible for giving the user controls they can click on and sending those messages to the receiver, but it can have a variety of other responsibilities depending on your application. It might do search and browsing, real-time updates, or notifications, and it might let your users write messages or play games or draw beautiful digital art - anything you want your app to accomplish.
The receiver's job is much simpler: play an audio or video file when the sender tells it to. The receiver also needs to respond to play/pause/stop commands and display basic status info, but this functionality is built in to the Cast receiver library, so you don't have to write any of it yourself. You can add bells and whistles like pop-up notifications or custom css styling, but all user interaction happens through the sender app (or from the Google Home app, which acts as a simple remote control). This limitation means that a lot of your features belong only in your sender app, not in the receiver.
Your receiver app is also limited because it has to run on a tiny Chromecast dongle with limited processing and cooling power. Putting unnecessary code into your receiver app could result in the Chromecast overheating and shutting down.
To keep your code as simple as possible, consider using the default Chromecast receiver. This way, you don't have to write or maintain any receiver code. If you need more control over the receiver's styling or behavior, then build your own, but it doesn't have to be complex. The basic Cast Receiver app is thirteen lines of HTML - that's it. Depending on your requirements, you might add css styling, custom message or event handling, or an autoplay queue, but even with all of these features the sample CastReceiver project is only 636 lines of code. Your receiver definitely doesn't need to be as complex as a Slack or Steam desktop web app.
Take advantage of the project-management wins from sharing a codebase with your sender app, but you must keep your receiver small and lightweight. Use the full js/html/css stack if you need to, but consider writing your receiver as a short HTML document, or even using the default receiver. When you keep your receiver functionality to a minimum, you give your users a reliable and responsive Chromecast experience, while still allowing rich interactive features through the sender app.
I have never developed something in Android before, but now my company has put me on a project which includes android.
My question is this: Is it possible to write an application that runs in the background and waits for triggers (if that is the correct word for it). For instance lets say I want my application to do something as soon as you open your emails or as soon as you get an email. Is there some API that I can use to interact with other applications such as Mail. The application does not have to have any GUI, it will literally just push some information notifications on the mail just received or opened.
I don't require a to technical answer, but rather just yes or no, and indeed yes, where can I get more info on it. Also if it is not possible, is there some workaround to achieve this. I have googled it, but most of the links are how to send an email from your application.
Thanks
EDIT: So it can even be triggered when a notification is received. Then I just want to look at the notification and determine if it is an email?
You could register BroadCastReceiver for the actions that you need to be caught
I’m trying to develop an application to do some manipulation (compression and security matters) on the outgoing Sms regardless of the composer application. The main challenge is that I cannot capture the Sms exactly before being sent. For instance the user compose the message body using Go Sms Pro and when the send button is pressed , right before the sms is actually sent we capture it and do the compression and security matters on .
Any solution or replacement idea appreciated.
Starting with KitKat, the SMS content provider has been opened up (finally): http://developer.android.com/about/versions/android-4.4.html
To make this work with previous versions of android, you could set up a content observer to watch content://sms/, query the appropriate tables in that database, and then do whatever you like to erase the message before it goes out. This is just a thought mind you, but whatever you do will likely involve using this method.
This is not possible, short of via your own custom build of the Android OS. You have no ability to intercept, let alone modify, the calls from an arbitrary app via SmsManager to the OS to send an SMS message.
I've got an idea for an Android Application, however I am unsure if it would work. Essentially what I want to do is "intercept" all text messages sent from any SMS App and make modifications to them.
For example, say I write out the following SMS:
Hi {Name}, how are you today? Can you tell {Boss} I'll be 15 minutes late today.
The onSMSSend function in my application(assuming it is currently running in the background) would then be able to edit the content of the message(Eg. Replacing variables with ones defined in the application), and then send it on to the recipient.
Is Android able to provide this functionality?
No it is not. Android may be able to inform you after an SMS was send. But there is no way to intercept a message that should be sent and apply changes to it on a non rooted phone.
What you could do is to write a new messaging App that allows the user to type a message, choose a number and send the message. Now you have full control over the message that is send but building a replacement for the sms app is a fair amount of work.