There will be more calls to *ForUser() APIs over time by mainline modules.
Let's avoid creating new objects in common cases.
Bug: 142134660
Fix: 140429319
Test: atest cts/tests/app/src/android/app/cts/UserHandleTest.java
Change-Id: Ie71850bd08a8d9831232ddb40807ae49e3a56841
The java.io.FileDescriptor object has a poor definition of ownership,
which can result in obscure use-after-close bugs. Instead, APIs should
return or accept ParcelFileDescriptor instances.
Bug: 130209137
Test: manual
Change-Id: Ifb3dd53dc138ec47f416f2d4b46c4668bc8ee1d8
The zygote handles requests by polling on its sockets, and then handling
one request for each active socket. However, it does so by reading from
a socket via a BufferedReader, which means that if multiple requests are
written into the socket before the zygote gets a chance to read them,
the zygote reads multiple requests into its BufferedReader, it handles
one request, and then never responds to the request that's buffered,
leaving its client stuck waiting for a response that will never happen.
For most requests, this can't happen, because the client will wait for a
response to be sent from the zygote before sending another request, but
this isn't true for --boot-completed until this patch.
Bug: http://b/141767463
Test: forrest runs of apct/text/text_native_test-cloud-tf
Change-Id: I8b7a80abfd9443d98f8cf5aedb7669b82c0cb84a
Initial user creation is slow because the system must prepare per-user data (like storage and
permissions) whose cost is proportional to the number of pre-installed apps. On automovive's
reference implementation, it can take more than 10s, which is a bad user experience.
This change lets OEMs pre-create some users , so that high initial-creation cost is "paid" during
the initial boot. On automotive, it improves the creation of an additional user (or guest user)
in about 7s (from ~17s to 9s).
Bug: 111451156
Bug: 132111956
Bug: 140750212
Bug: 140868593
Test: manual verification
Test: atest FrameworksServicesTests:UserControllerTest#testStartTemplateUser_background
Change-Id: I81de1b5376dc9c42b63be8853d7204c88826401f
When a developer has requested "sm set-force-adoptable", adjust the
return value of hasAdoptable() to reflect it. This ensures that we
run relevant CTS tests.
Bug: 141540368
Test: none
Change-Id: I483c0df1a574021eafcd1663d41a2f4097fe986a
This is a preparatory work for mainline. since Intdef is hidden, so we
have to move some annotations (applied in SDK/system API) to a separate
annotation class and having other module statically link to it.
TODO: include telephony annotation in framework-non-updatable-sources
Bug: 140908357
Test: Build
Change-Id: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
Looper traces handler calls by calling Handler.getTraceName(), which when used with PooledLambda
ends up showing just:
"android.os.Handler: com.android.internal.util.function.pooled.PooledLambdaImpl"
That name doesn't help understand what's the real bottleneck, and even worse, could let people
think it's the PooledLambda who's causing it.
Which this change, it will display names like:
com.android.server.appop.AppOpsService$Lambda
com.android.server.wm$Lambda
Fixes: 141172840
Test: manual verification (neither PoolLambda nor Message have unit tests)
Change-Id: I80d2158a50a644b10f3724fb42a4a9c2aee63ae9
This will allow us to receive values from server flags and store them
in persist.sys.fuse without risking flag consistency during a boot.
Test: manual - flip persist.sys.fuse both ways and make sure FuseDaemon
works as expected.
Bug: 140803239
Change-Id: I4424770926f98bccda06dab6a447ee5637e5eb6e
When Zygote forks a process with the MOUNT_MODE_PASS_THROUGH
flag, bind mount the pass_through path into /storage for the
process, allowing the process to bypass FUSE.
Bug: 140064376
Test: cat /proc/<pid of app with pass_through flag>/mountinfo shows
the lower fs bind mounted directly on /storage
Change-Id: Ia212c2c71ecfdc1629739ca8af171f332ccfca72
This is a violation of layering (LSS is considered a lower level
component than DPM) and source of deadlock due to lock inversion.
This change tries to remove most of the direct calls into DPM from
LSS. After this, there will only be a handful non-critical invocations
remaining:
1. DPM.reportPasswordChanged()
This is always called on a handler thread so it's OK (LSS does not
hold any hold while calling out). Consider this as a (asynchronous)
broadcast.
2. DPMi.reportSeparateProfileChallengeChanged()
This is now moved to the handler thread, similar to
DPM.reportPasswordChanged().
3. DPMi.canUserHaveUntrustedCredentialReset()
This is still a violation but it will soon be removed as we
remove the caching of syhnthetic password alltogether (deprecating
old resetPassword()). So I'll leave it for now.
Test: atest com.android.server.locksettings
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest MixedDeviceOwnerTest#testResetPasswordWithToken
Bug: 37090873
Bug: 141537958
Change-Id: Ie44cb418ab255bd016c5dd448674beabd362b74c
