mChannel is nullable and we have to do a null-check before calling its method.
Bug: 245506600
Test: manual and atest
Change-Id: Ib739f0f66f1a2aee1b2741263e7c206341782892
This patch contains two fixes:
- Make sure mUwbManager is non-null by calling isUwbSupportedOnDevice to avoid a NPE.
- Modify AdvancedConnectedDeviceDashboardFragment, add lifecycle observer only if device supports UWB.
Bug: 244871579
Test: manual test and Robotest.
Change-Id: I78f97794a66f3fb487f067c4570899e21c254acf
The mock location app should be OP_MOCK_LOCATION allowed app, the packageOps.get(0).getPackageName()
is the first app that used the OP_MOCK_LOCATION in history, but maybe rejected.
Change-Id: I0158436dd7d2790f4e9640075bc9c8bd3422f467
Prior to this cl, we use #getPackagesForUid()
to get a list of calling package names and
pick up 1st package name in the list as target
calling package. And then go to check the
Wi-Fi permission.
This implementation is ok for most apps without
sharing system uid. However, this may not work
if the package is set with sharing system ui.
In this case, we get a list of packages
and we don't know which one is caller. So, if we
decide to choose the 1st package as our
calling package, then it could fail to pass
permission check since that package could be not
a correct calling package.
In this cl, we skip permission check for those
packages running with system uid. So, it can resolve
Wi-Fi Panel problem since Wi-Fi panel runs
on settings process(with system uid).
Test: 1. adb shell am start -a android.settings.panel.action.WIFI
2. Verify on assistant app and system ui launcher and search app.
Bug: 240531998
Change-Id: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
(cherry picked from commit 5e785a2d99)
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Bluetooth pairing is cancelled if the pairing popup is closed without
explicitly accepting the pairing. However there is no way to
explicitly accept the pairing when the local device displays for the
passkey entry or pin key entry pairing method.
As a result all passkey entry and pin key entry pairings, where the
local device is displaying the value, are cancelled after the pairing
is successful. If the BT stack has not completed the SDP search when
the pairing is cancelled after successful pairing, it may result in
removal of the bond information.
Bug: 237757124
Test: Pair with BT HID keyboard; adb logcat | grep "BTPairingController:
Pairing dialog canceled"
Change-Id: Ifdb98c16084dd811eed68469e7df5d1913c6ace8
(cherry picked from commit aa1950fd80)
Merged-In: Ifdb98c16084dd811eed68469e7df5d1913c6ace8
(cherry picked from commit d668a888f0)
Merged-In: Ifdb98c16084dd811eed68469e7df5d1913c6ace8
The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ida6513002f8fd845a385924be290b720f06c4748
When dual SIM cards with same Carrier Id inserted, authentication of
SIM base network is via default data SIM. However, SIM name shown in
Network Details is always the one inserted first.
Hence, make SIM name of default data SIM shown in Network Details
preferred to keep consistent with the one used for authentication.
Co-authored-by: Yibo Wang <yibo.x.wang@sony.com>
Test: manual test
Bug: 240732444
Change-Id: Ibd64189d6c25b5a64881a0ad9d40854df93481f4
This script has been deprecated and replaced by AyeAye checks
directly in Gerrit.
Bug: 164530987
Test: none
Change-Id: Ia1baf761e5ca6a1cef7de231d0f320cfaa7e071a
Since there is the race condition and it causes UI hides the preferred
SIM dialog. Therefore, to hide the preferred SIM dialog under the
specific condition which the user has replaced the SIM during the
SIM switching.
Bug: 238061853
Test: Manually testing. Device has the psim+esim and the esim's mobile
data on. The tester disables the esim and then UI shows the preferred
SIM dialog.
Change-Id: I01e7d60170c5053730fd3113abd914fb5c0d11c9
(cherry picked from commit 286dce6b6e)
Merged-In: I01e7d60170c5053730fd3113abd914fb5c0d11c9
Deep links on large screen devices starts a homepage activity on the
left pane, and then starts the target activity on the right pane. This
flow overrides the calling package, and the target activity can't know
who initially calls it.
Thus, we store the initial calling package in the intent, so the
Connected devices page is able to make bluetooth not discoverable when
it's called from unintended apps on large screen devices.
Bug: 234440688
Test: robotest, manual
Change-Id: I4ddcd4e083c002ece9d10aabdb4af4a41de55ce7
Merged-In: I4ddcd4e083c002ece9d10aabdb4af4a41de55ce7
(cherry picked from commit 5df14831b8)
Merged-In: I4ddcd4e083c002ece9d10aabdb4af4a41de55ce7
Default max search time (300) fails on some devices.
Test: Network scan works on OnePlus 9 after overlaying
max network scan search time to 254.
Change-Id: Ia0038fac6d2000748e0aa08fd6a53f11876728d7
