我想在服务和活动之间传输少量数据。这些是单独的应用程序理想情况下，我只是将我的数据（以及确认的随机数）打包到Intent中并使用它。但根据Mark Murphy的博客文章Warning: Activity Intent Extras Can Be Public，我知道这不安全。
ResultReceiver安全吗？
有没有更好的方法来做我想要的？
这是我的用例：
服务A将使用Intent启动活动B并询问问题＆＃34;操作X是否已获得授权？＆＃34;。可能需要用户操作，这就是我从服务启动活动的原因。
我希望活动B简单地回答＆＃34;是＆＃34;或＆＃34;不＆＃34;。我想确保设备上的恶意应用无法欺骗该响应。我当前的代码使用Intent发送响应。
我采取了纵深防御的方法，其中一部分是我不希望A到B的请求被任何其他人读取。除其他外，我打算将一个nonce打包到原始请求中
回答@ mwhs＆＃39;问题：
服务只询问是/否问题。我想非常肯定答案来自我期待它的人。一个nonce应该做的伎俩，但它需要安全地传输。
除了一点点涉猎之外，我不是安全专家。你是什么意思＆＃34;在初始发送方那边收到那个非随机数字必须带有一个证据，即预定的一方实际上用该nonce回复，理想情况是通过将nonce（或它的减量）加密地绑定到证明身份（例如，可以使用共享的好钥匙）＆＃34;？
假设我可以将nonce安全地发送给另一方，并不是说对方响应它的事实构成了他们是预定的一方的证据吗？我如何＆＃34;绑定＆＃34;身份证明的随意性？某种HMAC？为什么减少它;是某种哈希破坏者？
我有点怀疑将共享秘密嵌入到理论上可以进行逆向工程的应用程序中。
答案 0 :(得分：1)
服务A将使用Intent启动活动B并询问问题＆＃34;操作X是否已获得授权？＆＃34;。可能需要用户操作，这就是我从服务启动活动的原因。
对于普通设备上的普通应用程序，这不是推荐的方法，除非您确定用户不会后悔您在活动中接管前景。
我希望活动B简单地回答＆＃34;是＆＃34;或＆＃34;不＆＃34;。我想确保设备上的恶意应用无法欺骗该响应。
您引用的博客文章指的是以前存在于Android中的错误，用于打包在用于Intent的{{1}}上的其他内容。如上所述，您的方案不涉及此问题，因为您没有提及从服务A传递到活动B的startActivity()上的任何额外内容。此外，该错误已被修复，但我忘记了4中的确切位置.x系列它是固定的。
我当前的代码使用Intent发送响应。
这不是特别丰富的声明。这类似于说您使用字符串发送响应。字符串或Intent可能是响应的格式，但不知何故，您需要使用进程间通信（IPC）将该响应返回给服务A.
一个非选项是Intent，因为它只适用于活动，而不是服务。
可能的IPC选项包括：
使用自定义startActivityForResult()权限在服务上调用startService()并传递Intent，以确保只有您的应用可以在该服务上调用signature。
在服务上调用startService()，等待获取活页夹，然后将bindService()（或其他）传递给您在Intent上实现的某种方法（并使用与上述相同的自定义Binder权限。）
将signature从服务A传递给活动B作为额外内容，让活动B填充并执行PendingIntent。您可以使用PendingIntent权限或验证活动B的应用程序的签名密钥，以确保服务A仅将其发送到正确的应用程序。并且，当我在博客文章中列出的问题得到修复时，您需要研究确切的问题。
将signature从服务A传递到活动B（否则与上面ResultReceiver方案的工作方式相同）
通过PendingIntent向服务A注册BroadcastReceiver，然后让活动B发送与接收者registerReceiver()匹配的广播。您需要使用自定义IntentFilter权限路径。
在Android组件系统之外做一些事情（例如，在活动与之对话的服务中使用HTTP守护进程）。 ICK。
请注意custom permissions suck，至少在Android 5.0之前。
除了现在修复的近期活动signature泄漏之外，我不知道目前有任何监视IPC的方法，除了：
后一种情况是Intent权限或验证活动B的应用程序的签名密钥发挥作用。
导出的任何内容（方案＃1，＃2，＃5）都存在欺骗风险。 signature权限有帮助，除了自定义权限很糟糕。我倾向于＃3或＃4。
根据这些应用之间正在进行的其他通信，可能还有其他选项（例如，长期绑定服务，使用回调对象提供双向通信）。