UsbPortManager is made to support both AIDL & HIDL interface until
HIDL is deprecated eventually. UsbPortHal abstract class is defined
which the UsbPortManager grabs an instance of from UsbPortHalInstance
method to talk to the Hal implementation process. UsbPortHalInstance
queries the underlying hal implementation and instantiates UsbPortHal
with either UsbPortHidl or UsbPortAidl based on the IUsb interface
implemented by HAL implementation.
go/iusb-aidl-migrate.
Bug: 200993386
Bug: 199357330
Bug: 211677613
Bug: 213312081
Bug: 199358576
Test: Manually tested through UI.
CTS-Coverage-Bug: 215019881
Change-Id: I246fd6e5bee8138d3ad3b6994665a1d4788c8789
Merged-In: I246fd6e5bee8138d3ad3b6994665a1d4788c8789
(cherry picked from commit bbfa92e694)
* changes:
Only invoke listener once physical address becomes known
Don't remove devices on onHotplug()
Assign local device portId 0
Set device type on first message received
This CL affects TV panels and Audio Systems only.
Before HdmiCecNetwork existed: devices were removed when
HotplugDetectionAction detected a hotplug out, and TIF was informed.
Before this CL: devices were removed from the CEC network onHotplug,
but the listener to inform TIF wasn't invoked. This was causing
multiple issues.
After: on TV panels and Audio Systems, only remove devices when
HotplugDetectionAction detects a hotplug out,
just like before HdmiCecNetwork existed.
Test: atest
Bug:213417037
Change-Id: I4181b4650b70101da44fd205e4df9eb566f74496
Merged-In: I4181b4650b70101da44fd205e4df9eb566f74496
Use the new @EnforcePermission annotation for SerialService.
Test: Manually inspect ISerialManager.java, the permission checks are
correctly generated.
Test: Run SerialChat app as regular app, SecurityException triggered
when launching the app.
Test: Run SerialChat as priv-app. Access is granted, the app executes
normally.
Bug: 197828948
Change-Id: Ide1d2809f2226f7cd84efa0d364dc78da726f294
This new PresentationSession interface enables an application to do a
multi-document presentation, something which isn't possible with the
existing API. As a practical example of this consider presenting both
your Mobile Driving License and your Vaccination Certificate in a single
transaction.
Also update the documentation for IdentityCredential to clarify that
the same AuthKey is used for multiple getEntries() calls on the same
credential.
Also deprecate existing IdentityCredential.getEntries() method and
related methods and classes.
Bug: 197965513
Test: New CTS tests and new screen in CtsVerifier
Change-Id: I74534969143882552407917a82f44d43da12711c
If a vendor command without vendor ID is received, the message is now
forwarded to all registered listeners, irrespective of the device type.
If a vendor command with ID is received, the message is forwarded to all
listeners registered with that vendor ID
Bug: 177061176
Test: atest com.android.server.hdmi.HdmiControlServiceTest#addVendorCommandListener_noCallback_VendorCmdDiffIdTest
atest com.android.server.hdmi.HdmiControlServiceTest#addVendorCommandListener_receiveCallback_VendorCmdNoIdTest
atest com.android.server.hdmi.HdmiControlServiceTest#addVendorCommandListener_receiveCallback_VendorCmdWithIdTest
Change-Id: I84e010ccbe58ff090348babba05db0c31add1136
It might cause deadlock sometimes:
The locking order of setEventsMask is:
registerDisplayListener -> <DMG.mLock> -> setEventsMask -> <class lock>;
The Locking order of handleMessage is:
Looper.loop -> Looper.loopOnce -> Handler.dispatchMessage -> handleMessage -> <class lock>;
Therefore, when the registerDisplayListener is called by client,
the DisplayListenerDelegate.handleMessage also called by DMS's callback,
at this time, if the method with DMG.mLock is called in handleMessage(),
it will lead to deadlock.
Test: (For example)
Thread A:
DisplayListenerDelegate.handleMessage() -> <class lock>
DisplayListener.onDisplayChanged() -> DMG.getCompatibleDisplay() ->
DMG.getDisplayInfo() -> <DMS.mLock>
Thead B:
DMG.registerDisplayListener() -> <DMS.mLock> -> DisplayListenerDelegate.setEventsMask() -> <class lock>
Signed-off-by: jiayongqiang <jiayongqiang@xiaomi.com>
Change-Id: Ie1a8728339c16fa8f4c4f5c758821c836fa1c96b
Bug: 201045056
Test: Verified that BiometricPrompt shows an error message if the user
is using face authentication and camera privacy is enabled.
Change-Id: Idc2140062c4aa87e0bcffb14e07336dc6cd7d955
The JPEG size override is done only when the
android.os.Build.VERSION_CDOES.MEDIA_PERFORMANCE_CLASS is set to
31 or larger, and not necessarily for every MPC13 devices.
Bug: 209622756
Test: Build
Change-Id: I4d76db1780e0d777e8da68a06829ce0e424905d5
If the camera privacy sensor is enabled, show an error message
on Keyguard.
Test: Verified that the sensor privacy error is shown when privacy sensor is enabled.
Bug: 201045056
Change-Id: Ib7709596d378caa690a782294197a5b26e55857f
In case the camera client disconnects from an output surface referenced
by an active repeating request, a race could occur between the client
and camera service. Camera service will notify the client about the
failed repeating request and will reset the request id internally.
During this time period the client can also try to call "stopRepeating"
which will trigger an IAE, reset the client repeating request id value
and return immediately. Once the "onRepeatingRequestError" gets
scheduled or unblocked, the framework will just ignore it since it
doesn't have any information about an active repeating request.
The framework will be unable to track the last frame id in the repeating
sequence. The sequence will never complete and the 'onClosed' callback
will not get triggered as well.
To mitigate this, cache the request id in case of IAE during
"stopRepeating" and try to resume the last frame id sequence tracking
once "onRepeatingRequestError" arrives.
Bug: 205895636
Test: Camera CTS
Change-Id: I5da4a82d156227568aaebe74a5e0b2400de1d01e
