This is to enable landing the SysUI driven PiP animation without BLAST. Without
BLAST we can't support multi container sync, multi buffer sync, etc, but we can
support the same sort of synchronization we've supported before. Let's recall how
the old PIP animation works: At the end of the enter animation, or the beginning
of the leave animation, the Surface changes size (When the Windowing mode changes).
We detect this size change deep in the guts of WindowStateAnimator, and when
we detect that we are called from "relayoutWindow" defer a transaction changing
the PIP scaling factors. This approach is we simply allow SysUI to set a pending
Transaction on a task via the WindowContainerTransaction API. The next BASE_APPLICATION
window to resize in this task will consume this transaciton, and defer the transaction
until the frame in which it resizes.
Bug: 139371701
Bug: 139371701
Test: Manual test with pending SysUI branch
Change-Id: I1e757d87e2f276db626de00685b0432508ac6d62
Only jobs watching for changes to EXTERNAL_CONTENT_URI for Images and
Vidoes will get exemption for jobs.
MediaScanner will scan and insert an entry under each of these URIs
for respective file types.
Test: atest com.android.server.job.controllers.JobStatusTest
Bug: 148887841
Change-Id: I6f9a07d2c0f06c002929056891187f22a6e87e21
Make obtaining a visual service from non-visual Context instance
report a strict mode violation and print the stacktrace.
Make calling getDisplay() throw an exception if called on an instance
that is not associated with a display. For existing usages introduce
a new internal method that does not perform the verification until
the usages are properly fixed.
Bug: 128338354
Test: StrictModeTest#testIncorrectContextUse_GetSystemService
Test: StrictModeTest#testIncorrectContextUse_GetDisplay
Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
JobParameters.getReasonName was only used internally and marked as
deprecated in favor of getReasonCodeDescription. There wasn't a clear
reason for having both methods, so this removes the deprecated method
and changes the users to use the recommended method.
Bug: 141645789
Test: Check output of `adb shell dumpsys jobscheduler`
Change-Id: I09923ef38e29476d48700fd04ad9cfae29b39878
am skip reason: Change-Id I207c446108afdac7ee2c25e6bbcbc37c4e3f6529 with SHA-1 3e63df535a is in history
Change-Id: Iac17ca3df5826eb235fbc7ef02c0a5de4f06f44e
As tracked in Bug 28750507, InputMethodManagerService#onSwitchUser()
is known to be slow, and the direct reason of the UI jank in the
launcher discussed Bug 139806621 is that #onSwitchUser() is running as
part of IMMS#startInputOrWindowGainedFocus() that is called as a sync
IPC from the UI thread of the launcher. Note that this is a
relatively new behavior that was introduced in Android 10 to support
per-profile IME mode (Bug 111083076). So users shouldn't see this code
path unless the device is running on Android 10 with work profile
enabled.
What this CL does is removing that direct code path from
IMMS#startInputOrWindowGainedFocus() to #onSwitchUser() by introducing
a new pending result
InputBindResult.ResultCode.SUCCESS_WAITING_USER_SWITCHING,
which means
IMMS is now performing user switching and cannot start input session
right now, but it will call the client back when the IME becomes
available for the target user.
Note that InputMethodManager is already able to handle this kind of
pending state, where IME is not yet available, since we already have a
similar pending results as follows.
* InputBindResult.ResultCode.SUCCESS_WAITING_USER_SWITCHING
* InputBindResult.ResultCode.SUCCESS_WAITING_IME_BINDING
One remaining concern is that when IMMS#switchUserOnHandlerLocked() is
running with holding the giant lock (IMMS#mMethodMap), thus it's still
possible that IMMS#startInputOrWindowGainedFocus() can be blocked
because of lock contention, which eventually blocks client's UI
thread. Although its chance wouldn't be that high, in order to tackle
that scenario we need to pursue different approaches such as:
* Further optimize IMMS#startInputOrWindowGainedFocus() to reduce the
likelihood of lock contention. This isn't a perfect solution for
this particular case but it's still worth doing. Possible
candidate of optimizations are:
* Bug 28750507: optimize IMMS#switchUserOnHandlerLocked()
* Bug 149864769: off-load Context#unbindService()
* Reconsider the use of giant lock.
* Redesign the current "startInput" protocol as part of our on-going
effort to redesign IME focus handling protocol (Bug 141738570)
e.g. can we completely make IMMS#startInputOrWindowGainedFocus()
async IPC?
Bug: 139806621
Fix: 144291210
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: Manually made sure that IMMS#startInputOrWindowGainedFocus()
isn't blocking Launcher's UI thread when swiping home.
1. lunch aosp_coral-userdebug && make -j
2. Flash the image
3. Open the system settings
4. System -> Gestures -> System nagivation
5. Select "Gesture nagivation"
6. Install Test DPC.
7. Enable managed profile with Test DPC.
8. adb install -r \
$ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
# deal with dex2oat
9. adb shell cmd package compile -m speed \
-f com.google.android.inputmethod.latin
10. adb shell cmd package compile -m speed \
-f com.android.inputmethod.tools.edittextvariations
11. adb shell cmd package compile -m speed \
-f com.google.android.apps.nexuslauncher
12. adb root
13. adb shell setprop pm.dexopt.disable_bg_dexopt true
14. adb reboot
15. adb shell am start -u 10 \
-n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
16. Tap the first edit text on the EditTextVariations
17. Make sure that AOSP Keyboard is shown
18. adb shell am trace-ipc start
19. external/chromium-trace/systrace.py \
gfx freq am wm sched binder_driver view \
-a com.android.launcher3 -o binder.html
20. Swipe up the home button
21. Hit the enter key to terminate the systrace.
22. Check the IPC log to see how much the UI thread is blocked by
IMMS#startInputOrWindowGainedFocus()
Change-Id: I5a73a66d2b8acadad9b3577ebc4c17b5a25fd011
These metrics will pull different metrics that tell the performance of the gnss subsystem.
Metrics include:
Location reports
% of location failure
Num times GPS had to first fix
Mean time to first fix on signal
Num position accuracy logs
Mean position accuracy in meters
Num top 4 Cn0 messages
Mean top 4 average Cn0 (signal quality)
Num L5 top 4 Cn0 messages
Mean L5 top 4 average Cn0 (signal quality)
Num Satellite status messages received
Num of Satellites used in fix
L5 Satellite status messages received
L5 of Satellites used in fix
metric_id: 1111
gauge_metrics {
data {
bucket_info {
atom {
gnss_stats {
location_reports: 12
location_failure_reports: 3
time_to_first_fix_reports: 2
time_to_first_fix_milli_s: 43588
position_accuracy_reports: 9
position_accuracy_meters: 112
top_four_average_cn0_reports: 31
top_four_average_cn0_db_mhz: 734711
l5_top_four_average_cn0_reports: 1
l5_top_four_average_cn0_db_mhz: 21500
sv_status_reports: 1015
sv_status_reports_used_in_fix: 100
l5_sv_status_reports: 7
l5_sv_status_reports_used_in_fix: 0
}
}
elapsed_timestamp_nanos: 537249375445
start_bucket_elapsed_millis: 522186
end_bucket_elapsed_millis: 549283
}
}
}
time_base_elapsed_nano_seconds: 9283624934
bucket_size_nano_seconds: 60000000000
is_active: true
Bug: 147910698
Test: On Device using test script and gnsslogger.apk
> make statsd_testdrive
> ./out/host/linux-x86/bin/statsd_testdrive <ATOM_ID>
Change-Id: I92461eb8533ec810bb67d76a25931295cfa1efbd
This change adds permission checking to ensure that the following
conditions are enforced in order for apps to receive the owner UID:
1. The app must be the owner of the network
2. The app must hold the FINE_LOCATION permission/appop
3. The user must have their location toggle enabled.
Bug: 142072839
Test: atest FrameworksNetTests
Change-Id: I7a981a82f1219828ee89c8c96eb9d2efd153377f
When testing HID devices, it was assumed that the bus used would always
be bluetooth. This caused USB hid tests to fail. This patch fixes this
issue by adding a "busType" parameter to the test register file. This
can be either "bluetooth" or "usb" at this time. This will break any
hid test that does not specify a busType.
Cherry picked from pa/1549664.
Bug: 136263708
Test: atest CtsHarwareTestCases
Change-Id: I44cda52505110227fa5262994d0cfe59ecb8763d
Add default values for 5g upstream/downstream bandwidth
Update default values on NR frequency changed
Config to use LTE values for upstream and 5G for downstream on NSA
Resource overlay for modem predictive/instantaneous bandwidth estimates
Test: atest FrameworksTelephonyTests
Bug: 149032132
Bug: 149032474
Bug: 149032786
Change-Id: I70e95e98c871ba3fdc2e94de9504eafe247619c9
am skip reason: Change-Id I4f4e1f698bf883e6eaf80959f3592562015c70f5 with SHA-1 e77c1664ec is in history
Change-Id: I423d231f5391db54bfd478b73639a3291d3db905
Add native thermal manager API of thermal mananger service into
libandroid. Export Thermal API as NDK library.
Bug: 137151587
Bug: 136285293
Test: build, atest thermalmanager-test atest CtsThermalTestCases
Change-Id: Ia49fb2133624ffcd6168af804ae612ef2bb190f2
Change from showing a toast to a notification.
Bug: 136219221
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerApi29Test.java
to trigger the notification.
Change-Id: If22a72fb5a70b14d0b424fbcfe6d1e5c70f2a34d
There may be policy critical apps that must not be suspended by the
user in a managed profile. The owner can now use either of the following
to block suspension of apps:
- DISALLOW_APPS_CONTROL: Blocks suspension of all apps in the user
- DISALLOW_UNINSTALL_APPS: Blocks suspension of all apps in the user
- setUninstallBlocked: Blocks suspension of a given package.
The same also block any of the DistractionRestriction to be set via
PackageManager#setDistractingPackageRestrictions. This is to make sure
the apps can still show notifications.
Since the owner should have the final call, these do not block the owner
from adding app suspensions itself. Whenever either of these are set,
any app suspensions that were not originally added by the owner are
lifted immediately and any distraction restrictions that were added are
removed.
Also, clearing restrictions and suspensions if an app with SUSPEND_APPS
permission is disabled. Even though it is expected that UI not allow
such an app to be disabled, it is hard to enforce across all device
implementations. And a missed edge case would lead to permanently
unusable apps on the device.
This change also fixes a bug where any DistractionRestrictions set
weren't cleared on suspending app data clear.
Test: atest GtsSuspendAppsTestCases
Bug: 144826981
Bug: 145735990
Change-Id: I81a492e1d07a8cc9aeb0acd7e5142826824a42ae
