[Bug] [Crashlytics][Messaging] DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION causes "incorrectly registered broadcast receiver: error

[AsafWhalo]

Description

Good day,

Upon uploading our game to the google play store we received this error in the dashboard

I eventually found that the issue is connected to these 2 additions to the AndroidManifest.xml :

<permission android:name="com.DefaultCompany.TestingSite.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION" android:protectionLevel="signature"/> <uses-permission android:name="com.DefaultCompany.TestingSite.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION"/>

which from what I understand is a cause of a unhandled broadcast receiver.

I have made a side project where I would build a APK after each 3rd party SDK we have in our main project, and would then unpack the APK and check the AndroidManifest.xml each time.

I found that when I added Firebase Crashlytics and Firebase Messaging unitypackage to the project, it would generate those permissions in the last AndroidManifest.xml

Reproducing the issue

1. Create new project in Unity

2. Set project as IL2CPP, and:
   

3. Add Crashlytics or Messaging unitypackage to the project

4. Just in case - run External dependency resolver

5. Build Project as Android, wait for APK

6. using apktool https://formulae.brew.sh/formula/apktool you can unpack APK

7. See last AndroidManifest.xml and search for DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION

Firebase Unity SDK Version

12.0.1

Unity editor version

2022.3.27f1

Installation Method

.unitypackage

Problematic Firebase Component(s)

Crashlytics, Messaging

Other Firebase Component(s) in use

Analytics, Crashlytics, Messaging

Additional SDKs you are using

Facebook, IronSource

Targeted Platform(s)

Android

Unity editor platform

Mac

Scripting Runtime

IL2CPP

Release Distribution Type

Pre-built SDK from https://firebase.google.com/download/unity

Relevant Log Output

No response

If using CocoaPods for Apple platforms, the project's Podfile.lock

No response

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Hey @AsafWhalo, thanks for reaching out. After doing a bit of digging, looks like DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION isn't exactly the culprit of the issue. According to an explanation from the F-Droid project:

Before API 33, registerReceiver() took the name of a signature-level permission to gate whether intents could be sent to dynamically registered broadcast intent receivers. If no permission was specified, it was exported to the world.

In API 33, registerReceiver()'s flag argument gained explicit RECEIVER_EXPORTED and RECEIVER_NOT_EXPORTED controls. The use of RECEIVER_NOT_EXPORTED with no specified signature-level permissions means that the application intends to only send intents to itself, and reject them from elsewhere.

In order to emulate API 33's RECEIVER_NOT_EXPORTED flag on older APIs, androidx's ContextCompat makes use of the fact that a signature-level permission that no other app uses amounts to the same thing as being not exported. So, AAPT merges into the manifest:

<permission android:name="${applicationId}.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION"
    android:protectionLevel="signature" />
<uses-permission android:name="${applicationId}.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION"/>

And then, on the older APIs, passes "${applicationId}.DYNAMIC_RECEIVER_ NOT_EXPORTED_PERMISSION" to registerReceiver()'s permission argument when RECEIVER_NOT_EXPORTED is specified.

Meaning, adding libraries such as androidx.work:2.9.0, or androidx.core:core:1.9.0 will automatically include this permission. And since the Firebase SDKs normally use these or higher versions of those libraries, it will most definitely include the DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION permissions. I tried creating an empty native android app, and it seems to include this permission in the merged manifest.

That said, I'm wondering if there's any receivers that might've been incorrectly setup (e.g. having no export flag in the AndroidManifest.xml). Could you share me your merged manifest file, so I can check if there's anything unusual? Thanks!

[AsafWhalo]

Hey there, sorry was a busy few days

That sounds interesting, but it is from what I gathered just don't know then the source that generates this

I am adding the AndroidManifest after a apk build, and also a exported merger log (had to make it a txt to upload)
AndroidManifest.txt
manifest-merger-release-report.txt
mainTemplate.txt