Previously, we were only making sure that the magnified content belongs
to the view the magnifier is attached to. However, when the view was
laid out partially outside the screen, we would pixel copy from outside
the surface the view is attached to. This would lead to the user seeing
a distorted content in the magnifier, in cases when the magnified view
lies outside the screen. This CL addresses this issue, by clamping the
pixel copy coordinates inside the surface we copy the magnifier content
from.
Bug: 72039853
Bug: 63531115
Test: bit CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iddab05c98b615259938e0d3a3320b98b3b13b246
This CL attempts to clarify that just having a ContentProvider does
not necessarily mean ContentProvider#onCreate() is always called
before Application#onCreate() on Android N and later devices because
of direct boot.
Fix: 67559645
Test: make -j doc-comment-check-docs
Change-Id: I33b7cda42146333f48fb445027f5d31f3c5af5b6
Freeze period is defined as a pair of calendar dates (recurring annually)
during which the system should block any incoming system updates, including
security patches. They are set on top of existing system udpate policy
types (automatic, windowed, postpone) such that outside the freeze
periods existing policy semantics will still apply. They are created to
allow admin to keep their device fleet from any destabilizing changes during
critical period of the year, for example during Christmas sales period.
Device Owner can set several freeze periods, although to prevent the device
from not receiving OTAs indefinitely, each single freeze period is
restricted to be at most 90 days, and adjacent freeze periods need to be at
least 60 days apart. To properly enforce these restrictions, any freeze
periods the device previously experienced is tracked by DevicePolicyManager
and are validated against any new policy. This is to deal with corner cases
such as the admin repeatedly set a short but overlapping freeze period on a
rolling basis, hence bypassing the 90-day freeze period restriction.
Test: runtest -c com.android.server.devicepolicy.SystemUpdatePolicyTest frameworks-services
Bug: 64813061
Change-Id: I2864192797dc194edd9c183b881da6cfe3fdba5e
An upcoming change will add another library that needs to be
added for backwards compatibility. Merging the tests for those into the
existing test class makes it much harder to see and the tests start to
overlap, i.e. some tests will test more than one aspect which makes
maintenance more difficult and debugging more complex.
This splits the test methods in PackageBackwardCompatibilityTest out
into separate tests for the different PackageSharedLibraryUpdater
implementations into their own classes and simply tests that the
PackageBackwardCompatibility class uses the correct implementations.
This allows each PackageSharedLibraryUpdater to provide comprehensive
tests for their own behavior without affecting tests for the other
classes.
The OrgApacheHttpLegacyUpdaterTest only runs if the
OrgApacheHttpLegacyUpdater class is on the classpath. That is done
using OptionalClassRunner which is a custom JUnit Runner that runs the
tests in a class iff a specific class is present. Otherwise, it behaves
as if the class had a single test that made an invalid assumption.
Tested by building with and without REMOVE_OAHL_FROM_BCP=true and then
running the following:
adb install -r -g out/target/product/marlin/testcases/FrameworksCoreTests/FrameworksCoreTests.apk &&
adb shell am instrument -w -e class android.content.pm.PackageBackwardCompatibilityTest,android.content.pm.AndroidTestRunnerSplitUpdaterTest,android.content.pm.OrgApacheHttpLegacyUpdaterTest,android.content.pm.RemoveUnnecessaryOrgApacheHttpLegacyLibraryTest com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 18027885
Test: as above
Change-Id: Idd1a343d234a57d518010c5a79030cbd7682e0c1
This flag will allow the sync manager to exempt certain kind of sync requests.
- This will only exempt jobs from app-standby.
- EBS still won't exempt them. Battery saver cuts background network anyway, so
background syncs will still not work, and it didn't used to work pre-P either.
- Manual force-app standby still doesn't allow them to run.
Bug: 72443754
Test: Build and boot. The behavior shouldn't change since none uses the flag yet.
Test: atest CtsJobSchedulerTestCases
Change-Id: I806b97bb4b7da773479e878e6eccb792b03eadc1
* Update usage of A2dpService API calls that take BluetoothDevice
as an additional argument
* Update the description for BluetoothA2dp.connect()
Exempt-From-Owner-Approval: De-facto owner of the relevant changes is
the Bluetooth team.
Bug: 69269748
Test: Manual
Change-Id: I190ed48ef65bbc8b88b45f84ebd6ab3d21cf0b4e
Merged-In: I190ed48ef65bbc8b88b45f84ebd6ab3d21cf0b4e
(cherry picked from commit 502af2192c)
Status: Ready for review.
Note: This is a Javadoc only change.
Changes:
* Replaced "guide/developing/tools/traceview.html/ with
"studio/profile/traceview.html"
Test: * Build with "make ds-docs -j16"
* Staged content at go/dac-stage/reference/android/os/Debug.html
* Ran linkchecker against staged content
Bug: 37640935
Change-Id: I0446c44a78ae7d1d9193e2fe08e059cdc90cac7a
