UserManager may not have been started yet, so discover users by
looking at filesystem.
Fix disabled bug where default should be "false."
Test: builds, boots
Bug: 36794413
Change-Id: If91fd27b955175072228a93aab4b8ac3b27df0bf
It's confusing, but f_bsize is not the value you're looking for; the
real block size is f_frsize. Fix all those bugs.
Also, the vast majority of clients are interested in the usable
disk space, not including reserved space.
Test: builds, boots
Bug: 36840579
Change-Id: Ib1470389afd49c14cab62282ec1e978ebb2c4791
Previously FuseAppLoop instantiates Runnable for each command, which
causes lots of instantiation and GC.
Test: CTS
Bug: 35229514
Change-Id: Ifea098e5ade044b1a954c0b714c5b3270a95cd1a
Some system services are offering package usage data through both
public/system APIs and through dump() calls. In principle, usage
data hould always be protected with PACKAGE_USAGE_STATS, so start
enforcing that. (Otherwise if a user blocked PACKAGE_USAGE_STATS
access to an app, that app could still obtain the data via dump()
if they held the DUMP permission.)
Bottom line, let's respect the user's wishes.
Protecting the entire output like this is pretty blunt, but future
CLs can add more nuance to the output if desired.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: I46173562713bea7d89e12a4313c78eb52ea8d77d
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
Adds a new filter that includes downloaded and launcher apps, as well
as instant apps, and ensured that instant apps do not appear where
they previously were not expected (downloaded and launcher apps).
Test: Added testing for the existing filter and the new one.
Bug: 36515324
Change-Id: I7ef94442bae14ee18d4b4d70f04f9bf62af9eff8
(cherry picked from commit a4e0356ed48021c353a6964ec8ea4c6b55006282)
* changes:
Bluetooth 5 advertising duration refactoring (4/4)
Bluetooth LE Advertising minor improvements
Fix advertise data size estimation
Hide periodic scanning
Bluetooth API spelling fixes ("wether" -> "whether")
Expose both duration and maximum extended advertising events to limit
advertising time.
Test: manual
Bug: 30622771
Change-Id: I44df300995ef985526b93f8c24389775720b3432
(cherry picked from commit 5a355610fe6ac0460f7130375de97b4d7bae7ba4)
This patch adds some additional error checking for the advertising set
parameters, and some more comments.
Test: manual
Bug: 30622771
Change-Id: I87bd44f4179ef63694ad3ed656dc2acc52e40f1e
(cherry picked from commit f4ed33f5fa6ffa3bda6faff773a3fb90b16a760c)
UUID in service data field can be 2, 4, or 16 bytes long.
Test: manual
Bug: 36553478
Change-Id: Ib5ba2d16065496ca311e8642a15a7ea6bc84d4c1
(cherry picked from commit 72e9e9f81504559ca18b71358203b1b39d9f0581)
The system previously overrode the display size for a specific scope
(task/activity/etc.) by setting the associated Configuration's
screenWidthDp/screenHeightDp. This leads to two issues. First, the
conversion of screen size from pixels to display independent pixels
and then upconverting later on leads to rounding errors. Secondly,
the screenWidthDp and screenHeightDp values account for insets, such
as the status bar. These however are not reflected in the display
size when returned from Display#getMetrics/getSize.
This changelist addresses the issue by adding a Rect value to
Configuration which stores the app display bounds. This is always set
at the display level and overridden as appropriate. As the proper
app insets are accounted for at the root configuration, all overrides
(outside of specific exceptions) are the result of the intersection
between the requested bound and the parent bound.
Change-Id: I2c4fcd0bee92af12aabbca258de05b4ec061d0e1
Fixes: 34338931
Bug: 36812336
Bug: 36676979
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerDisplayTests
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
WindowFrameTests#testLayoutNonfullscreenTask and
sizes because test assumed that frame for window was always
bigger than screen size. Now we calculate all frames relative
to real display size.
TestWindowManagerPolicy used in WM unit tests reported incorrect
value from rotationHasCompatibleMetricsLw(), which lead to
DisplayContent#mAltOrientation set to "true" after any rotation
and resulted in shrinked display metrics.
DisplayContentTests#testDefaultDisplayOverrideConfigUpdate was
not restoring the config applied to default display because
it was trying update values in config from non-empty to empty,
which is considered a no-diff.
Test: com.android.server.wm.WindowFrameTests
Test: #testCalculatePolicyCrop
Test: #testLayoutNonfullscreenTask
Test: com.android.server.wm.AppWindowTokenTests
Test: #testLandscapeSeascapeRotationByApp
Test: com.android.server.wm.DisplayContentTests
Test: #testDefaultDisplayOverrideConfigUpdate
Change-Id: Ia0ed46307f67f6b47859209ebcf13253b59b8002
It tooks 10 years, but better late than never!
Bug: 32984164
Test: Compiled documentation and checked in Chrome
Change-Id: I6dfd7fba6d3077f8c774b203589083bdbc15f9d2
In BidiFormatter and AndroidBidi, treat emojis new to
Unicode 10.0/Emoji 5 as bidi class ON.
Test: Manual
Bug: 32952475
Change-Id: I1a40c6ee2b6e9d91c9d1e5b64faca6d16301fe93
(Finally) introduce a new ServiceConnection callback to
tell you when the binding has died. This allows you to robustly
have a weak service monitoring, and also is an easy way to find
out about breakages due to app updates etc.
Also clean up some debug output.
Test: moved to own suite and ran them.
Change-Id: I526cc00816c384fa9eb1312b92406f38085cbff9
- This CL has two main changes:
1) It modifies the activity multi-window and picture-in-picture mode
changed callbacks to provide the configuration of the activity with
the mode applied.
2) It modifies the order in which the multi-window and picture-in-picture
mode callbacks are made, to ensure that when going in and out of
picture-in-picture: first PiP, then MW, and then the config change.
- Previously, the ordering of the two callbacks was inconsistent. When
calling moveActivityToPinnedStack(), we reparent the task into the pinned
stack (triggering the picture-in-picture mode change), followed by the
resize animation (causes configuration changes). Inversely, when we
expand the task to fullscreen (and not just remove it), we run the
animation first, which resizes the task to the final size (causes
configuration changes) then reparent after the animation completes
(triggering the picture-in-picture mode change).
In this CL, we ensure that for both the transition in and out of PiP, we
defer to the bounds animation to trigger the PiP mode change. Normal
calls to reparent or adding a new task are unchanged. When the PiP
mode change is called from the animation, it provides the final target
bounds which we use to calculate the target configuration of the activity
for the callback. If the bounds animation is interrupted, an update will
also be scheduled if we change the fullscreen state we are animating to.
To work around the issue where we are scheduling MW/PiP mode changes in
both the animation and the configuration change, we also now keep track
of each state internally in the ActivityRecord.
Bug: 36099777
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testConfigurationChangeOrderDuringTransition
Change-Id: I03513bc3a4d4a72c250983f22f079ce9d7a2cb40
Signed-off-by: Winson Chung <winsonc@google.com>
