android - "Exported receiver does not require permission" on receivers meant to receive from system services

42,493

Solution 1

Why don't I get the warning on all receivers ?

Because the first two are clearly designed to be broadcast by Android. The last one is unknown, partly because you did not supply the string resource values, and possibly because they are your own unique action strings.

What permissions do I need to set for receivers meant to receive from system services to correct the warning

The correct solution is to delete the <intent-filter>. If you are broadcasting these Intents, or if you are wrapping an Intent in a getBroadcast() PendingIntent, you do not need action strings. Use the Intent constructor that takes the Java class object as the second parameter, and use that:

new Intent(this, BatteryMonitoringReceiver.class)

You are welcome to still attach an action string to that Intent, if you want, but you can dump the <intent-filter> (routing will be based on the supplied component, in this case the Java class).

Only use an <intent-filter> when you are expecting the OS or third-party apps to initiate the Intent themselves (executing a PendingIntent that you created does not count).

Solution 2

The warning "Exported receiver does not require permission" means, You have an intent-filter with some action (which means by default you have android:exported="true" set and it can now receive broadcasts from ANY broadcasters outside of your application) Since it can receive broadcasts from ANY broadcasters outside of your application, it warns you by saying "Hey, are you sure ANY broadcaster can invoke you? In my opinion, it is better if you allow only those broadcasters to invoke you that has the permission you have set for this receiver through android:permission"

You can remove this warning by adding android:exported="false" to the receiver tag

Solution 3

If you do want to export your receiver to other processes, you can add your own permission definition in your android-manifest file for avoiding this warning, like

<permission
    android:name="com.yourpage.permission.YOUR_PERMISSION"
    android:protectionLevel="normal" />

<uses-permission
    android:name="com.yourpage.permission.YOUR_PERMISSION" />

<receiver <!-- warning : Exported receiver does not require permission-->
    android:name=".receivers.BatteryMonitoringReceiver"
    android:permission="com.yourpage.permission.YOUR_PERMISSION"
    android:enabled="false" >
    <intent-filter>
        <action android:name="@string/intent_action_setup_alarm" />
        <action android:name="@string/intent_action_cancel_alarm" />
        <action android:name="@string/intent_action_monitor" />
    </intent-filter>
</receiver> 

for more information, you can refer to http://developer.android.com/training/articles/security-tips.html

Solution 4

If, like me, you are here because your app built with a previous SDK version stopped working with more recent versions and you would like to fix it with minimal change, just add

android:exported=false

to the receiver tag in the manifest file. The solution by CommonsWare is obviously the one to go with for the long term but this fixes the issue temporarily if you are using custom intents and don't mean to export them.

Going by Lubo's way, you would need to export this custom permission, which would prompt the user before installation. That means the descriptive text for the permission needs to be well written so you don't end up scaring the user into changing his mind about installing the app. Also, it would need to be translated into all your target languages.

Solution 5

To hide this warning, add tools:ignore="ExportedReceiver" to the receiver:

<receiver
    android:name=".MyReceiverIndentedForOtherAppsWithoutPermissions"
    tools:ignore="ExportedReceiver">
    <intent-filter>
        <action android:name="com.my.app.CUSTOM_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</receiver>
Share:
42,493

Related videos on Youtube

Mr_and_Mrs_D
Author by

Mr_and_Mrs_D

Be warned - the Monster isAlife Git, Java, Android and finally Python I was flirting with JEE since a couple years but since 1/2014 we are having an affair I spent the best part of the last year refactoring a widely used mod manager application. Here is the commit message of the release I have been working on, where I detail what I have been doing: https://github.com/wrye-bash/wrye-bash/commit/1cd839fadbf4b7338b1c12457f601066b39d1929 I am interested in code quality and performance (aka in the code as opposed to what the code does) If you find my posts useful you can buy me a coffee TCP walks into a bar &amp; says: “I’d like a beer.” “You’d like a beer?” “Yes, a beer.”

Updated on July 05, 2022

Comments

  • Mr_and_Mrs_D
    Mr_and_Mrs_D almost 2 years

    I have some receivers declared in my AndroidManifest :

    <!-- no warning -->
    <receiver
        android:name=".receivers.TriggerMonitoringBootReceiver"
        android:enabled="false">
        <intent-filter>
            <action android:name="android.intent.action.BOOT_COMPLETED" />
        </intent-filter>
    </receiver>
    
    <!-- no warning -->
    <receiver
        android:name=".receivers.ScanResultsReceiver"
        android:enabled="false">
        <intent-filter>
            <action android:name="android.net.wifi.SCAN_RESULTS" />
        </intent-filter>
    </receiver>
    
    <!-- warning : Exported receiver does not require permission-->
    <receiver
        android:name=".receivers.BatteryMonitoringReceiver"
        android:enabled="false">
        <intent-filter>
            <action android:name="@string/intent_action_setup_alarm" />
            <action android:name="@string/intent_action_cancel_alarm" />
            <action android:name="@string/intent_action_monitor" />
        </intent-filter>
    </receiver>
    

    The first one is meant to receive a BOOT_COMPLETED action. The second is meant to receive android.net.wifi.SCAN_RESULTS. The third one is meant to receive some actions I broadcast (intent_action_monitor) and some actions broadcasted by the AlarmManager (intent_action_setup_alarm etc).

    Two questions:

    • Why don't I get the warning on all receivers?
    • What permissions do I need to set for receivers meant to receive from system services to correct the warning (I understand what it is about and I don't want anyone to use my receivers anyway) ? Will exported="false" do for boot receivers, wifi receivers, alarm receivers etc?
      I thought of using a custom permission with android:protectionLevel="signatureOrSystem" but the docs advise against both this protection level and custom permissions. So how I should handle this warning ?

    Links to the docs and/or some code will be much appreciated.

  • Mr_and_Mrs_D
    Mr_and_Mrs_D about 11 years
    Oh thanks ! just to be extra clear - "the first two are clearly designed to be broadcast by Android" I thought so but they are still exported aren't they ? - so if I delete the intents there is still a way someone can use the receivers - will adding exported="false" make any difference ? (Aside: I need the actions but your clarification "Only use an <intent-filter> when you are expecting the OS or third-party apps to initiate the Intent themselves (executing a PendingIntent that you created does not count)." is very very welcome - +1)
  • CommonsWare
    CommonsWare about 11 years
    @Mr_and_Mrs_D: You are not getting a warning on the first two, so my answer is focused on the third one. "I thought so but they are still exported aren't they ?" -- yes. "so if I delete the intents there is still a way someone can use the receivers" -- since you are not getting warnings for those, leave them alone.
  • Yeung
    Yeung over 10 years
    I wonder making custom permission is useful. Just like the Intent's action. I can use decompile tools to extract the manifest.xml and read the Action name. Then the permission name may also face the same thing...
  • markcheeky
    markcheeky over 7 years
    This is a correct solution when you need to declare your own permission. However as official documentation recommends: "Creating a new permission is relatively uncommon for most applications, because the system-defined permissions cover many situations," you should check the system-defined list: developer.android.com/reference/android/…