Warning: file_get_contents(/data/phpspider/zhask/data//catemap/7/google-maps/4.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Java 为什么Android keymaster logging DROPBOX\u ENTRY\u会在Android 9中添加事件?_Java_Android_Encryption_Broadcastreceiver_Android Keystore - Fatal编程技术网

Java 为什么Android keymaster logging DROPBOX\u ENTRY\u会在Android 9中添加事件?

Java 为什么Android keymaster logging DROPBOX\u ENTRY\u会在Android 9中添加事件?,java,android,encryption,broadcastreceiver,android-keystore,Java,Android,Encryption,Broadcastreceiver,Android Keystore,我使用的是一款Android应用程序,它可以处理一些敏感数据,因此在我向存储器写入或读取数据的任何时候都严重依赖加密。在AndroidAPI27及以下版本中,它工作良好,速度非常快。然而,我注意到在API 28(Android 9,Pie)中,解密操作要慢得多 查看我的日志,我注意到一条新消息被垃圾邮件发送了数百次: 2018-12-19 16:20:10.564 1233-1260 W/BroadcastQueue: Background execution not allowed: rece

我使用的是一款Android应用程序,它可以处理一些敏感数据,因此在我向存储器写入或读取数据的任何时候都严重依赖加密。在AndroidAPI27及以下版本中,它工作良好,速度非常快。然而,我注意到在API 28(Android 9,Pie)中,解密操作要慢得多

查看我的日志,我注意到一条新消息被垃圾邮件发送了数百次:

2018-12-19 16:20:10.564 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
2018-12-19 16:20:10.565 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver
2018-12-19 16:20:10.588 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
2018-12-19 16:20:10.588 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver
2018-12-19 16:22:54.580 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
2018-12-19 16:22:54.580 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver
看起来每个解密操作都会生成一个添加的
com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
广播

com.google.android.gms/.chimera.gmsintentooperationservice$PersistentTrustedReceiver
尝试处理。这似乎需要花费大量的时间,而且在Android Pie之前也不是问题。为了量化,我在API23中对这些相同的解密操作进行了基准测试,平均操作时间约为3ms。Android Pie上完全相同的代码需要60-90毫秒,速度慢20-30倍。疯子这在我的应用程序启动时尤其明显,因为它需要解密几百个小字符串才能加载一些用户数据。在Android Pie上,我的应用程序启动时间现在需要整整10秒,而这条消息一直在logcat中被垃圾发送

我生成了一个bugreport并查找任何有趣的内容,我看到了以下内容:

  Service com.google.android.gms.stats.service.DropBoxEntryAddedService:
    Process: com.google.android.gms
    Running op count 34:
      SOn /Norm: +12s205ms
          TOTAL: +12s205ms
    Started op count 17:
      SOn /Norm: +12s118ms
          TOTAL: +12s118ms
    Executing op count 652:
      SOn /Norm: +2s737ms
          TOTAL: +2s737ms
我不确定如何读取这个输出,但巧合的是(或不是),这个服务的总运行时间几乎正是我的应用程序现在启动所需的时间

接下来,我想看看这些消息中有什么内容,所以我在根仿真器上运行了它,并执行了一个
dumpsys dropbox keymaster--print

========================================
2018-12-19 18:32:04 keymaster (data, 52 bytes)
/data/system/dropbox/keymaster@1545262324865.dat

========================================
2018-12-19 18:32:04 keymaster (data, 52 bytes)
/data/system/dropbox/keymaster@1545262324880.dat

========================================
2018-12-19 18:32:05 keymaster (data, 53 bytes)
/data/system/dropbox/keymaster@1545262325142.dat
dropbox中有数百个这样的条目。查看实际生成的文件,我发现前几个似乎是合理的:获取提供者、加载AndroidKeystore、生成我的密钥,然后是成百上千个完全相同的事件:

AES�Imported2Nonebctrhr解密

它是一个非ASCII记录,因此hextump如下所示:

0000000 0a 03 41 45 53 10 80 01 1a 08 49 4d 50 4f 52 54
0000010 45 44 32 04 4e 4f 4e 45 42 03 43 54 52 48 01 52
0000020 07 64 65 63 72 79 70 74                        
0000028
不管这有多有趣,它并没有让我更接近实际问题或解决方案。为什么Android 9会出现这种情况?每次执行解密操作时,广播看似无用的消息有什么意义?我怎样才能预防它?还有其他人经历过吗

要添加更多详细信息,请执行以下操作:

  • 使用
    AndroidKeystore
    进行密钥存储
  • CipherInputStream
    CipherOutputStream
    AES/CTR/NoPadding
    一起用于实现
  • AES
    SecretKey
    在用户第一次启动应用程序时生成,使用
    KeyGenParameterSpec.Builder
    然后使用
    KeyGenerator.generateKey()
  • 随后的应用程序启动使用密钥别名从AndroidKeystore加载密钥
  • SecretKey
    条目引用由encryption helper类持有。它不是为每个加密/解密操作加载的
  • 使用上面的
    SecretKey
    参考和
    AES/CTR/NoPadding
我很乐意回答任何后续问题。这对我来说是一个严重的问题,谷歌关于这个“功能”的文档是完全无用的