Close AppSearchImpl in handling user removed broadcast.

Flushing takes a few ms, it seems like a pretty good trade off compared
to keeping an icing instance in memory forever.

Bug: 179390369
Test: presubmit
Change-Id: Ic0493137dc8c33d44bd074bbd9ca4ae442049513
This commit is contained in:
Terry Wang
2021-06-09 18:50:53 -07:00
parent 12b7df48e7
commit a3d8ce430c
2 changed files with 1 additions and 20 deletions

View File

@@ -179,7 +179,7 @@ public class AppSearchManagerService extends SystemService {
*/
private void handleUserRemoved(@NonNull UserHandle userHandle) {
try {
mImplInstanceManager.removeAppSearchImplForUser(userHandle);
mImplInstanceManager.closeAndRemoveAppSearchImplForUser(userHandle);
mLoggerInstanceManager.removePlatformLoggerForUser(userHandle);
Log.i(TAG, "Removed AppSearchImpl instance for: " + userHandle);
} catch (Throwable t) {

View File

@@ -103,25 +103,6 @@ public final class ImplInstanceManager {
}
}
/**
* Remove an instance of {@link AppSearchImpl} for the given user.
*
* <p>This method should only be called if {@link AppSearchManagerService} receives an
* ACTION_USER_REMOVED, which the instance of given user should be removed.
*
* <p>If the user is removed, the "credential encrypted" system directory where icing lives will
* be auto-deleted. So we shouldn't worry about persist data or close the AppSearchImpl.
*
* @param userHandle The multi-user user handle of the user that need to be removed.
*/
public void removeAppSearchImplForUser(@NonNull UserHandle userHandle) {
Objects.requireNonNull(userHandle);
synchronized (mInstancesLocked) {
// no need to close and persist data to disk since we are removing them now.
mInstancesLocked.remove(userHandle);
}
}
/**
* Close and remove an instance of {@link AppSearchImpl} for the given user.
*