RemoteException are thrown when someone invokes a binder call
but the binder calls fails due to technical reasons (the remote
process died; data sent through binder is too big etc). Right now
in LockSettingsService most RemoteExceptions are just blindly
bubbled up through the call chain. This has the issue that it
will be silently ignored if this is part of some app calling into
LSS via binder, because RemoteException cannot be propagated
across binder at the moment. To fix this, we look at each place
within LSS where RemoteException is thrown and take the following
action:
* If the RemoteException is not critical, just swallow it in place
and emit a log.
* If it's critical (LSS cannot carry on with the failed invocation):
** Rethrow as IllegalStateException (which is binder-compatible)
so it fails fast.
** Unless the surronding method has appropriate error return semantics
which can be adopted instead. In this case, swallow the exception,
return error code, and emit log.
Bug: 128831839
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/locksettings
Change-Id: I4e19b8e63a86e5477933bf21c718771e9018e718
The class is abstract and marked as a SystemApi, but there's real
way to use it while compiling against the system_sdk unless the
constructor is also public.
Test: make update-api
Test: make
Bug: 138589409
Change-Id: Id1fe158ec55b299325bfbc16ab1ea33cd53fc123
NLSs (rightly) assume that the SBN they get from
onNotification[X] calls will not be null. If it is, log and bail early.
Bug: 78279961
Test: reboot device
Change-Id: Id2bba6b15aeea2d701d92d6c63022463f0f8c1df
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
There would be an error if an InputChannel didn't be disposed before
finalized. The client InputChannel created by ViewRootImpl or SystemUI
that would also create an InputEventReceiver to receive input events, and hold
the client InputChannel, so if the InputEventReceiver is going to be disposed,
the InputChannel should be disposed as well.
Test: manual
Bug: 128679213
Change-Id: I24c16f032403e8a982a84a5e0adbfabcdc016f0f
Parent SurfaceView to a bounds layer that enforces a crop preventing it
from drawing over the surface insets. The bounds layer crop is set to the
surface insets and updated when the parent surface size changes or the
parent surface insets change.
If the SurfaceView children are reparented to another client surface
then ensure the SurfaceView relative layer info is updated correctly.
Bug: 132205507
Test: go/wm-smoke
Test: test preserve surfaces codepath with split screen and ensure relative z is preserved
Test: test surfaceview apps, youtube, maps & camera.
Test: try to repro maps pip issue described in bug
Change-Id: I14c2f7603345ad89f0af4db48150b05d8ada602a
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
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
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
