Root cause: The permission "android.permission.BLUETOOTH_CONNECT" is missed for settingsintelligence on zumapro
Solution: pre-grant the permission "android.permission.BLUETOOTH_CONNECT" for settingsintelligence on zumapro
Fix: 320409645
Test: Manual Test
Flag: NA
Change-Id: I104a0e9a7e30fc1e530ee0e9baaab3972d6a992b
Dump flag value in the construtor for easier debugging. Feature flags
are not expected to change in runtime, dumping the value once should
be enough.
Bug: 296119135
Test: manual test
Change-Id: Ie5aca2dff23e59704fb306833cde0e592b9f430d
(cherry picked from commit 9164eae7cdee032381d8bf045fbbed33f62b00bf)
This reverts commit a4a92ded54.
Reason for revert: move the conditional to bcl.mk and battery_mitigation to avoide haveing 2 versions of mk.
Change-Id: I87a0c7270960ccd4e4bb01ecf58e787defcc50b9
60257881ad
Reverting to comply with the Allocator VTS for 24Q1, do not merge to main.
Bug: 310046460
Test: VtsHalGraphicsAllocatorAidl_TargetTest
Change-Id: I47f69b046c798ea15eb48debdc55c3a7273ac007
Setting the owner of /dev/logbuffer_cpif as system to allow the
dump_modem script to read the logs as part of bugreport
Test: Tested bugreport on device
Bug: 318949647
Change-Id: I402049e9b7b42b31f6fd07e8bf3a9cafefdc6526
Signed-off-by: Mahesh Kallelil <kallelil@google.com>
Test: Various tests are done on zuma devices given which has been in
production for a while. Tests done on zumapro devices include:
- flashed a zumapro device and observed that the device boots up
successfully.
- Checking the bugreport and didn't see anything suspicious.
- Verify that there is not any sepolicy violation related to
the multiclient HAL.
Bug: 247124878
Change-Id: Iaae483761c8163a34aaeb86651e1b9f6f51dfb5a
Put build flag conditional inside bcl-aidl.mk
to handle new battery mitigation service.
Bug: 317869347
Change-Id: Ic2d781e5afbc1994fdf1a08528f4659fff929fed
Signed-off-by: samou <samou@google.com>
Revert submission 25697219-bm_enable_build_flag
Reason for revert: DroidMonitor: Potential culprit for Bug b/317869992
- verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:25697219-bm_enable_build_flag
Change-Id: Ic2be8f44e812b0486076eb2676bb2477eb065f34
The state count requirement is very specific to the case where the
signal integrity is the culprit of flaky connection. However,
there could be other cases such as bad receptacles causing data pins
to disconnect randomly.
Remove the state count requirement to cover more cases.
Bug: 296119135
Test: manually trigger the warnings
Change-Id: Ic2ae376ad6062d9930614381503f44e4a5ac760f
(cherry picked from commit 5e14ba01be9acc31d3df0f506b4287eea0bf9583)
