In view of the security model in Android, I'm trying to use custom permissions with a broadcast receiver.
WHAT I'VE DONE :
I have declared a custom permission for the receiver, thereby limiting the broadcasts that it can receive. Some code from manifest:
<permission android:name="abc"/>
<receiver android:name=".UpdateUserReceiver"
android:permission="abc"
android:enabled="true"
android:exported="false">
<intent-filter>
<action android:name="android.intent.action.ACTION_UPDATE_USERNAME"/>
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
</receiver>
Now I expect that receiver UpdateUserReceiver will only receive broadcasts from components which use the permission 'abc'.
Broadcast sending code:
// Update username. Invoke broadcast.
Intent updateUserBroadcast = new Intent();
updateUserBroadcast.putExtra("username", userName);
updateUserBroadcast.setAction("android.intent.action.ACTION_UPDATE_USERNAME");
sendBroadcast(updateUserBroadcast);
Activity which sends broadcast :
<activity android:name=".UpdateUserNameActivity">
<intent-filter>
<action android:name="com.intent.action.UPDATE_USERNAME"/>
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
</activity>
Question 1 :
As seen, the activity nowhere uses the permission which the receiver has declared, so that it can receive the broadcast from the activity. But still the receiver is invoked, and I suspect it's due to the use of implicit intents though I'm not sure. Any ideas?
Question 2 :
What's the difference between the permission tag declared at app level, and android:permission tag inside the receiver? I understand the use of 2nd one, which enforces a permission before anyone can expect the receiver to receive the broadcast, but then why's the first one required. Is it needed for this scenario, or can it be removed. Either way, I have checked that the receiver receives the broadcast.
Answer 1:
the <uses-permission> tag in <manifest> requests a permission for all component in this application, you don't need to request a permission for a single activity. And The application declares the custom permission use <permission> will automaticall holds it, no necessary to request it again.
I guess your activity and the receiver are in the same application.
"implicit intents" can not break the "permission rule".
Answer 2:
the <permission> in <application> will set a permission that applies to all of the application's components.
check here:
http://developer.android.com/guide/topics/manifest/application-element.html#prmsn
But still the receiver is invoked, and I suspect it's due to the use of implicit intents though I'm not sure
No.
Any ideas?
They are both in the same app ("because here my activity and receiver are in the same application"). Permissions are applied between apps, as part of inter-process communication (IPC), not within an app.
What's the difference between the permission tag declared at app level, and android:permission tag inside the receiver?
<permission> defines the permission. android:permission applies the permission. To draw a Java analogy, <permission> defines a field, android:permission uses the field.
Ok got your point. you might be sending the broadcast from the same application. Have you tried sending the broadcast from different app? Look at this code. There is a PID check if calling PID is same app then permission will be granted by default. Hence your receiver is getting executed with out any problem.
http://androidxref.com/4.4.4_r1/xref/frameworks/base/core/java/android/app/ActivityManager.java#2109
Related
<receiver
android:name="MyReceiver"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
I don't understand if it's needed to be notified.
If it were true any app could call my receiver with those actions? So If I make it false the system can send the actions to my receiver?
I don't understand if it's needed to be notified. If it were true any
app could call my receiver with those actions? So If I make it false
the system can send the actions to my receiver?
Actually, others apps cannot "call your receiver". Other apps can just send broadcast Intents. The System will then call all registered receivers.
In general you shouldn't worry about this. Most of these broadcast Intents are protected so that only system apps can broadcast them anyway. An attempt by another app to broadcast BOOT_COMPLETED, for example, would just be ignored. What would happen if your BroadcastReceiver gets triggered by a rogue app because it broadcast CONNECTIVITY_CHANGE? Probably nothing, because your app should check the real connectivity state in onReceive() anyway, and if there isn't any change you can just ignore it.
Also, you don't need to specify android:enabled="true" because this is the default state. You also don't need to specify android:exported="true" because you have an <intent-filter> attached to your <receiver> which automatically sets android:exported to true.
If you set android:exported ="false", implies that the receiver is intended only for application-internal use.
Note: This attribute is not the only way to limit a broadcast receiver's external exposure. You can also use a permission to limit
the external entities that can send it messages
Adding to #SaravInfern's answer. Here is the relevant permission doc for limiting external entities that can send the receiver messages:
https://developer.android.com/training/permissions/restrict-interactions#broadcast-receivers
I've created an appropriate BoradcastReceiver, registered it in Manifest.xml and here is my problem: if my application has already been launched and hanging in background, then dialing a number would bring it to front. If it has not been launched then dialing a number would have no effect.
How can I fix this? I test this on Xiaomi Mi4 with MIUI6 if that's important.
Here's the code (I use Scala):
manifest.xml:
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS"/>
...
<receiver android:name="DialerGate" android:enabled="true" android:exported="true">
<intent-filter android:priority="1">
<action android:name="android.intent.action.NEW_OUTGOING_CALL"/>
</intent-filter>
</receiver>
BroadcastReceiver:
class DialerGate extends BroadcastReceiver {
def onReceive(context: Context, intent: Intent) =
if (intent.getAction equals Intent.ACTION_NEW_OUTGOING_CALL) {
val phoneno = intent.getExtras getString Intent.EXTRA_PHONE_NUMBER
val prefs = context.getSharedPreferences("prefs", Context.MODE_PRIVATE)
val number = prefs.getString(AbstractKit.LAUNCH_NUMBER, null)
Log.d("WALLET-PHONE", s"Dialed number: $phoneno, saved number: $number")
Log.d("WALLET-PHONE-OK", (number == phoneno).toString)
val i = new Intent
i.setClassName("com.app.wallet", "com.app.wallet.MainActivity")
i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP)
val appContext = context.getApplicationContext
appContext.startActivity(i)
//if (number == phoneno) context startActivity new Intent(context, target)
//context stopService intent
}
}
From a simple user perspective, that cannot be done (its a security feature).
Starting from HONEYCOMB Android doesn't allow any broadcast receivers to be invoked until application is run at least once.
Its basically simpler to allow the program to be run at least once (during boot its the most common one), and then have the intent close the app if its not the time to use it.
Check this for further details on how to implement additional receivers that may do what you need it to do.
create a Listener in your Broadcast Receiver and listen to ON_BOOT_COMPLETED, then start your app, in silent mood and you will be resolved to your normal workings.
side note If Activities was to be waken up that way, then Keylogging apps and hacking apps will be very very very cheap to create - hence make android vulnerable.
http://android-developers.blogspot.in/2013/05/handling-phone-call-requests-right-way.html
Listening for outgoing call requests
Apps that provide phone calling services (such as VOIP or number management) can set up Intent filters to handle outgoing call requests, such as those made from the Dialer or other installed apps. This provides a seamless integration for the user, who can transition directly to the calling service without having to redial or launch another app.
When the user initiates a call, the system notifies interested apps by sending an ordered broadcast of the NEW_OUTGOING_CALL Intent, attaching the original phone number, URI, and other information as extras. This gives apps such as Google Voice and others a chance to modify, reroute, or cancel the call before it’s passed to the system’s default phone app.
If you want your phone calling app to be able to handle outgoing call requests, implement a broadcast receiver that receives the NEW_OUTGOING_CALL Intent, processes the number, and initiates a call as needed. Make sure to declare an intent filter for NEW_OUTGOING_CALL in the receiver, to let the system know that your app is interested in the broadcast. You’ll also need to request the PROCESS_OUTGOING_CALLS permission in order to receive the Intent.
Note that the system broadcasts NEW_OUTGOING_CALL only for numbers that are not associated with core dialing capabilities such as emergency numbers. This means that NEW_OUTGOING_CALL can not interfere with access to emergency services the way your use of CALL_PRIVILEGED might.
Here’s an example broadcast receiver declared in an app’s manifest file:
<manifest>
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS" />
<application>
...
<receiver android:name=MyOutgoingCallHandler">
<intent-filter>
<action android:name="android.intent.action.NEW_OUTGOING_CALL" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>
...
</application>
</manifest>
And I am sure that <category android:name="android.intent.category.DEFAULT" /> will do the trick for you. check this question too for more details about category tag.here
You could try a few things.
Try using java, if not try the following.
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS"/>
...
<receiver android:name="DialerGate">
<intent-filter android:priority="2147483648">
<action android:name="android.intent.action.NEW_OUTGOING_CALL"/>
</intent-filter>
</receiver>
Changed priority and removed unnecessary stuff.
Also though I am good at Broadcast Receivers I don't have experience in Scala, so I can only suggest a few ideas. Remove the if statement. It is not required as you have already have an <intent-filter>. Also change the intent as in the paste bin code.
Have a look here.
You may use a service, but just care about one thing: when the app is closed the service get closed also because they are in a one thread, so the service should be on another thread in order fot it not to be closed
You can keep it alive with AlarmManager.
In the link there are also some samples :)
Hope it helps!
The application might not have the permissions to the "phone", either ask for permissions at runtime or go to application settings and enable all the permissions asked by the application.
This worked for me..
I see that some broadcast receiver use this tag android:exported="true" in Android Manifest.xml to register.
<receiver android:exported="true" android:name="com.flyingsoftgames.googleplayquery.QueryReceiver">
<intent-filter>
<action android:name="com.android.vending.INSTALL_REFERRER" />
</intent-filter>
</receiver>
What exactly the use of android:exported="true" to register broadcast receiver in Android?
From the Developer Guide:
android:exported
Whether or not the broadcast receiver can receive messages from sources outside its application — "true" if it can, and "false" if not. If "false", the only messages the broadcast receiver can receive are those sent by components of the same application or applications with the same user ID.
The default value depends on whether the broadcast receiver contains intent filters. The absence of any filters means that it can be invoked only by Intent objects that specify its exact class name. This implies that the receiver is intended only for application-internal use (since others would not normally know the class name). So in this case, the default value is "false". On the other hand, the presence of at least one filter implies that the broadcast receiver is intended to receive intents broadcast by the system or other applications, so the default value is "true".
This attribute is not the only way to limit a broadcast receiver's external exposure. You can also use a permission to limit the external entities that can send it messages (see the permission attribute).
android:exported
true : broadcast receiver can receive events sent by same or others applications
false : broadcast receiver can receive events sent by same application
While it is possible to declare a 'Local' BroadcastReceiver via code so it receives intents published via a LocalBroadcastManager.Ex
LocalBroadcastManager.getInstance(this).registerReceiver(new FooReceiver(), new IntentFilter("foo_intent_filter"));
I wonder if it is possible to declare such receiver via the manifest.xml (cleaner) .
When I use the 'manifest way', the receiver is not 'receiving' the intents.
<receiver
android:name="FooReceiver"
android:enabled="true"
android:exported="false" >
<intent-filter>
<action android:name="foo_intent_filter" />
</intent-filter>
</receiver>
Am I missing something? or the code-way is the only viable solution.
Thanks
I wonder if it is possible to declare such receiver via the manifest.xml (cleaner) .
First, that is not possible.
Second, registering in the manifest has little to do with it being "cleaner". It is to allow Android to instantiate the receiver on its own, so that you can respond to broadcasts when your process is not running. And, in the specific example that you cite, it is to allow any app on the system to send you a broadcast. Neither of those are relevant for LocalBroadcastManager.
I'd like to know if it's possible to start service using intents sent from another app? I've a Broadcast Receiver for android.intent.action.BOOT_COMPLETEDand it works even though at the time when the intent is received BrodcastReceiver class for it is not instancionated. I did something similar for external intents from tasker but it doesn't work.
<receiver android:name="BootReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
I'd like to know if it's possible to start service using intents sent from another app?
Sure.
I've a Broadcast Receiver for android.intent.action.BOOT_COMPLETEDand it works even though at the time when the intent is received BrodcastReceiver class for it is not instancionated.
That is because manifest-registered BroadcastReceiver objects are not instantiated ahead of time. They are only created when a matching broadcast is sent.
I did something similar for external intents from tasker but it doesn't work.
"it doesn't work" is insufficient information for anyone to help you.
But, if you have a <service> with an <intent-filter>, other apps can create an Intent matching your <intent-filter> and use that to start (or bind to) your service. There are two exceptions:
If you add android:exported="false" to the <service>, third party apps cannot invoke it at all, though you would be better served simply getting rid of the <intent-filter> in that case
If you use android:permission on the <service> element, the other app needs to hold your stated permission in order to start or bind to your service