1

Are there any drawbacks to using intents as a form of message passing between two apps that I control?

I have two apks which will always exist on the device together. And, I'd like to use explicit intents to pass messages back and forth as opposed to creating and managing two separate services. Using explicit intents just seems like an easier to manage approach than services.

Sofia Clover
  • 569
  • 1
  • 5
  • 15
  • What exactly is your scenario? What kind of interaction between your applications, is the User Level (`Activity`) or interactions are in the background? Could you explain more your question? – Anderson K Jul 21 '14 at 23:21
  • If you're the one who wrote those two apps, you could make sure that they were treated as the same app, this way they could share data more easily. That would cut down on the data you'd have to share through intents. – Stephan Branczyk Jul 21 '14 at 23:26
  • @StephanBranczyk - when you say 'treated as the same app', are you referring to setting them up to use the same userId? shareUserId field set in the manifest ? – Sofia Clover Jul 21 '14 at 23:30
  • @André.C.S - The interactions would be in the background, i.e. - no UI results or actions needed in the UI. It is strictly passing data back and forth. – Sofia Clover Jul 21 '14 at 23:31
  • You cannot use explicit intents, between different apps. – G. Blake Meike Jul 22 '14 at 00:07
  • @G.BlakeMeike - From my understanding, the whole purpose of explicit intents is to initiate a specific app with a fully-qualified class name. – Sofia Clover Jul 22 '14 at 00:19
  • Yes, Sofia, the same sharedUserId from the manifest signed with the same key. Also, I think Blake meant to say that explicit intents can be restricted to the same shared application user id if its application and component attributes are set to android:exported="false" so there shouldn't be a problem with security. – Stephan Branczyk Jul 22 '14 at 00:24
  • An "explicit" intent is one that contains a reference to a specific class object. Those intents cannot travel across application (process) boundaries. An "implicit" intent, in contrast, has a String as a target. The Android OS binds the String to a component in some app. Implicit intents work across process boundaries. – G. Blake Meike Jul 22 '14 at 01:38
  • @SofiaClover Do not confuse an Intent with a specific ComponentName (via Intent.setClass) with an explicit Intent. I'm not entirely clear on what my esteemed fellow Oaklander Stephan is saying but an explicit intent cannot initiate a specific (different) app... – G. Blake Meike Jul 22 '14 at 01:46

3 Answers3

1

Communication between applications can expose certain rich, but if you really need to do this way, you can only customizing permissions that your applications will have knowledge. Then you can use BroadcasrReceiver to exchange messages securely using custom permissions.

Defining their permission:

<permission android:name="com.yourapp.PERMISSION"
    android:protectionLevel="signature"
        android:label="@string/permission_label"
        android:description="@string/permission_desc">
</permission>

By setting

<receiver android:name=".MyReceiver"
    android:permission="com.yourapp.PERMISSION">
    <intent-filter>
        <action android:name="com.yourapp.ACTION" />
    </intent-filter>
</receiver>

In addition to these permissions you can also set them their purchases Activities, Services, ContentProvider.

Edited

Integration between existing processes in Android (Inter-Process Communication), the AIDL (Android Interface Definition Language).

AIDL is particularly useful when different applications need to communicate among themselves to exchange information through a well-defined interface with support for multithreading. Unlike the use of Messenger with Bound Services with AIDL you are required to create a file. AIDL containing the declaration of the integration interface, which helps the client applications to know which operations are available as well as their respective arguments and returns.

Anderson K
  • 5,115
  • 5
  • 29
  • 48
  • The semantics of Broadcast Intents are not particularly appropriate for interprocess communication. Much better to simply use an IntentService and send the intents using `startService` – G. Blake Meike Jul 22 '14 at 00:08
  • @G.BlakeMeike, I agree with you, when you say that `Broadcast` is not the best choice for this scenario, but if we can really speak the best way for this context, **AIDL** is undoubtedly the best way to do this, I edited my answer to add this artifice. – Anderson K Jul 22 '14 at 00:24
  • Bound Services and AIDL are powerful tools. They are also somewhat complicated. For many applications, simply firing off an Intent may be just the ticket. – G. Blake Meike Jul 22 '14 at 01:40
  • @G.BlakeMeike, well, I suggest you post your answer, with your vision, so you think can help you further! – Anderson K Jul 22 '14 at 01:44
0

You can use intents to pass data between two apps..however I see once drawback(not too big)-you need to take care that those intents dont get exposed to others.Some malicious app can use the same intents to send bad data something similar to Denial-of-service attacks.

Just to add-if the interactions are in background you can use broadcast receivers too.

Also if the apps are always going to be together why are you not packing them as single app.If you are using parcelables, your flow might break if there are two different incompatible versions of the parcelable.(if you add a field to a object in new version of an app,the other app is still not updated,the app might crash).

rupesh jain
  • 3,287
  • 1
  • 10
  • 21
0

Although the discussion here seems really good, at @André.C.S's suggestion, I will add my 2 cents.

Intents are a simple and effective way of passing messages between processes. One of Android's key features, the ability to call another application as a function (Activity.startActivityForResult), depends on it.

As everyone here has already pointed out, intents, whether fired at BroadcastReceivers, Services or Activities, have security issues. If you decide to use them, you will need to protect them. Andre's description of how to use permissions to do that is spot on. You must treat the method that catches the intent as if it were a web service and verify parameters, etc. accordingly.

Finally, Intents, while simple, are really not appropriate for high-bandwidth IPC. If you will be exchanging messages with the other app at a rate measured in milli-seconds, you will want to look into AIDL and a bound service. By my measurements, they are between 1 and 2 orders of magnitude faster.

Incidentally, you might consider running both applications in the same process. There are manifest application attributes that allow that. If you did that, using explicit intents would be easy and your apps would be much safer.

Edited to point out extremely embarrassing error

So, taking my own advice, I tried it. To my horror, as several people have tried to point out, explicit intents can be used across processes.

I am eating a large helping of crow, with humble pie for dessert.

An explicit intent contains a ComponentName object, not an explicit reference to a class object, as I claimed. A ComponentName contains a package name and a class name. The former is, typically, derived from the current context and thus is local to the current process. It is possible, however, to construct an intent with a package name that is an arbitrary string.

I stand corrected.

G. Blake Meike
  • 6,323
  • 3
  • 21
  • 38
  • It still seems to me that the whole intention of explicit intents is indeeed to start a different app. That is why you supply a fully qualified package name. Dalvik takes care of finding if for you across processes. See these SO questions - http://stackoverflow.com/questions/2780102/open-another-application-from-your-own-intent & http://stackoverflow.com/questions/6829187/android-explicit-intent-with-target-component?lq=1 – Sofia Clover Jul 22 '14 at 17:36
  • Yes @SofiaClover And three days before you tried it, I edited my answer to that effect. It *does* work. – G. Blake Meike Jul 30 '14 at 03:56