根据 RFC 2109，Cookie 严格意义上属于 HTTP 机制。 不应用于除 HTTP 以外的其他协议，包括 file://。 目前还不清楚它们的行为应该是什么，以及适用何种安全分隔规则。 例如，从 Internet 下载到本地磁盘的 HTML 文件是否应与本地安装的任意 HTML 代码共享相同的 Cookie？

不建议开发人员使用未记录或隐藏的 API 构建其应用程序。 由于无法保证 Google 未来不会删除或更改这些 API，因此应避免使用它们，并且使用此类方法或字段具有破坏应用程序的较高风险。

在 Camera 对象释放后，代码试图使用该对象。在未重新获取 Camera 对象的情况下任何对该资源的进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例：以下代码使用切换按钮来打开和关闭照相机预览。用户轻按该按钮后，照相机预览停止，并释放照相机资源。但是，如果再按一次按钮，将调用之前释放的 Camera 对象中的 startPreview()。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

在媒体对象释放后，代码试图使用该对象。在未重新获取媒体对象的情况下任何对该资源的进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例：以下代码使用切换按钮来切换媒体播放。用户按此按钮后，当前歌曲或视频就会停止，并将释放照相机资源。但是，如果再按一次按钮，将调用之前释放的媒体资源中的 start()。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

当 Android SQLite 数据库处理器关闭后，代码仍试图使用它。在未重新建立数据库连接的情况下，对处理器的任何进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例：以下代码可能来自将用户值暂时缓存在内存中，但可调用 flushUpdates() 将这些变化提交到磁盘中的程序。该方法会在将更新写入数据库后正确关闭数据库处理器。然而，当再次调用 flushUpdates() 时，数据库对象会在重新初始化之前被再次引用。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

在完全进行数据擦除和恢复出厂重置后，硬件和设备特定标识符仍会存在。因此不应依靠此类信息生成用来授权或验证用户的唯一标识符。

不仅如此，由于通用的唯一标识符与个人信息是在一起的，因而泄漏后会给用户隐私和安全带来威胁。

Android 类加载劫持漏洞主要表现为以下两种形式：

- 攻击者可以更改程序在其中搜索来加载类的目录的名称，从而指向他们有控制权的某个目录的路径：攻击者明确控制了将在其中搜索类的路径。

- 攻击者可以更改用于加载类的环境：攻击者间接控制了路径名的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制在其中搜索加载类的目录。这种类型的 Android Class Loading Hijacking 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据用作一个或部分字符串，代表在其中搜索要加载的类的库目录。



3. 通过从库路径执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

例 1：以下代码使用用户可更改的 userClassPath，来确定在其中搜索要加载的类的目录。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此代码允许攻击者通过将 userClassPath 的结果修改为指向他们控制的不同路径，以提升的应用程序权限加载库并可能执行任意代码。因为程序不验证从环境读取的值，如果攻击者能够控制 userClassPath 的值，那么他们就可以欺骗应用程序指向他们控制的目录，从而使用与原始应用程序一样的权限加载他们已经定义的类。

例 2：以下代码使用用户可更改的 userOutput，来确定应将优化的 DEX 文件写入的目录。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此代码允许攻击者指定优化的 DEX 文件 (ODEX) 的输出目录。这样，恶意用户便可以将 userOutput 的值更改为他们控制的目录，例如外部存储。一旦达到这一目的，便可以很轻松地将输出的 ODEX 文件替换为恶意 ODEX 文件，并使用与原始应用程序一样的权限加以执行。