This is not how you should register a receiver. You receiver stops working, because you construct it in onCreate, which means it will live as long as your app is alive. When the app gets destroyed, you also lose the the receiver. If you register receiver inside an activity, you should always register it in … Read more
There are a couple of things you can try which, when used in concert, should be able to cut through all of the idle/standby/doze modes (irrespective of OS version). 1. Use a WakefulBroadcastReceiver instead of an ordinary BroadcastReceiver. Make sure you include the WAKE_LOCK permission to use it correctly. 2. Use the setExactAndAllowWhileIdle() method (on … Read more
You can use Interface for it so main objective of Fragment re-usability is maintained. You can implement communication between Activity-Fragment OR Fragment-Fragment via using following :
Here is code from 4.0.3_r1 in frameworks/base/services/java/android/server/AlarmManagerService.java. First, we create a PendingIntent mDateChangeSender; private final PendingIntent mDateChangeSender; Then, in the constructor of AlarmManagerService.java, we setup the PendingIntent: Intent intent = new Intent(Intent.ACTION_DATE_CHANGED); intent.addFlags(Intent.FLAG_RECEIVER_REPLACE_PENDING); mDateChangeSender = PendingIntent.getBroadcast(context, 0, intent, 0); Then later in the constructor: mClockReceiver.scheduleDateChangedEvent(); So what is mClockReceiver? Just a BroadcastReceiver listening for Intent.ACTION_TIME_TICK … Read more
You need to set a custom intent action, not the AudioPlayerBroadcastReceiver component class. Create a Intent with custom action name like this Intent switchIntent = new Intent(“com.example.app.ACTION_PLAY”); Then, register the PendingIntent Broadcast receiver PendingIntent pendingSwitchIntent = PendingIntent.getBroadcast(this, 100, switchIntent, 0); Then, set a onClick for the play control , do similar custom action for other … Read more
It seems that google is trying to prevent this from KITKAT. Looking at core/rest/AndroidManifest.xml you will notice that broadcast android.intent.action.MEDIA_MOUNTED is protected now. Which means it is a broadcast that only the system can send. <protected-broadcast android:name=”android.intent.action.MEDIA_MOUNTED” /> The following should work for all versions: if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { final Intent scanIntent = new … Read more
There is no API function to check if a receiver is registered. The workaround is to put your code in a try catch block as done below. try { //Register or UnRegister your broadcast receiver here } catch(IllegalArgumentException e) { e.printStackTrace(); }
Here is what the Android SDK says about sendStickyBroadcast(): Perform a sendBroadcast(Intent) that is “sticky,” meaning the Intent you are sending stays around after the broadcast is complete, so that others can quickly retrieve that data through the return value of registerReceiver(BroadcastReceiver, IntentFilter). In all other ways, this behaves the same as sendBroadcast(Intent). One example … Read more
Android has intent action for broadcast receiver. BroadCast receiver will be trigger when it listen any action which registered within it. Now we will take one example : That we need to listen the action of “whenever any bluetooth device connect to our device”. For that android has it fix action android.bluetooth.BluetoothDevice.ACTION_ACL_CONNECTED So you can … Read more
By defining your receiver with android:process=”:remote” you basically run your receiver in a different process (= VM). For typical use-cases, you don’t need to run this in a different process, and whatever you want to do can probably run just fine locally (in your APK process). The drawback of using android:process=”:remote” is that you need … Read more