According to the Android docs Intent extra name must have a package prefix. I've been using Intent extra names without prefixes for a long time and it seems like there is no chance of collision since what really matters is the Intent action being unique. So are the docs just wrong or am I missing something?
The docs for putExtra say:
Add extended data to the intent. The name must include a package prefix, for example the app com.android.contacts would use names like "com.android.contacts.ShowAll".
I believe the Android docs recommend using fully-qualified extras is to handle an uncommon edge case. The edge case is when you are:
Writing an Activity that can be started using a public Intent action such as Intent.ACTION_VIEW
AND
For your own usage you want to be able to pass custom extras to the Activity described above without interfering with another Activity that is doing the exact same thing and might have extras with the same name but different meanings or format
Phew, it all sounds very unlikely. If you aren't handling public Intent actions then it still seems as though there is no need to fully-qualify your extras, but I guess it doesn't hurt to do it all the time if you are the paranoid type.
Intents can be passed on to other apps and the system it self, so courtesy is to use a package namespace.
From the official tutorials:
It's a good practice to define keys for intent extras with your app's
package name as a prefix. This ensures that the keys are unique, in
case your app interacts with other apps.
Unless your app interacts with other apps, or you foresee that it might need to do so in the future, you can safely omit package prefixes in your extras.
Related
Android's intent documentation states that :
action must be in a namespace because Intents are used globally in the system
Does this namespace concept just imply that if I don't use, for e.g., my app's package name as a prefix for a custom action name, then it may conflict with the action name for a different app, so when some app is using intent, it may start the wrong component because of my name conflict. Is there any more detail that needs to be worried about when it comes to namespace in intents ?
Does this namespace concept just imply that if I don't use, for e.g., my app's package name as a prefix for a custom action name, then it may conflict with the action name for a different app, so when some app is using intent, it may start the wrong component because of my name conflict.
More or less.
Is there any more detail that needs to be worried about when it comes to namespace in intents ?
It is unlikely that creating a custom action is the right solution for whatever problem that you are solve. One use case for it is if you are going to try to convince third-party developers to specifically invoke one of your activities, perhaps as part of an SDK that you are creating for such developers. This is well within reason, just unlikely. Another use case would be if you have a suite of apps that you were trying to inter-link at specific spots. This is somewhat more probable, but it becomes a bit of a problem to do well -- by default, any app in the system will be able to start that activity if they so chose, and securing that can get tricky.
Note that you neither want nor need an action string of any sort for activities that are private to your app. That's because you neither want nor need an <intent-filter> for activities that are private to your app. Just use explicit Intents to invoke such activities.
I know that public (named) intents that are registered with the system and can be called from any application and private (anonymous) intents that are used within a single
application. please can anyone give me an example for better understanding.
Thanks in advance
Sorry no time to write a full answer, but you can create custom permissions in order to sign your Intents & BroadcastReceivers.
When you use these custom permissions, only apps that have been signed with the same signing key, and include that custom permission, can see these Intents.
This question might help you:
How to use custom permissions in Android?
#Commonsware explains the issue really well in a recent blog post:
Don't have an Accidental API - The CommonsBlog
The Android documentation does probably the best job of explaining it, here is a relevant snippet:
There are two primary forms of intents you will use.
Explicit Intents have specified a component (via
setComponent(ComponentName) or setClass(Context, Class)), which
provides the exact class to be run. Often these will not include any
other information, simply being a way for an application to launch
various internal activities it has as the user interacts with the
application.
Implicit Intents have not specified a component; instead,
they must include enough information for the system to determine which
of the available components is best to run for that intent. When using
implicit intents, given such an arbitrary intent we need to know what
to do with it.
This is handled by the process of Intent resolution,
which maps an Intent to an Activity, BroadcastReceiver, or Service (or
sometimes two or more activities/receivers) that can handle it.
Explicit intents you use in your activity to start internal activities.
While implicit intents are used often used to launch other activities like when you want to share a link or email something, you send out an implicit intent and let the user decide the email client to use to send the email or to share the link.
There are some instances where you might want to use an implicit intent to run an internal component of your app, because it seems to be more stable.
What's the proper way for other people to reuse my Activities? Should they hard code the intent actions in their app or is it customary to provide them with a jar file enumerating my app's intent actions? Is there a less tightly-coupled way to lookup the intent actions?
First of all, take a look at openintents.org and see if there's any match to what your activity does.
Secondly, documentation is always a good idea.
Having the intent details hardcoded in their applications should work just fine. After all, the intents are part of your public interface and shouldn't change.
Your applications manifest should announce what sorts of things your activity can handle, via intent-filters. Outside users can read the manifest to determine what actions you support, and invoke them via action intents.
See intents and intent filters for more details.
I am interested in activating another application's activity. I know from reading the Android SDK that it's probably better to do this with an implicit intent. However, this activity doesn't reside in an application I own, so I don't know the action and category and data flags on the intent-filter.
How can I examine an Android applications metadata like the activity classes and the intent-filters for those activities (if declared in the manifest)?
Thanks!
I would try this.
Check on openintents
Contact the developer.
Use android-apktool too see the app's manifest.
It might be illegal to use android-apktool. Use it under your own risk.
There is one more solution: you could run this app and look into logcat. All intents are logged, so you could see what is called up. You won't see extra data though.
My app needs to have a intent-filter that responds to a Intent that has it's component set (a explicit intent.) Here is a example.
Intent i = new Intent();
i.setClassName("com.compareeverywhere","com.compareeverywhere.ScanActivity");
startActivity(i);
Just a simple intent-filter will not do - because the Intent is made for a specific component (Activity,) it just launches that without looking for intents at all. Is there a way to do this?
Thanks, Isaac Waller
P.S: Please don't reply "No."
No.
:) That being said, imagine what would happen if Android allowed people to hijack Intents for specific components. Don't like a competitor's app? Just have yours hijack his main Activity with your own to display porn. Intents can specify specific components specifically because the authors don't want others to be able to replace them.
You have two options. If this is your own code, replace it with a generic intent, or if it belongs to someone else, contact them, and ask nicely for them to change it to a generic intent along with some good reasons why that is necessary.