File changed.
Preview size limit exceeded, changes collapsed.
Loading
Remove AndroidFuture from ShortcutService's internal api
AndroidFuture is not meant to be used as a return type, this CL removes the cases where AndroidFuture is used as a return type. After closely scrutinize some of the api are not required to be async in system level to support AppSearch integration in the future. Here's the list of API that can was previously made async at service-level but could actually stay synchronous: - setDynamicShortcuts/addDynamicShortcuts: Dynamic shortcuts are stored in system ram only unless it is also a long-lived shortcut, yet long-lived shortcuts are persisted into AppSearch in a separate background thread, client process should not need to wait for writing to AppSearch to finish. - updateShortcuts: Long-lived shortcuts that lives in AppSearch might be updated by this api, but similar to setDynamicShortcuts/addDynamicShortcuts client process is not required to wait for writing to AppSearch to finish. - removeDynamicShortcuts/removeAllDynamicShortcuts: The method signature doesn't return anything in the first place, so client process is not required to wait for AppSearch. - disableShortcuts/enableShortcuts: Similarily, since the method signature doesn't return anything, client process is not required to wait for AppSearch. - reportShortcutUsed/onApplicationActive/applyRestore: No return type. - removeLongLivedShortcut: The operation itself should be async, but since it has no return type, client process is not required to wait. API that should become async at service level but remain sync in client process are: - requestPinShortcut: To support drag and drop from AllApps+, client process should be waiting for the pin request to complete since long-lived shortcuts that doesn't exists in system memory might still be surfaced in AllApps+. Since read from AppSearch is async, the client process will need to wait for the read to finish synchrounously. - createShortcutResultIntent: Similarily, a client process might call this api to launch a long-lived shortcut that doesn't exists in system memory. So the client process needs to wait for read from AppSearch to finish. API that should be async but is not covered in this CL - getShareTargets: Sharing shortcuts could be potentially backed up long-lived shortcuts that doesn't live in system ram, but this api is already being used by PeopleService, thus should be covered in a separate CL as it would need to be reviewed by another team. Bug: 197277083 Test: atest ShortcutManagerTest1 ShortcutManagerTest2 ShortcutManagerTest3 ShortcutManagerTest4 ShortcutManagerTest5 ShortcutManagerTest6 ShortcutManagerTest7 ShortcutManagerTest8 ShortcutManagerTest9 ShortcutManagerTest10 ShortcutManagerTest11 Test: atest CtsShortcutManagerTestCases Change-Id: I8970cc77073d329fe00a349d9fa190f917b7851d