summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorGreg Kaiser <gkaiser@google.com>2016-09-08 00:12:19 -0700
committerGreg Kaiser <gkaiser@google.com>2016-09-08 14:12:42 -0700
commitf16abd98c7ea8332e413d44a0baa8cb6eaa6669c (patch)
treee88aa84eb567017783797f52f57d45267747ac6a /tools/aapt2/java/JavaClassGenerator_test.cpp
parentc779cdc5609ccd8d588376a22a823bcd9f0199b9 (diff)
ContextHubService: Keep handles across hub reboot
Previously, when a Context Hub rebooted, this service would reset all of the "handles" used to identify the nanoapps on the Context Hub. This caused many issues for Java application code trying to track nanoapps, and these issues were exacerbated under nanohub, which reboots every times it loads an app. We change this so that we keep the same handle across reboot if the same nanoapp is still running post-reboot. We accomplish this by never "invalidating" our caches, but rather performing a query post-reboot and removing stale entries. Due to b/30835598, we needed to change our post-load query to be all apps. Without that change, a race between the two query responses we would have post nanohub app load (one for post-load, one for post-reboot) would leave us without knowing which response we're dealing with. Now, since both requests are the same, we don't care which response we deal with. This is all (hopefully) just for the Nougat release. In the O release, we hope to remove these caches (b/30835981) and the idea of the JNI code inventing handles (b/30810861). Bug: 30950975 Change-Id: I85a84ba5c1a039d69c1adaaea56609e0a38cce42
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions