[ad_1]
Earlier than Android 13, when an app registered an exported element in its manifest and added an <intent-filter>, the element could possibly be began by any specific intent — even these that don’t match the intent filter. In some circumstances this may enable different apps to set off internal-only performance.
This habits has been up to date in Android 13. Now intents that specify actions and originate from exterior apps are delivered to an exported element if and provided that the intent matches its declared <intent-filter> parts.
In present Android variations, there are two methods to ship an intent to a element (reminiscent of an <exercise>) the place the intent doesn’t match the element’s declared <intent-filter> parts:
- Express intents: intents with a element identify set will at all times be delivered to the element, so long as the sender has permission.
- Intent selectors: when setting an identical intent as a selector of the primary intent, the primary intent will at all times be delivered.
Builders anticipated that intent-filters would influence all intents reasonably than only a subset. In reality we’ve seen plenty of confusion round intent-filters.
For every of the next questions, you might be offered with the next:
- The creation of an intent object, which is handed to startActivity() or sendBroadcast().
- An <intent-filter> component.
Your job is to reply the query: Will the intent match the intent filter?
First, the intent:
And the intent filter:
No!
If an intent doesn’t include any classes, Android will deal with it as if CATEGORY_DEFAULT to all implicit intents handed to startActivity() and startActivityForResult(). Notice, this habits is outlined if and provided that that intent is used to launch an exercise. Intent filters should embrace CATEGORY_DEFAULT to be able to obtain implicit exercise intents (documentation). Notice that this solely applies when beginning an exercise. They don’t apply to launching companies or sending broadcasts.
To accurately match this instance the intent filter must be carried out as follows:
How about one other one?
Intent:
Filter:
No once more!
An intent filter should specify a <information> component to simply accept intents with information (documentation). To match it ought to appear to be this:
Up to now yr we discovered one explicit pitfall that we predict we can assist with, making intent filters work in a extra intuitive method.
Let’s have a look at it for instance:
Intent:
Filter:
In present Android variations, sure — the intent does match the filter! It’s because specific intents don’t have to match declared intent filters. When an app declares an exported element in its manifest and provides an <intent-filter>, the element may be began by any intent — even these that don’t match the intent filter! This might have brought on vulnerabilities in lots of apps.
Right here is an instance we’ve found within the wild:
Code of sufferer app:
Elements declared in sufferer’s manifest:
The motion com.instance.PRIVATE_INTERNAL_ACTION will not be speculated to be accessible exterior of the appliance, because the receiver that handles it (InternalReceiver) will not be exported. Nevertheless, on account of the truth that ExternalReceiver doesn’t examine and guard the incoming motion, a malicious actor can do the next to set off inside performance:
For apps that focus on Android 13+ this has now modified. The subsequent part describes these modifications.
Beginning for apps concentrating on Android 13+ (the intent receiving facet), all intents originating from exterior apps are delivered to an exported element if and provided that the intent matches its declared <intent-filter> parts.
One huge caveat: If an intent doesn’t specify an motion, it passes the intent matching take a look at so long as the filter incorporates at the very least one motion. Which means it’s best to at all times deal with the case if the incoming intent doesn’t have an motion (when intent.getAction() returns null)!
Non-matching intents are blocked. Conditions the place intent matching will not be enforced embrace the next:
- Intents delivered to parts that don’t declare any intent filters
- Intents originating throughout the similar app
- Intents originating from the system and from root.
Whereas this modification is nice for safety causes — when you had been relying on this habits to make your app work together with one other via specific intents, you might even see habits modifications in your app, even when you don’t replace to focus on Android 13.
With these modifications, the malicious actor in our earlier instance can now not set off inside performance of our sufferer utility on Android 13, assuming the sufferer utility is up to date to focus on Android 13. Nevertheless, it’s nonetheless strongly beneficial to replace all exported parts to examine and solely settle for actions which can be allowed to guard your utility when operating on older Android variations. Our up to date instance shall be like this:
First, we should always be aware, the enforcement is simply enabled if the intent receiving app targets Android 13+. It does NOT have an effect on intents delivered to the identical app internally.
If you’re sending specific intents (intents with an specific element identify set) to one other app, make sure that the intent matches the parts’ <intent-filter> parts. The matching logic is precisely the identical as resolving implicit intents.
When making an attempt to start out an exercise with a non-matching specific intent, you’re going to get a right away ActivityNotFoundException with the message:
Unable to search out specific exercise class {element identify}; have you ever declared this exercise in your AndroidManifest.xml, or does your intent not match its declared <intent-filter>?
For broadcast receivers and companies, there isn’t a apparent sign of failure apart from warning logcat messages within the tag “PackageManager”:
Intent doesn’t match element’s intent filter: <intent description>
Entry blocked: <element identify>
Ensure to declare all potential intent filters that your element expects and accepts in AndroidManifest.xml.
Past that, if a element solely expects specific intents, contemplate eradicating all <intent-filter> parts if no filtering is desired. Elements with no intent filters will settle for any specific intent.
This modification is already enabled on Android 13 builds, since Developer Preview 1.
You’ll be able to toggle this modification utilizing the compatibility framework UI in developer choices, or by getting into the next ADB command in a terminal window:
Do not forget that this is applicable to the app receiving the intent; you can not disable the change for intents that your app sends to different apps.
As a result of this modification can have an effect on builders even earlier than they aim 13, it’s vital to analyze this modification and coordinate an replace quickly when you use intents to work together with exterior apps. For extra info, try our docs that describe intents and intent filters.
[ad_2]
Source_link