I have a semi-successful app on the market that uses broadcast receivers for a few of its features. As a request from many of the users, I have successfully excluded a few activities from the "Recent Applications List" by adding this line to the activities in the manifest:
android:excludeFromRecents="true"
I am trying to do the same thing with my broadcast receiver. I have tried adding that line to my receiver and all of the dependant activities to no avail. What can I do to "hide" the broadcast receiver from the user? Is this supposed to work, or is there an alternative?
Also, how do I stop the app from showing in the task manager (running application list) when a broadcast is received? There are quite a few apps on my phone (my app included) that show up in my 3rd party task manager that do not show as running applications in the default settings->apps->running list. Can somebody please explain why this is the case, and what I can possibly do to keep it off the task manager list as well (without knowing how the each individual task manager searches for apps)?
Thanks!
NOTE: I use the word "hide" apprehensively. It is basically to de-clutter the recent applications list as requested by the users. No ill intents :D.
When you receive the broadcast start/launch the new activity/service with FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS. It's hard to tell without the source code, but you may also want to add FLAG_ACTIVITY_NO_HISTORY.
Related
I have been trying to do something similar to truecaller app, where my app is supposed to show a screen after a call gets hung up. Was achieving this by registering android.intent.action.PHONE_STATE implicit broadcast in the manifest file.
But it is not working if I change the app to target Android O, because of the Android O broadcast limitation, and I'm trying to figure out an alternative solution to this use case.
Alternative solutions suggested in android docs: Job scheduler or register a service with context.
Job scheduler: Because of the Job scheduler optimizations there will be some delay to receive the callback. So it will affect the user experience if our app screen is shown a few min after the phone call and polling to check for new call logs every few seconds causes battery drain issue.
Register service with context in Java: I want the behavior to work even if the app is not active or alive. This will not work if the system kills the Service.
Register a Foreground Service: This requires a notification to be shown to the user all the time, which would be spam the user, and running a service 24/7 consumes lots of resources which defeats the whole purpose of broadcast limitation.
Please suggest an alternate solution so that the user experience remains the same.
Thanks in advance
Eventually, the action was added to the "Implicit Broadcast Exceptions" list so you can add ACTION_PHONE_STATE_CHANGED to your manifest and it will work:
https://developer.android.com/guide/components/broadcast-exceptions
ACTION_CARRIER_CONFIG_CHANGED,
TelephonyIntents.ACTION_*_SUBSCRIPTION_CHANGED,
"TelephonyIntents.SECRET_CODE_ACTION", ACTION_PHONE_STATE_CHANGED,
ACTION_PHONE_ACCOUNT_REGISTERED, ACTION_PHONE_ACCOUNT_UNREGISTERED
OEM
telephony apps may need to receive these broadcasts.
You have only one solution, use a foreground service and register the broadcast receiver in the service.
As there is NO proper solution to read the PHONE_STATE from Android O. The best alternative we can go for is to trigger a job on new call log entry from the content provider. By this, the behaviour is maintained of showing a screen(with a few sec of delay) after the call ends.
NOTE : The disadvantage is we cannot get the state of the phone call(Ringing or off_the_hook etc.,). The call back will only be received after the new call log has been added to the System DB.
For me, and my production app, the solution would be to avoid targeting api 25 and above, until a better workaround/api comes up.
If your app targets level 24 or below, you're not affected by the new Implicit Broadcast Limitations and your app can still listen to PHONE_STATE broadcasts even when your app is not running.
An app targeting lower APIs can still be downloaded and installed normally on new Android versions, the only reason to update your sdkTarget value is if your app requires usage of new APIs.
There seems to be an broadcast exception for ACTION_NEW_OUTGOING_CALL but not one for incoming call (or when call ends). It seems like a bug to have one for outgoing but not one for incoming. There's been a bug report filed in google issue tracker. Hopefully their answer will clarify what we should be doing.
I'll update this answer if/when the bug tracker gets updated.
As mentioned here: https://issuetracker.google.com/37273064#comment4, ACTION_PHONE_STATE_CHANGED (android.intent.action.PHONE_STATE) will be whitelisted for the Android O release. Though they may be replaced with a different mechanism in a future release.
I'm new to android and trying to build a simple app which needs to listen for incoming sms. I know that I need to use the BroadcastReceiver class and I also know how to make my own broadcast receiver. But how do I start it? Does it start automatically if I set the code for it in the manifest? The app just has the Main activity, do I need to somehow add a broadcast receiver in the onCreate of this activity? I searched for an answer, but it's still not clear to me. I know it's not nice to ask, but it would be great if you can share some sample code. Thanks!
If you declare the receiver within your AndroidManifest.xml, then you shouldn't need to do anything more. When a broadcast gets sent, the Android system will look through all installed apps and notify each app that has declared the appropriate Receiver in its manifest, starting the app in the process if necessary. For most cases, such as SMS, that is how you want to declare receivers, because most broadcasts are sent with the intent that you want to open your app when its not currently running to react to the broadcast.
Alternatively, you may declare the broadcast within a running activity, which may be useful if you want the broadcast to directly update the UI in your running app.
BroadcastReceiver Documentation
Well, there are lot of threads on this topic but all are before the release of android 3.1.
Now broadcast receivers will not work until user manually launches the application, i.e for broadcast receivers to work, the application should be in running state not stopped. There are certain questions in my mind right now, specially about BOOT_COMPLETED receiver.
Why would they still want to have BOOT_COMPLETED and won't let application use it? I mean there seem to be no point in having it. When system boots, apps are in stopped state and no app will receive this event if I'm not mistaking.
And on the developer page I read this:
"The platform defines two new intent flags that let a sender specify whether the Intent should be allowed to activate components in stopped application.
1:FLAG_INCLUDE_STOPPED_PACKAGES — Include intent filters of stopped applications in the list of potential targets to resolve against.
2:FLAG_EXCLUDE_STOPPED_PACKAGES — Exclude intent filters of stopped applications from the list of potential targets"
Can someone please explain the meaning of it. Can I still receive broadcasts when my app is in stopped state? And how can I register such receivers in manifest.xml ? I know these flags are added in the code but can I do similar in the manifest.xml?
Apps are in the stopped state if and only if they have never been manually launched by the user. It the user has launched the app at least once, the app can register for an receive BOOT_COMPLETE messages at startup.
Hi I am working with android.Firstly I am not familiar with broadcast receiver. I need to create an app in which, if anyone installed my app a broadcast receiver will run which check the installation status like ACTION_PACKAGE_INSTALL and android.intent.action.PACKAGE_REMOVED
.But How can i get these status even my app is closed ?? Is it possible with broadcast receiver ?? Please help me, thanks in advance :)
basically, BroadcastReceiver can receives broadcasts even if your app is not in foreground, or even if your application's process is not alive.
this can be done by declaring the receiver within your application's Manifest.xml file
when you declare a receiver in the Manifest file - then the system would wake up your application and invoke your receiver if it set with the appropriate intent filter that responding to the broadcast that been sent (in your case - ACTION_PACKAGE_INSTALL and PACKAGE_REMOVED actions..)
but unfortunately there are also bad news for you:
from Android ICS and above - you cannot receive any broadcasts until you application launched explicitly by the user at least once!
this is due to security reasons Google decided is necessary, to prevent from malicious apps doing staff entirely transparent without the user launched them at all even once..
so the answer basically is - no! you can't perform any code and receive any events from your app until it launched at least once.
by the way - you wouldn't received ACTION_PACKAGE_INSTALL and PACKAGE_REMOVED broadcasts for your own app that been installed or uninstalled anyway.
by reading your question again, honestly I'm not sure what is that you expects to happend:
it is no make any sense to "check your application installed status" if it unistalled or not. after all - if it uninstalled - then it can't run (and perform any code) anyway.
The app has a BroadcastReceiver that listens for a boot-complete event and starts a background service to send some data to my HTTP server.
My question is, if the app is never run by the user (only installed), will the BroadcastReceiver receive the boot event?
Starting with android 3.1 user has to launch the application once for it to receive the boot_complete broadcast..
Following is from the official javadoc:
Starting from Android 3.1, the system's package manager keeps track of
applications that are in a stopped state and provides a means of
controlling their launch from background processes and other
applications.
Note that an application's stopped state is not the same as an
Activity's stopped state. The system manages those two stopped states
separately.
The platform defines two new intent flags that let a sender specify
whether the Intent should be allowed to activate components in stopped
application.
FLAG_INCLUDE_STOPPED_PACKAGES — Include intent filters of stopped
applications in the list of potential targets to resolve against.
FLAG_EXCLUDE_STOPPED_PACKAGES — Exclude intent filters of stopped
applications from the list of potential targets. When neither or both
of these flags is defined in an intent, the default behavior is to
include filters of stopped applications in the list of potential
targets.
Note that the system adds FLAG_EXCLUDE_STOPPED_PACKAGES to all
broadcast intents. It does this to prevent broadcasts from background
services from inadvertently or unnecessarily launching components of
stoppped applications. A background service or application can
override this behavior by adding the FLAG_INCLUDE_STOPPED_PACKAGES
flag to broadcast intents that should be allowed to activate stopped
applications.
Applications are in a stopped state when they are first installed but
are not yet launched and when they are manually stopped by the user
(in Manage Applications).
javadoc link
Check out this blog for more detail
Yes, the Boot receiver is registered to listen to the boot so if you reboot your device it will fire, regardless of whether you started the app or not. Similarly, if you add NFC listeners to your manifest, then if someone swipes an NFC card the app will react. The Manifest is used by Android to react to whatever you've specified in it. It's not contingent on whether the app is running (or has ever run).
Excellent question though! :)
EDIT as per the other answers and the documentation. This is not true anymore. Sorry for the confusion.