至少在多核平台上（并且大多数新智能手机都是多核的），只要攻击者能够以足够的精度访问时钟，所有对分支预测和缓存的侧信道攻击都应该有效。ARM 架构有一个应用程序代码可以使用的“循环计数器”，但它必须首先从特权代码（内核）启用；看到这个答案。从 Android 2.3（使用NDK）开始的应用程序可以使用本机代码。

我不知道Android是否默认启用了循环计数器；它在新启动的 CPU 中被禁用，但 Android 使用 Linux 内核，并且循环计数器对于许多任务非常方便，包括实现gettimeofday()系统调用，因此 Linux 内核可能启用它。这应该被测试。

如果启用了循环计数器，那么System.nanoTime()对于纯 Java 应用程序，Java 方法也可能返回相同的信息。因此，甚至可能不需要使用原生来对 Android 发起缓存定时攻击。

此外，还可以有其他准确的时钟。例如，GPS API 提供了一个，即Location.getElapsedRealtimeNanos()。

对缓存访问的侧信道攻击已经在常见的 AES 实现中得到证明（在实验室条件下，但仍然得到证明）。针对这种针对密码算法的攻击已经完成了相当多的工作，但这里并没有真正针对密码学。恰好密码算法使用密钥并且密钥集中秘密；知道钥匙可以揭示很多东西，所以钥匙是高价值的目标。此外，所有此类攻击均由密码学家研究，密码学家致力于密码算法。然而，边信道泄漏可能发生在任何算法的每一次实现上，无论是否加密。通常，当设备中发生加密时，是因为一些机密数据由该设备处理，所有这些处理，而不仅仅是加密，可能会像疯了一样泄漏。这个问题是真实的和包罗万象的。

在这些假设下，人们必须假设可以从一个应用程序中推断出很多关于其他应用程序做什么的数据。防御与您在同一硬件上同时运行代码的本地攻击者是很困难的。

很多。我不打算给出一个详尽的清单，只是举几个有代表性的例子。

应用程序 M 可以了解应用程序 A 正在与哪些 IP 地址进行通信？

是的，即使它闭着眼睛，双手被绑在背后。/proc/net/tcp列出所有打开的 TCP 连接。这是我。在 Android 上，uid 显示应用程序；给定进程的相同信息对/proc/$pid/net/tcp.

shell@android:/ $ cat /proc/net/tcp                                            
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 3600030A:AF4C 10CEFCC6:0050 01 00000000:00000000 00:00000000 00000000 10004        0 402734 1 00000000 37 3 8 10 -1                            
…

应用程序 M 是否可以了解应用程序 A 当前是否正在使用某些独占访问资源/传感器（例如，麦克风、相机等）？

如果资源是独占访问的，那么应用程序 M 至少可以轮询以查看资源是否正在使用中。M 可以将此信息与应用程序 A 在 中的活动统计信息相关联/proc/$pid/stat*。

应用程序 M 可以推断出有关通过屏幕软键盘输入应用程序 A 的文本的任何信息吗？

是的。智能手机有很多输入设备：摄像头、麦克风、加速度计……单独使用加速度计，

在受控设置中，当从 50 个 PIN 和 50 种模式的测试集中进行选择时，我们的预测模型在 5 次尝试内平均可以对 43% 的输入 PIN 和 73% 的时间进行分类。在不受控制的环境中，当用户走路时，我们的模型仍然可以在 5 次尝试内对 20% 的 PIN 和 40% 的模式进行分类。

该成功率仅在 50 个随机 PIN 中，并且在决定之间的成功率1974可能1975会更低。另一方面，这项研究仅使用加速度计，结合其他数据（如相机和时间）可能会提高速度。

计时措施会泄露大量数据；见汤姆李克的回答。

通过的信息/proc是特定于 Android 的；其他操作系统可能会也可能不会公开此信息。SEAndroid 之类的东西可以防止这些信息泄露给其他应用程序。另一方面，侧通道问题不能简单地通过更好的数据流隔离来逃避。它们需要消除有用的功能，例如在另一个应用程序正在执行时告诉时间或访问硬件设备的能力，这在某些设置（例如智能卡）中可能是可以接受的，但在智能手机中是不可接受的。