Missing parts:
1) Whitelist locksettingsservice to use grant API.
2) Probably have similar update for recovered keys - they will live in
system service and RecoveryAgent will use getKey() method to access
them.
3) ApplicationKeyStorageTest
Bug: 66499222
Test: adb shell am instrument -w -e package \
com.android.server.locksettings.recoverablekeystore \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I584b89e3f777bed679b2eb5173750f3f1dee3635
Reverts the revert of ag/3546427 and fixes the regression.
Didn't add the ids to the layout in landscape and seascape that caused
the crash. Also fixed a boolean parsing issue in CommandQueue and
correcting the unpin button press when it lays the buttons after
overview proxy connects to launcher.
Change-Id: I59791f6a08e11d17dfb32ab3a2733766c8cf1036
Fixes: 72800226
Test: manual, rotate screen and pin (like in play movies)
There are several places across the OS where Java code is simply
copying data between two points, which requires bringing that data
out into userspace before going back into the kernel. (That's pretty
lame.) The patches for the recent Meltdown/Spectre security issues
have made this overhead even worse, so it's finally time to move this
copying directly into the kernel.
This change adds a couple new FileUtils.copy() methods which inspect
the given streams/FDs, and attempt to do as much optimization as
possible before falling back to a slower userspace-based copy.
Benchmarks are showing typical improvements of 44% for 32KB files,
50% for 32MB files, and 35% for 32MB pipes.
Plenty of tests are included, and there's a simple kill-switch that
can be used to enable/disable the feature if it starts causing any
trouble. (A future CL will enable the optimizations.)
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I52518d529da5d961610998b9f61399064d8025cd
Instead of writing StatsLog.write(StatsLog.NAME, 1), we replace the 1
with the appropriate StatsLog constant.
Bug: 72749863
Test: still compiles
Change-Id: I68c8206de49df7e77ee66333dd633e4b70c7b226
All the text and screen pinning hint shows tells the user that the back
and home button should be held to exit screen pinning. The hint also do
not have the recents button shown if it is invisible. The toast code has
been moved to recents and services calls through to post a toast message
depending if the recents button is visible.
Test: manual
Fixes: 72059911
Change-Id: I93abf5072b97760f33e7e77421544a4b3ad27beb
This reverts commit 860b8ba719.
The original change that was reverted contained a bug that allowed an
http view/browsable intent used to query for browsers to be considered
as a candidate for instant apps. This was resulting in an attempt to
bind to the instant app resolver while holding a lock on mPackages.
This change ensures that PMS doesn't bind while checking for the browser
status of a package in both the instant app filtering code and by adding
the FLAG_IGNORE_EPHEMERAL to the canonical browser intent.
Reason for revert: Applying fix
Change-Id: I4896b3a15416a11fdc3f6c191e552c4ce8963623
Fixes: 63117034
Fixes: 71916178
Test: Manual using test app at google_experimental/users/patb/InstantAppsInP
Test: atest android.appsecurity.cts.EphemeralTest passes after modification
We use the approach of outsetting the stack bounds and then
insetting windows which don't have surfaceInsets by said outsets.
Test: Manual. go/wm-smoke
Bug: 72657549
Change-Id: I9ac7e13ec696f88f02794175d0d44ac870f91d33
This CL sets the user traced pattern on the unlock screen to fade as
it's drawn, reducing the chances of shoulder surfing.
Test: Build, set a pattern, and try.
Change-Id: I2ad37a10782d826d076dcf5142700d8facc2f52e
Records start and duration of shutdown, along with reason and if it was
a reboot.
Test: manually verified statsd received atom. CTS test for this will be
difficult, and I will investigate further later.
Change-Id: I0f6b595e0e251fd0a8b38127182d055885460a55
Bug: 63117034
Change-Id: Ie3818e913e8e1077f60434a626bc606c0b5015ab
Test: Manual using test app at google_experimental/users/patb/InstantAppsInP
Test: atest android.appsecurity.cts.EphemeralTest passes after modification
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
For frameworks constants that don't have intrinsic meaning (i.e. their actual
value and order don't matter), so that it is unlikely that their values
will be changed:
This cl introduces proto enums representing some constants found in
the Android codebase, and connects the two.
By using the Proto enum as the source-of-truth, it means that Java and
proto can be kept in sync. Otherwise, when the Java frameworks code
changes, it silently breaks the protos from working properly, since the enums
are wrong. By having the Java code reference the proto enums, it ensures
that everything is in sync. The values of the constants are unchanged.
But future changes to these constants will need to be done in the proto
file, which the Java file merely references.
The protos are necessary for incidentd and statsd and, in the future,
possibly dumpsys. In this way, the logging mechanism is much less likely
to get broken when new constants are added, and we can be ensured that
the logging accurately reflects the underlying codebase.
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases
Test: cts-tradefed run cts-dev -m CtsIncidentHostTestCases
Change-Id: If79032c34b2799db1e3e70cb47b1312fd72092b9
