There is still confusion about the scope of the
KEY_CARRIER_NAME_OVERRIDE. This CL further clarifies
that the carrier, for purposes of this string, is the
service provider. Thus, the CARRIER_NAME_OVERRIDE will
still be subject to SPN display rules.
Note: to use this override in scenarios such as roaming
where the display rules may not choose the name of the
home operator (and thus not choose this override), a
service provider may choose to use other flags such as
KEY_FORCE_HOME_NETWORK_BOOL and
KEY_SPN_DISPLAY_RULE_USE_ROAMING_FROM_SERVICE_STATE_BOOL
to achieve the desired display behavior.
Bug: 77461054
Test: none (docstring-only change)
Merged-In: Id866df7ef9ce593de1f9d31d2556af4bfc766a8e
Change-Id: Id866df7ef9ce593de1f9d31d2556af4bfc766a8e
(cherry picked from commit 178020a2f8c7710c90a66793176fae33108f9c15)
Clarify that the caller has to wait for onServiceAdded callback before
calling BluetoothGattServer::addService again.
Bug: 72717069
Test: Compile
Change-Id: I20b031c724ba64bfd71cf10e58e587f69e4a2555
Bug: b/70351683
Test: m clean && m check-android-test-base-api
and compare the old and new stubs.jar using md5sum.
Change-Id: Ia9273016c4d3472888f970cbddf0ed85c0501eb3
Stubs libraries android.test.mock.stubs and
android.test.mock.stubs-system are now built in Android.bp.
(Note that API check and update are still done in Android.mk)
As a good side effect, this allows android.test.runner[-minus-junit]
libraries (that are defined in Android.bp) to be built with the
android.test.mock.stubs instead of the runtime library
android.test.mock. This in turn allows us to prevent java:sdk ->
java:platform dependency also in Soong, because the runner libraries
were the only violators.
Bug: 73829976
Test: m -j android.test.mock.stubs android.test.mock.stubs-system
Test: m -j checkapi
Test: m -j update-api
Merged-In: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
Change-Id: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
(cherry picked from commit e649b8066c3385ba0b667a79d378402b15ef3127)
PlaybackActivityMonitor.mPlayerLock:
android.media.MediaPlayer.release()
> android.media.PlayerBase.baseRelease()
> synchronized (mLock)
> com.android.server.audio.PlaybackActivityMonitor.releasePlayer()
> synchronized(mPlayerLock)
and:
com.android.server.audio.PlaybackActivityMonitor.unmutePlayersForCall()
> synchronized (mPlayerLock)
> android.media.PlayerProxy.setVolume()
> android.media.PlayerBase$IPlayerWrapper.setVolume()
> android.media.PlayerBase.baseSetVolume()
> synchronized (mLock)
playerSetVolume()
Since system_server can have its own players, the calls to
AudioService from PlayerBase can be synchronous, hence the
deadlock.
The fix consists in never holding the lock in PlayerBase
while calling into AudioService.
Refactor the playstate update into a method used for
start / stop / pause.
Bug: 72294559
Test: see bug
Change-Id: Ib41045de124683a7484184cf63577bd2412d1362
This API should only be used for testing purpose e.g., CTS/GTS/SL4A
By overriding carrier information, we could force a particular carrier id,
carrier's config, but also any country or carrier overlays to be loaded
when using a test SIM with a call box.
Bug: 72332597
Test: atest CtsTelephonyTestCases:CarrierIdentificationTest
Change-Id: Icd5804375ef9334c9f6c382cc6a774b9c9c15213
(cherry picked from commit 5b509b81a0d5b14148745368b153dc6b8d4482ac)
Merged-in: 5b509b81a0d5b14148745368b153dc6b8d4482ac
Bug: b/70351683
Test: m clean && m check-apache-http-legacy-api,
and compare the old and new stubs.jar using md5sum.
Change-Id: I0035837aef48a76e40a2c723c2adce3ff129ad28
Merged-In: I0035837aef48a76e40a2c723c2adce3ff129ad28
Registering for carrier config changes can deliver a sticky broadcast
and can cause Tethering to think something has changed and reevaluate
provisioning status, even though this has been checked before it
entered tethering mode alive state.
Additionally, move the provisioning_app{,no_ui} resources into the
TetheringConfiguration, if for no other reason than now we can log
it in .toString().
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
- manual USB tethering toward WiFi works
Bug: 69565814
Merged-In: If254326e892b78ef9daf620f829c1def136d695c
Merged-In: I288093a1d76566e72d4889d92c7aedafc318c8b6
Merged-Id: I01c71fd971a4683bb2b6d14825d36f24a04d88a8
Change-Id: I01c71fd971a4683bb2b6d14825d36f24a04d88a8
(cherry picked from commit 1b450e3eb9106a9cc73dfc144d275141dd5017ef)
This is the "Emergency Info" screen available from the lock screen.
It requires the CALL_PRIVILEGED permission in order for it to be able to
place emergency calls. This can occur if a user adds an emergency number
to their emergency contacts.
Test: make checkbuild
Bug: 76086838
Change-Id: I76e8318c5c05bbbbdf02d2c6951f742c3bd67ea6
* changes:
HIDL: add APIs used by subclasses to SystemApi
Update HIDL-related documentation.
Add remaining missing HIDL SystemApi methods.
HIDL: reportSyspropMethod -> enableInstrumentation
Allow HIDL to be used in priv-apps.
Relies on events sent from netd in aosp/578162.
Test: Added tests to ConnectivityServiceTest. Added a new test
class DnsManagerTest. Built a simple app that appears to
receive onLinkProperties events correctly upon manual changes
to the private DNS settings on a Pixel.
Bug: 71828272
Change-Id: I68665aaf74b7d59182cc6f9586b80b55b0dfe427
This required advancing the IpManager to IpClient refactoring
(Bluetooth used IpManager and friends). Most importantly, the
Bluetooth code used WaitForProvisioningCallback, so this is
moved into IpClient proper now. Also: some more renaming
cleanup.
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
Bug: 62476366
Bug: 72663849
Change-Id: I9eee2a9d5c31cdd48a054a7edc3403584efb1864
Registering for carrier config changes can deliver a sticky broadcast
and can cause Tethering to think something has changed and reevaluate
provisioning status, even though this has been checked before it
entered tethering mode alive state.
Additionally, move the provisioning_app{,no_ui} resources into the
TetheringConfiguration, if for no other reason than now we can log
it in .toString().
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
- manual USB tethering toward WiFi works
Bug: 69565814
Change-Id: Ib8b2620ce44c55e5eb0afd3f00f3f5aa4fc8a593
The RELEASE field has no guaranteed internal structure and developers
should not attempt to parse it.
Test: no code changes
Change-Id: I0ea3ab5ba5dd4cc733feb62725cf7c62c00c857b
Moves this out of ConnectivityService and into each NetworkMonitor
(where it's more self-contained).
Test: as follows
- builds, flashes, boots
- runtest frameworks-net passes
- manual testing with working and non-working hostnames behaves
somewhat (but not entirely) as expected, and not always quickly
Bug: 64133961
Bug: 72345192
Bug: 73872000
Bug: 77140445
Change-Id: Ic4322af3cb49149f2d975cb31f54b2ac7927f907
