When starting the "App may not work in split-screen" activity which
is translucent we used to transfer the starting window, and then the
frame was drawn quickly so the starting window from the behind was
removed, leading to a black hole.
Bug: 28094732
Change-Id: I828f0ea8b0465a5a113fd76a82d33177c8faa566
There're two major problems that prevents GnssMeasurement from N-HAL from
delivering to Java-side correct:
1. The size check of HAL-provided GnssData is wrong. So native code rejects all
valid GnssData.
2. The svid's data type is different between HAL-side and Java-side. Therefore
an explicit type casting is required.
This CL fixes those problems, together with a few typo fixes.
Bug: 28169973
Change-Id: Id0c2cc120387970564b840cfcbdcb6f329c7e543
When multi-user is disabled and user button is tapped
on the keyguard, the contact app is displayed behind the keyguard.
The keyguard should be dismissed when the contact app is launched.
Change-Id: I7daa0bec84b5172e78668cc71e51955f166ede0a
(cherry picked from commit 0a334053298c988a816a754c4235ed3b01cc9cfc)
...for monitoring content providers
We now have some delays before reporting URI changes, to allow
them to batch together.
Also clean up debug output, and fix some issues with how we
were managing the content observer state.
And while I am here, fix the device idle and app idle controllers
to no longer maintain their own list of jobs, but just directly
iterate over the JobStore.
Change-Id: If3fdff23c00c2f1b99901a9be096d851562d3439
We now keep track of how long each app has been running a job
for, in 30 minute batches. If it is running jobs frequently,
we will bump down the priority its jobs run at to allow other
jobs to run before it.
Currently we count both pending and active as the job running,
which means that an app that has jobs waiting in the pending
queue will count against its abuse prevention. This could
allow starvation -- if we bump down the priority of an app's
jobs and the system is so busy continually that they sit
in the pending queue a lot -- it could never recover. But I
think that is okay... if we are really in a state where we
are continually running as many jobs as possible, we probably
have other larger issues.
Change-Id: I838aa4b5840e91df49a1e17b53188d6e4a66a6d1
There's a race condition when grabbing the VR service during
ImmersiveModeConfirmation's constructor since the window
manager allocates the ImmersiveModeConfirmation in its own
init(); vr may still be starting up at that time.
Change-Id: Ic0aa0fbf8fd087f01f4690c14e1c68f0670b0bc0
Fixes: 28159168
The view should be showing a combined list of "downloaded"
+ "visible in launcher" apps. However, if FBE and work callenge are
enabled, after a reboot the direct boot unaware apps are filtered.
Reason is that PackageUserState#isMatch assumes at least one of the flags
are specified and expects system to derive the aware/unaware flags
according to the user's lock state if neither of them is specified.
Bug: 28004355
Change-Id: Ia05edb0530023597fd219eb5e59cd71752efd279
Parts of the WebViewUpdateService code assume that there exists at
least one webview package which is available by default and is not a
fallback package. With this CL we enforce this assumption by crashing
when parsing the webview packages config file if it doesn't hold.
Bug: 28014401
Change-Id: Ib7de1f596e31bae65542a6883a9f3af54337bf1b
When the ResolverActivity makes a filter after an intent is chosen,
either for remembering last used or an "always use" choice for the
user it doesn't consider the selector in the intent if present.
This means that when a resolver activity is launched for an intent
with a selector, the selector is used for resolving preferred
activities, and for populating the list, but when the same intent
is sent again it doesn't match the filter created by the previous
ResolverActivity.
This in turn means that the user will get another ResolverActivity
even if "Always Use" was chosen the last time.
Bug: 28129216
Change-Id: I29be7010e7c890caf9789673b3c3f821ba362761
Filtering packages for boot-time post-OTA update with
UsageStatsManager idleness API is too aggressive and leaves out even
apps used heavily in the foreground. Remove for now.
Bug: 27902702
Bug: 28161327
Change-Id: I7912f9ad5d8c6206c19068a76383e370d24818db
To ensure that we don't permanently change WebView implementation if the
current package is temporarily uninstalled (e.g. when being replaced) we
don't update our persistent setting unless the user explicitly changes
WebView implementation (and on boot!).
Unfortunately this will means that the Dev Setting for changing WebView
implementation will work in a slightly less intuitive way. The
persistent setting is now persistent across uninstalls and installs.
I.e. the Dev Setting shows the current WebView implementation though
that could differ to the value chosen by the user since the package
chosen by the user could be uninstalled or disabled. In this case
installing/enabling that package would again make the Dev Setting point
to it.
However, as a compromise, we do change the setting at boot so that if
the currently chosen package is not valid we will change the setting so
that it points to the package we currently use instead.
Also ensure we only use WebView packages that are available-by-default
if no WebView packages are enabled.
Add unit test to ensure that if a user-chosen provider is uninstalled we
switch back to using that provider when it is installed again.
Add unit test to ensure we switch user-chosen provider at boot if the
chosen one is uninstalled.
Bug: 27673076
Change-Id: Icd27ae302798ebf695b9ef4bd4d5fd47fe4be02c
