In order to access system-only cameras client processes need
SYSTEM_CAMERA permissions in addition to CAMERA permissions. A
permission was preferred over other mechanisms such as having private
connections would need to hard-code the package name(s) of clients using
system only camera devices. A system | signature permission on the other hand,
would make this more flexible and would be better for security.
Bug: 133508924
Test: cts CameraManagerTest, CameraDeviceTest
Test: Give cts test SYSTEM_CAMERA permissions by using
adoptShellPermissions and run some camera tests.
Change-Id: Ibcd6ccdb231dcca949ed4fb14712d033a5801d36
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Convert a use of android.text.format.Time.format() to use calculations
based on java.time instead. This avoids future Y2038 issues associated
with Time.
Bug: 16550209
Test: build / boot / treehugger
Change-Id: I37567367f108562bec1510e549186c123f51318b
Simplifies the dismissal of the dialog, and allows for better
synchronization of when the client should receive the error. The only time
that BiometricService should dismiss the dialog is when authentication
is canceled due to another client, which is almost always due to
allowed-but-weird app behavior.
Bug: 135082347
Test: atest BiometricServiceTest
Test: atest BiometricDialogImplTest
Test: atest CommandQueueTest
Change-Id: I10daa798115e51af8a854759e30033c28e6636ba
Hiding of the BiometricDialog is (almost) all handled by SystemUI now.
BiometricService should only send results to the client when it receives
onDialogDismissed() from SystemUI
Bug: 135082347
Test: atest BiometricServiceTest
Change-Id: Ie91fd54680b942e421b7e187f1107ef7323ea719
1) Clean up BiometricDialogImpl. As a side-effect of 2, which cleans up
the dialog lifecycle, we no longer need to have a handler here. This
greatly simplifies the code here.
2) Clean up interface between BiometricDialogImpl and the UI
(BiometricDialogView).
3) Clean up interface between BimetricService and BiometricDialogImpl.
SystemUI is now responsible for dismissing the dialog.
Test: atest BiometricDialogImplTest
Bug: 138628043
Change-Id: Ic1fea4c05c27dfc7eb6fc661f517f0380b9fff99
The ACTIVITY_RECOGNITION permission applies to TYPE_STEP_DETECTOR, not
TYPE_GEOMAGNETIC_ROTATION_VECTOR.
Bug: 139363621
Test: n/a, comment update only
Change-Id: Ibce74be1e704ded04ae710988d0e03df43ab1cf9
ag/7063548 implemented RadioMetadata.hashCode() by calling Bundle.hashCode(),
but that function uses the default implementation that uses the address
of the Bundle. As a result, two RadioMetadata objects that were equal
probably had different hash codes.
RadioMetadata now instead lazily computes its hash code based upon the keys and
values in mBundle.
Fixes: 130750904
Test: atest com.android.server.broadcastradio.hal2.StartProgramListUpdatesFanoutTest
Change-Id: Ia49716594744871831bc3734aea37e0f505897bf
canAuthenticate() is meant for apps so it will reflect the
FACE_UNLOCK_APP_ENABLED setting. If disabled, resetLockout will not be
run for that user.
Fixes: 138269776
Test: Disable unlocking for apps, get locked out, enter password.
Lockout is reset now.
Change-Id: I5d7bf3abbac7c8982595d5733464a887ab5184ab
This change completes the refactor to enable multi-AIDL client support on the v2
BroadcastRadioService:
- Adds incremental updating to ProgramInfoCache as requested on ag/6922213.
- TunerSession now maintains a ProgramInfoCache as a view of the state
transmitted to the AIDL client.
- RadioModule also has a ProgramInfoCache as a view of the state
received from the HAL.
- The two classes communicate with each other to propagate changes in
filters or ProgramInfos.
This change also makes the following framework changes:
- Overrides ProgramList.Filter#equals() and #hashCode().
- Addresses an oversight from ag/6922213, where RadioMetadata#hashCode() should have been overridden.
Bug: 126887436
Bug: 121305828
Test: atest com.android.server.broadcastradio.hal2.StartProgramListUpdatesFanoutTest atest com.android.server.broadcastradio.hal2.ProgramInfoCacheTest
Change-Id: I03b0b60b30c01ed03d3a86cff105f2efe830b233
KeyguardUpdateMonitor#isUnlockWithFacePossible was returning true
when the user had disabled face unlock.
This was causing bypass to still be enabled (hiding all notifications)
and bouncer was also being delayed, even though we were not scanning.
Fixes: 134977472
Test: auth with bypass (toggling face auth setting on/off)
Test: auth without bypass (toggling face auth setting on/off)
Change-Id: I234eb303db87fe0dafa2073a9bdf819c665018d6
This cache will not be updated when device is plugged into a new port
or unplugged from the current connected device.
Test: manual
Bug: 131629012
Change-Id: I8043f51b94323471218616ab237abbde1e0777d2
(cherry picked from commit 0429af7fca7ca7191c5ea4987c00da97d1a7877c)
When OneTouchPlay is called, client side wants the current device to
stream its internal source. But this internal source could be Youtube or
Netflix or pure HOME screen. HDMI framework won't be able to tell the
difference here. We should leave this activity switch responsibility to
the client side.
Test: manual
Bug: 131601411
Change-Id: I55afec05462394fbb004a3037bec59ae0a78018e
(cherry picked from commit c7a701ef9a3cbc07afc75efdf9d2a80f5cb82305)
resetLockout may take longer on some devices, causing FaceSettings
setActiveUser to be overwritten. To be safe, invoke updateActiveGroup
whenever user-specific functionality is invoked from the upper layers.
Ideally setActiveUser + operation should be atomic. In the future perhaps
we could consider changing HIDL so each method is user-aware, but for now
this is the only thing we can do.
Fixes: 136264301
Test: Set up work profile on device, repeatedly do the following
1) Go to settings, enroll face
2) Back out, go back in, delete face
3) Enroll face
4) Delete face, go back out
Change-Id: Ic32587cd4613f2bfd71171df6b69fe6028812ca8
