Voice Assistant can be disabled on a user-level. Adding this null check
prevents crash for when Assistant is enabled for the system in general but
disabled for a specific user.
Bug: 149112015
Test: Manual -- Change config_disableLockscreenByDefault to true to
emulate the environment in which Volvo observed the bug. Verify that
switching to user0 through adb shell switch-user 0 causes the same crash.
Verify that the crash does not happen with the new null check.
Change-Id: I5b8ede1e5bd8c1bc047bc6d6220b425dea8f50ea
There were a couple problems with work profile state in location. First,
we assumed that notifications sent to parent users would also be sent to
profiles but this is not true. Second we had assumed location status in
profiles was always identical to the parent user, but work profiles may
have user restrictions applied which are not present on the parent user.
The easiest way to handle these issues seems to be to expand LMS user
handling to deal with all users, rather than making various assumptions
which may or may not be true.
This also means we need to store last locations on a per profile basis.
Since we're refactoring how last location works completely, we also
removed the special NO_GPS handling for last locations. With the new
permission strings we now no longer have to exclude gnss based location
from coarsening. This lets us:
1) deprecate and remove various constants and methods use for storing
coarse locations tied to fine locations
2) substantially simplify code that calculated coarse location
This also exposed numerous bugs in the location service where we were
using the current user's state instead of the calling user's state,
which could have exposed the current user's location to other users
inappropriately.
Bug: 148798374
Bug: 146071833
Test: presubmits + manual
Change-Id: I2d3216a9fb58b73d0124d563b05de8870b70b716
Bug: 135133301
Test: AImageDecoderTest
AImageDecoderHeaderInfo_getWidth/Height return an int32_t. Ensure at
creation time that the actual image dimensions will fit in int32_t.
In today's code, this should almost never happen:
- PNGs have their dimensions limited to 1000000
- see PNG_USER_WIDTH_MAX and PNG_USER_HEIGHT_MAX in pnglibconf.h
- JPEGs are limited to 65500
- see JPEG_MAX_DIMENSION in jmorecfg.h
- WebPs' dimensions are encoded in 14 bits
- GIFs' dimensions are encoded in 16 bits
- SkBmpCodec and SkWbmpCodec require dimensions to fit in 16 bits
- SkIcoCodec uses SkBmpCodec or SkPngCodec, so their limits are
enforced
- libheif limits to a size smaller than int32_t
It might be possible for a DNG image to be larger, and some of the above
are configurable. Just in case, make AImageDecoder_create fail on such a
large image.
Change-Id: Id520dfbc0581f990c4f52cb6675e987bf71c558c
Previously, some paths through BiometricService needed to be accessible
by apps. Now that external calls are routed through AuthService instead,
we can check for the system-only USE_BIOMETRIC_INTERNAL permission
everywhere that we had been checking for USE_BIOMETRIC in
BiometricService.
In order for this to be enforced properly, we also need to move some
of the permission checks that were previously in BiometricService to
AuthService, which is now the primary entry point for applications
invoking the relevant biometric APIs.
Test: com.android.server.biometrics
Test: Manually verified functionality using support biometric demo app
Bug: 148971767
Change-Id: Ieab61276c6375b0d674f73e1833edabc8700fe74
am skip reason: Change-Id I2f250cdd53a667b2d89e84e589b0ae0bc94a8aa3 with SHA-1 c99b83b95f is in history
Change-Id: I2a423f4e9d1d8f5e008a96c8fc7719855be4ed76
am skip reason: Change-Id I7099048c126e88f75cf5bd7e779ddfe923cc1c02 with SHA-1 012223b366 is in history
Change-Id: Ica6a6bb378022eb1a2e5fcabe647d4947724dd0c
am skip reason: Change-Id If6965979b5ab15b53f8e81cad895cc2d3dc29e0e with SHA-1 af2d303621 is in history
Change-Id: I27983f9c28dbb110fec156eb6ece6c22e19b9812
The infrastructure for telephony handle caching was checked in in
ag/10255108, but disabled due to changes that needed to be made in AOSP.
This CL activates the caching.
Test: atest PhoneSubInfoControllerTest
Test: atest DcTrackerTest
Test: atest CellBroadcastConfigTest
Bug: 140788621
Change-Id: I42c829a07f9192ccbedef38e835019804eb20978
Supports initiation of a conference call
by directly adding participants to existing call
Test: Manual
Bug: 62151032
Change-Id: I4e60efafab4761ae65a460fdc6c4cacc3e233220
First we eliminate the "dropReferenceTransaction" semantic. This semantic
reparents the surface to null if the C++ object dies before release() is
called. This is a legacy semantic from before SurfaceControls were reference
counted. I point that it's unused by noting that all Java code paths
will lead to calling release() in the JNI code before dropping the last reference.
With dropReferenceTransaction gone we can remove mOwned it has no further uses.
With these gone we now remove release() all together on the native side. This
means that mClient and mHandle will only be written from the
constructor and destructor making access to them thread-safe
as long as you hold an sp<> to the SurfaceControl. This should prevent
bugs like we've had in the past about who calls release when, no one calls it!
The final question is: is removing the call to release on the Java side safe?
We still need an explicit Java binding release call so we can drop the native
reference in a timely fashion. This then breaks down in to two scenarios:
1. We are the last reference
2. Someone else holds a reference
If we are in the first scenario, then calling release or not is equivalent to just
dropping the reference. If we are in the second scenario, calling release()
will be unsafe. Because we could at any time overwrite mClient/mHandle after
the other ref holder had verified it was null.
The main path I know of for how native code could acquire a second reference
to the JNI owned SurfaceControl is via Transaction::registerSurfaceControlForCallback
then if we release while Transaction::writeToParcel is running, it will inevitably
segfault. This change could lead to the extension of life-time for SurfaceControl.cpp
objects while the Transaction containing them is alive (but previously the
SurfaceControl.cpp proxy would have been released). I also argue this is safe since
the sp<IBinder> itself was reffed in another place in the Transaction so the lifetime
of the actual server side resource isn't extended at all. Only the lightweight proxy
object.
Bug: 149055469
Bug: 149315421
Test: Existing tests pass.
Change-Id: Ibd4d1804ef18a9c389c7f9112d15872cfe44b22e
