API for home support on virtual displays.
Instead of adding yet another virtual display flag, the API is in
VirtualDisplayConfig and uses WM's DisplayWindowSettings to store the
bit whether home is supported.
The difference with the existing FLAG_SHOULD_SHOW_SYSTEM_DECORATIONS
is that it also adds navigation bar and the new API doesn't. The flag
is hidden but there are existing clients of it.
Several caveats:
- Need to use displayUniqueId instead of displayId because we should
tell WM about the home support before the display is actually
created and the display listeners notified.
- Interacting with the DisplayWindowSettings requires the WM lock,
which must not be acquired while DisplayManagerService is holding
its own lock because this may and will sometimes cause deadlock.
- So extracting the displayUniqueId generation logic before the DMS
locked region of actually creating the virtual display and passing
it to WM to store the settings.
- Change in the virtual display uniqueId generation: reusing ids per
package/uid causes problems in when displays with the same name
are created and released quickly (CTS). When there are no display
devices, the same unique id is used, but the DisplayWindowSettings
may not have yet received the previous onDisplayRemoved callback,
so the setting for that uniqueId is removed. Making the uniqueIds
truly unique fixes this and there's no realistic danger of an
overflow.
Fix: 291749213
Fix: 297167917
Test: see CTS in topic
Test: atest VirtualDisplayAdapterTest
Test: atest DisplayWindowSettingsTests
Test: atest DisplayAreaPolicyTests
Change-Id: If72696a793a9c4d63d4f8b72de7433b0dd440909
18 files changed