today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
(cherry picked from commit 288b71c8c1)
Merged-in: I1b750751148925b4a7bd94553318907654012fc1
Moved RESOLUTION_ACTIONS from EuiccService to EuiccResolutionUiDispatcherActivity,
so that it does not need to be made public.
Bug: 137202333
Test: compilation
Change-Id: If8011bbe6af32c038f55d851acc2406eba208de6
Merged-In: If8011bbe6af32c038f55d851acc2406eba208de6
To prepare for enabling MissingNullability Metalava check this CL
works on adding missing nullability issues that metalava flags if
we tell it to flag new things since API 29.
This is not a complete CL, mostly addresses public api and
toString/equals for @SystemApi
Exempt-From-Owner-Approval: Large scale nullability clean up
Bug: 124515653
Test: make -j checkapi
Merged-In: I109260842cfc25f06e40694997fcbb4afa02c867
Change-Id: I109260842cfc25f06e40694997fcbb4afa02c867
Issue:
TextClassifierService failed to invoke the callback to send the result back to client
occasionally because the callback object may be GCed.
And thus smart selection failed occasionally, as the client doesn't get a response
back when it hits this issue. It won't fallback to local textclassifier due to the
timeout specified in TextView.
Cause:
We thought that ITextClassifierCallback is a "cross process" reference, and
so we only store a weak reference of it to avoid leak.
And it turns out that it is wrong. As soon as the weak ref gets GCed in
the service, that counts as dropping the callback. The service doesn't
know about any strong references the client has.
Bug: 138865849
Test: Try smart selection over 30 times, make sure smart action is shown
for every single time.
Merged-In: Ia9218cf67e8d67697a0fdff22c7918a55efc39ca
Change-Id: I4d89518dfff777ba5d999d9ba89d7f4cf7598e75
To determine if the CPS can get/send messages. Apparently
the IBinder can be cached in ActivityManager and onBind() is not
always called when a service is connected the second time.
Test: manual; ensure a service recieves an onsubscribe for an
active rule post requestUnbind/requestRebind
Fixes: 62584038
Change-Id: Iffe37242509f3bf26e609e6b423f3928c00156ad
(cherry picked from commit 265d093cd9)
Added Tron logging to StatusBarNotification.getLogMaker() so it will
be present in most logs about the notification.
Change-Id: I720706d37c663f2018bdfe2153ad180970166c90
Test: atest android.service.notification.StatusBarNotificationTest
Bug: 135180518
It is now simply a container for a parceled RankingMap,
which can be unparceled entirely into objects in the
listener's heap and discarded. Notification key strings are
interned (by reference into the Ranking data structure).
This should save a considerable amount of RAM:
- parceled Bundles hanging around in the listener process,
waiting to be unparceled, never freed
- a dozen copies of the notification key string
Bug: 133763354
Test: atest NotificationManagerServiceTest NotificationListenerServiceTest NotificationDataTest
Test: coretests, cts, etc.
Change-Id: I5d8ab5c8f27c70f4af7051b24608ba0d1f2dd5cd
This reverts commit 3b33a04fb3.
Reason for revert: This is crashing ExtServices on qt-dev
Bug: 132679875
Change-Id: I60b7b6b8db33585f62e108389367c74ce682b922
When the Tile is created, we don't have its actual state, so it has to
start with some default state. Between the tile being bound and the
first time the state is updated by TileService, this is the default
state.
When the Tile for CustomTile is created, set its default state to
INACTIVE. On the first update it after it's bound it will be set
correctly. This is probably less upsetting than an ACTIVE tile that
suddenly becomes INACTIVE.
Test: manual using logs to verify that the Tile is never ACTIVE when it
shouldn't.
Fixes: 132813963
Change-Id: I58bad0a2a16ca42366a5772f62fe82c74a6e2fb7
Bug: 131917369
Test: Killed launcher and confirmed the binder died callback was called and callback was removed.
Test: compiles
Change-Id: I40612aeca2de2f197e17379355e6d9e46193ae5e
TileServices#getTileWrapper created a TileServiceManager (that triggered
the binding of TileService through a Handler) and after populated the
maps with the respective tokens. As one of the keys is the
TileServiceManager, this had to do after creating it.
This created the situation that in certain cases, the binding would
happen before all the maps were populated (in particular mTokenMap but
sometimes mServices).
By decoupling the binding triggering from TileServiceManager constructor
into a separate method in TileServiceManager we can guarantee that by
the time the service is bound, the maps are populated. Also added some
guards to make sure that this method has been called and the tile has
been added.
The new method is called after populating the maps, and it would not
make sense for the TileService to be bound if the maps are not
populated.
Test: atest TileServiceMaanger TileLifecycleManager TileServicesTest
Test: atest CtsAppTestCases:android.app.cts.TileServiceTest (approx 50
times)
Test: test TileServiceTest ActiveTileServiceTest
Test: Development tiles and adding Grayscale tile work perfectly
Fixes: 124735442
Fixes: 129684780
Fixes: 130796699
Change-Id: Ie3c7277756c74551ba2e6b3e88dad4a98aeafc96
This reverts commit 02014297fd.
Reason for revert: QT SDK Finalization. Will be merged again on/after May 13th
Bug: 129975435
Change-Id: Ia054b193a982dee669630555974d2d7831fe2b50
