tree a9974429733defe0afcdb9fea9666b4f2fd9064f
parent 0cccde6b1ad66c16a1dbacdd17c634efdf80d83d
author Badhri Jagan Sridharan <Badhri@google.com> 1515718589 -0800
committer Badhri Jagan Sridharan <badhri@google.com> 1516891362 +0000

Add support for UsbDeviceManager to talk to USB GADGET HAL

Till now, Init scripts(property tiggers) are used define the
operation that needs to be performed when a certain gadget
composition needs to be enabled. Based on the user preference,
usb service sets the sys.usb.config which triggers the
corresponding property triggers in init scripts and usbservice
polls on sys.usb.state to infer whether the property triggers
have completed executing.

This CL makes UsbHandler class abstract to make init scripts
based legacy implementation and HAL based implementation to
share the common logic. The legacy init script based logic is
implemented by UsbHandlerLegacy and HAL based logic is implemented
by UsbHandlerHal. The decision on which one to initialize is
made depending on whether the device has Gadget HAL impelemented.

Since HIDL supports asynch calbacks, usb state management is moved
to the message queue to avoid polling incase of HAL based
implementation.

To switch to a new configuration:
1. UsbService calls setCurrentUsbFunctions and queues
   MSG_SET_FUNCTIONS_TIMEOUT
2. If the  setCurrentUsbFunctionsCb arrives on time,
   then  MSG_SET_FUNCTIONS_TIMEOUT is cancelled and
   default functions are retried by queueing
   MSG_SET_DEFAULT_FUNCTIONS if SUCCESS is not signalled.
3. If MSG_SET_FUNCTIONS_TIMEOUT gets executed, then,
   default functions are retried by calling
   setEnabledFunctions(null, false, mUsbDataUnlocked);

Also, for HAL based implementation config_oemUsbModeOverride is no
longer needed as hal can take of enabling oem specific functions.

Bug: 63669128
Test: Tested usb gadget configuration for both cases:
1. When gadget hal is present
2. When gadget hal is not present
Change-Id: Ifcef464a0b97b265872696346a76162f8e84d6c0