diff options
| author | 2023-07-13 18:41:31 +0000 | |
|---|---|---|
| committer | 2023-07-14 17:56:44 +0000 | |
| commit | 6e4fea576cfd1190317d0b898b769885988acde5 (patch) | |
| tree | 40a124c25b0a85bc1218bbc24e4907b9565d3631 /wifi/java/src | |
| parent | 2689c4ecec99e41da37f63524408124a1fb66cab (diff) | |
Ensure the getCredentialType cache gets enabled
Invalidate the getCredentialType cache at boot time. This works around
an issue in PropertyInvalidatedCache where caches don't work until they
are invalidated for the first time. This workaround can be removed if
the underlying issue in PropertyInvalidatedCache is fixed, but that will
require a bit more discussion and will be riskier than this workaround.
This fixes a performance regression introduced by ag/19284361 ("Simplify
invalidation of lockscreen credential type cache"). That CL eliminated
unnecessary cache invalidations, which should have improved performance.
Unfortunately, due to the unexpected PropertyInvalidatedCache behavior,
it actually made the cache stop working entirely in the common case
where no user's lockscreen credential has changed since boot.
Bug: 268192609
Test: Set DEBUG=true in PropertyInvalidatedCache.java. Build and flash.
Run 'adb logcat | grep getCredentialType', and turn screen off and
on. Verified that "cache hit" messages are logged, whereas before
this CL "cache getCredentialType unset" messages were logged.
Change-Id: Ie826bdb163288e5741a33e26209d3175de426bd1
(cherry picked from commit d91457a155c99bb4506e8c70c0129b634f3e1247)
Merged-In: Ie826bdb163288e5741a33e26209d3175de426bd1
Diffstat (limited to 'wifi/java/src')
0 files changed, 0 insertions, 0 deletions