1) Add CarrierConfig to allow/disallow holding calls for emergency
calls.
2) If holding an ongoing call for an emergency call is disallowed,
define a new DisconnectCause reason to notify telecom/dialer of this
disconnect reason.
Bug: 138741228
Test: atest CtsTelecomTestCases; atest CtsTelephonyTestCases
Change-Id: I7c6a1d0f648c598111ed047fbb9c609843c6aba9
* changes:
Add new API for Telecom to send phone state
Minor style correction to avoid merge conflict
non-mainline telephony related AIDL refactor/decoupling
for oems which take telephony mainline module, all telephony related
apks will be signed with non-platform certificate. that said apks won't
be able to grant platform signature permission. Solution is to add a new
telephony protection level.
Bug: 141479803
Test: cts & manual
Change-Id: Ib3be016080d42fd76e7c131f4e44d815ce431e6e
(cherry picked from commit 45c183d201)
Merged-in: Ib3be016080d42fd76e7c131f4e44d815ce431e6e
Expose Geometry and LatLng classes as SystemApi
Expose maxWaitDuration, which is used in the cell broadcast service
geofencing logic.
Bug: 135956699
Test: make and run appcompat script
Merged-In: Iac585cd54db97c08eccc57adc9721c90aa785fcd
Change-Id: Iac585cd54db97c08eccc57adc9721c90aa785fcd
(cherry picked from commit a8ec03ebe6)
Add new API to replace Telecom's prior usage of hidden TelephonyRegistry
methods.
Bug: 141576016
Test: CTS
Change-Id: I0049f55e8eadaa144ad844026524197198700038
1. decouple IOnSubscriptionChangedListener AIDL from telephonyMainline
2. other refactor. moving APIs which will not be included in
telephony mainline to frameworks/base/core/java/android/telephony.
Moving internal classes like AIDL which will not be included in
telephony mainline to
framework/base/core/java/com/android/internal/telephony
Bug: 140908357
Test: Build & unit test
Change-Id: I9413ef758cceadd251d03f3b5ea1054cc48ef044
Merged-In: I9413ef758cceadd251d03f3b5ea1054cc48ef044
deprecate KEY_CARRIER_FORCE_DISABLE_ETWS_CMAS_TEST_BOOL. This is
only used for cellbroadcast receiver and move to resource overlay
show_test_settings
Bug: 141579944
Bug: 62016498
Bug: 141772296
Test: Build
Change-Id: I64762d9d7e5857dd2a9da1de4fa99e505a034887
These have been the cause of bugs in the past, such as b/10150258,
because it's not always obvious or guaranteed that a calling thread will
always have a looper, or that it's actually the looper you want.
Specifying the looper explicitly, even if it's just Looper.myLooper(),
makes the code clearer. Since callback APIs generally should have
Executor variants added, it might be nice to also deprecate the
constructors or options that rely on the calling thread's looper, but
since I don't have an inventory of all those I'm starting with this.
Bug: 144042891
Test: No behavior changes
Change-Id: I0e7ba80d6b89a866ea715c790dd602ef728bf5bd
