You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Warn people when their AndroidManifest.xml file doesn't contain the string android:taskAffinity #144484
We should notice when an AndroidManifest.xml file does not include the string android:taskAffinity and the minSdkVersion is not sufficiently high for it to not matter, and print a warning pointing people to https://developer.android.com/privacy-and-security/risks/strandhogg, something like this:
Warning: this application's AndroidManifest.xml file leaves it vulnerable to the StrandHogg v1 and
StrandHogg v2 Android vulnerabilities.
To mitigate the StrandHogg v1 vulnerability, set "android:taskAffinity" to the empty string in the
<activity> tag. To mitigate the StrandHogg v2 vulnerability, the minSdkVersion should be set to 28
or higher.
For more details, see: https://developer.android.com/privacy-and-security/risks/strandhogg
This warning can be silenced by including the string "android:taskAffinity" somewhere in the app's
AndroidManifest.xml file or by setting the "minSdkVersion" to a sufficiently high value.
@andrewkolos P3 basically means "wontfix", since it's unlikely anyone else will ever get around to it. can you talk more about why this isn't something we want to do?
@christopherfujino does the tools team already have a way for developers to set a "dont warn me about X".
The android team does not wish to parse the many possible manifest xml files but we do already have access to minSdkVersion and can warn but don't really want to warn every user that chooses to have a lower support version.
@christopherfujino does the tools team already have a way for developers to set a "dont warn me about X". The android team does not wish to parse the many possible manifest xml files but we do already have access to minSdkVersion and can warn but don't really want to warn every user that chooses to have a lower support version.
No, but maybe we should? Technically we could add a feature flag for it, but that doesn't feel right.
But a system specifically for ignoring warnings seems like it would be useful.
@christopherfujino does the tools team already have a way for developers to set a "dont warn me about X". The android team does not wish to parse the many possible manifest xml files but we do already have access to minSdkVersion and can warn but don't really want to warn every user that chooses to have a lower support version.
No, but maybe we should? Technically we could add a feature flag for it, but that doesn't feel right.
But a system specifically for ignoring warnings seems like it would be useful.
FWIW if I saw the warning with the wording from the original draft above:
This warning can be silenced by including the string "android:taskAffinity" somewhere in the app's
AndroidManifest.xml file or by setting the "minSdkVersion" to a sufficiently high value.
and I wanted to silence the warning without acting on it, I'd just add a comment with that string in it. Like this:
<!-- We don't set the android:taskAffinity attribute because [blah blah rationale here]. But we mention it in this comment in order to silence a warning from Flutter: https://github.com/flutter/flutter/issues/144484-->
After all, the warning specifically suggests "including the string" with no mention of actually putting it in as an XML attribute of an actual <activity> element, so it's saying that that should work.
Given that, I think it'd be reasonable to go ahead with building this warning without blocking on designing a more general "ignore this warning" system that we're happy with, i.e. #146130.
There are plenty of other potential warnings where "include this string" wouldn't work well as a rule — in particular a key aspect here is that there's that very distinctive string "android:taskAffinity", which will definitely appear if the app is addressing the issue in any normal way and on the other hand is very unlikely to appear by accident. So there's lots of other potential warnings where a system like #146130 would be needed. But I think this warning can do just fine without it.
After all, the warning specifically suggests "including the string" with no mention of actually putting it in as an XML attribute of an actual <activity> element, so it's saying that that should work.
I am not very advanced in that topic, but would it be possible to add the default identifier as String in the template, like proposed here? Otherwise some plugins might not work. Although not sure whether this should be resolved plugin wise or on Flutters end: MaikuB/flutter_appauth#503 (comment)
E.g. android:taskAffinity="${applicationId}"
Activity
Hixie commentedon Mar 8, 2024
@andrewkolos P3 basically means "wontfix", since it's unlikely anyone else will ever get around to it. can you talk more about why this isn't something we want to do?
christopherfujino commentedon Mar 12, 2024
re-assigning to the android team to decide the priority.
reidbaker commentedon Mar 28, 2024
@christopherfujino does the tools team already have a way for developers to set a "dont warn me about X".
The android team does not wish to parse the many possible manifest xml files but we do already have access to minSdkVersion and can warn but don't really want to warn every user that chooses to have a lower support version.
christopherfujino commentedon Apr 1, 2024
No, but maybe we should? Technically we could add a feature flag for it, but that doesn't feel right.
But a system specifically for ignoring warnings seems like it would be useful.
reidbaker commentedon Apr 2, 2024
Filed #146130
For us to talk about this system.
gnprice commentedon Jun 3, 2024
FWIW if I saw the warning with the wording from the original draft above:
and I wanted to silence the warning without acting on it, I'd just add a comment with that string in it. Like this:
After all, the warning specifically suggests "including the string" with no mention of actually putting it in as an XML attribute of an actual
<activity>element, so it's saying that that should work.Given that, I think it'd be reasonable to go ahead with building this warning without blocking on designing a more general "ignore this warning" system that we're happy with, i.e. #146130.
There are plenty of other potential warnings where "include this string" wouldn't work well as a rule — in particular a key aspect here is that there's that very distinctive string "android:taskAffinity", which will definitely appear if the app is addressing the issue in any normal way and on the other hand is very unlikely to appear by accident. So there's lots of other potential warnings where a system like #146130 would be needed. But I think this warning can do just fine without it.
Hixie commentedon Jun 6, 2024
For the record, that was indeed my intent.
Gustl22 commentedon Dec 16, 2025
I am not very advanced in that topic, but would it be possible to add the default identifier as String in the template, like proposed here? Otherwise some plugins might not work. Although not sure whether this should be resolved plugin wise or on Flutters end:
MaikuB/flutter_appauth#503 (comment)
E.g.
android:taskAffinity="${applicationId}"