If someone setup a invalid subscription plan with
subId:INVALID_SUBSCRIPTION_ID. (For instance, test code).
It will cause NPE when WiFi connected because WiFi network doesn't own
subscriberId. (Happened on API call: buildTemplateCarrierMetered with
null subscriberId.)
Fix:
1. Add null check before calling buildTemplateCarrierMetered
2. Add invalid subId check before saving subscription plan.
Bug: 191938713
Test: atest -c NetworkPolicyManagerServiceTest
Change-Id: I835a7b8890035975e187ca0a70ec2f30ca56455a
Merged-In: I835a7b8890035975e187ca0a70ec2f30ca56455a
When the user presses the power button on an unlocked device, we play a
transition animation into AOD. This animation has two parts: a black
scrim that collapses around the power button, followed by the appearance
of the AOD UI. For performance reasons, we don't mark the state of the
status bar as KEYGUARD until both sections of the animation finish. This
causes a bug with silent notifications: if the user's only notification
is one or more silent notifs and they press the power button, the AOD
animation will play, but in the moment that the AOD UI needs to appear,
the status bar is not yet in the KEYGUARD state. This means that the
silent notifications will not yet be hidden, and so the lockscreen will
use the "small" clock treatment rather than the "large" clock treatment.
A few ms later, we will enter KEYGUARD state for real, the notifs will
be hidden, and the small clock will revert to the large clock, causing a
flicker.
This change creates a new concept in StatusBarStateController: an
"upcoming state". When we start the animation, we mark our upcoming
state as KEYGUARD (without changing the actual state). At the same time,
we modify NotificationViewHierarchyManager (the thing in charge of
hiding silent notifications) to check the upcoming state rather than the
actual state.
To avoid the upcoming state desyncing from the actual state, setting the
actual state causes the upcoming state to be cleared.
Bug: 190344677
Test: manual
Change-Id: I7b3613d242516440ba2e86aa1a936aef62a53d6a
- If we set a fixed height for the illustration and automatically
scale the width of the illustration, the size of the background
layer will be different from the size of the illustration. To
fix this problem, we must make the background layer the same
size as the illustration and automatically scale.
- Update the size of background to 412x300.
- Update the layout of frame's child views to wrap_content.
- Update the padding of frame to 16dp.
Bug: 190810977
Test: robotest and see the UI
Change-Id: I0422f91c24860154fea7c766d5670c314d62bebb
This CL logically reverts recent CLs [1][2][3][4][5][6][7][8][9] to
switch back to the previous sync IPC approach in IInputMethodManager
except for the following two IPCs.
* reportPerceptibleAsync
* removeImeSurfaceFromWindowAsync
Reason for revert:
We need more time to understand its performance implications.
[1]: If4b40244a2e0e3b11c38c1da9340ba8e5166ad64
b9590fa1e1
[2]: If79e063641a01b325c63eb9f871f5b992d7c0b72
5a5648dcb5
[3]: I1547b98b2aacf764e33aadc9ab784f2013f58f2f
d833f0dab4
[4]: I646ef4ae0570aae1812ea267f309441fdec6938d
38fd020616
[5]: Iaa63e01453da4ff0e3f446eac036b3be3180cb73
4a820ccc41
[6]: Id516fd1c961f43ac3e139c88d7ed004c188d458b
0a32fd21ef
[7]: Icb396ae5d74060af69c4ecb16723b2e37b9f2067
c4663ba6a9
[8]: I3eafbc28ed3acf3ba859885bf201cb06b3149b94
f226a79fee
[9]: Ic584203c1221fbae17f5e2d8f09e3992df061646
5e2d9f271d
Bug: 163453493
Bug: 174892351
Fix: 190486491
Test: atest CtsInputMethodTestCases
Change-Id: If16ac0de536d9089eb04f6e07b1ee47378124658
Merged-In: If16ac0de536d9089eb04f6e07b1ee47378124658
The issue occurs when the application proc state changes
rapidly, e.g. from FOREGROUND to BACKGROUND to CACHED.
The original code would sometimes attribute the time slice
to the wrong proc state.
Bug: 192550308
Test: (on cuttlefish) atest --rerun-until-failure 300 FrameworksCoreTests:com.android.internal.os.BstatsCpuTimesValidationTest -- --abi x86_64
Change-Id: Ic22bbfa3aae701014fc016ec9e2d32b1c528d462
Apps should not be allowed to programatically check whether a given
package is installed on the current device.
But, currently, isAutoRevokeWhitelisted allows app to do so by invoking
isAutoRevokeWhitelisted for a package name, then checking for an error:
- if NullPointerException is thrown, the package does not exist, or
- if SecurityException is thrown, the package exists.
The NullPointerException occurs in PermissionManagerService on the line:
final int packageUid = UserHandle.getUid(userId, pkg.getUid());
^ null
The solution is to:
- avoid a NullPointerException by moving the above line of code down
below where we've already null-checked 'pkg' (checkAutoRevokeAccess),
- return false when the target app doesn't exist, and
- return false when the calling app doesn't have permission to access
the target app (via filterAppAccess).
Bug: 186404493
Test: manual
Change-Id: Ibae43d92b8eee24a0e56f08c878a7fe793833287
This change ensures that the UnderlyingNetworkListener receives
location-sensitive fields in order to proxy the location sensitive
fields in the VcnTransportInfo
Bug: 192587440
Test: manual tests
Test: atest FrameworksVcnTests
Change-Id: Id42ae2e373d909424c3f213412ea4731ee01fa2b
