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
CL Id0a4200f912ac3303026cb26b6d8974c47332828 sets a system property
"ro.art.hiddenapi.warning" for non-release, non-user builds. This
patch reads that flag and unless the flag is set, will only ever show
the warning message if the app is debuggable.
Test: manual
Bug: 64382372
Change-Id: I9b552792779589a7a91818a82d5c86141fc0a30b
Status: Ready for review
Note: This is a Javadoc only change.
Changes: Removed unnecessary "(TODO)" note.
Test: Build the docs with "make ds-docs" and staged updated content.
Staged content:
go/dac-stage/reference/android/app/Notification.html#FLAG_SHOW_LIGHTS
Bug: 20150478
Change-Id: I3a7fc0414ccb6f52e9b4919031a93ca1a7a29336
Tuned rates that we collect PSS, to reduce how much we do
that heavy operation. Added a new way to determine
whether a process has changed to a state for the
"first" time -- now this is when it has gone to that
state for the first time since it was in a lower state.
This will reduce the amount of time we consider a
process to be first to only when it has previously
gone into a higher state than it had before.
Keep track of more fine-grained information about why we
collect a PSS sample (not just internal, but for a single
process, all processes because of a mem state change, all
processes because of a poll).
Started collecting RSS in various places, so we can start
looking at that w.r.t. PSS and see about transitioning to
it is a new primary metric.
Added logging for many of the places where the system
writes its configuration files, so we can more easily
see any bad behavior going on in those areas.
Added some currently disabled code to read smaps directly
instead of using fgets(). Probably won't help, but want
tot test.
Bug: 70859548
Test: atest CtsAppTestCases
Change-Id: I400dba0f3ae9c024df51c946cfa592561028b598
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
