When a test fails in layoutlib, store the resulting png files in
out/failures subdirectory of the current working directory.
That avoids the risk of collisions if tests for several branches
of layoutlib are run at the same time.
Test: Run tests in layoutlib with at least one failing test
Change-Id: I31594a871e481e6aa410a165926ce544dc7ddcf2
(cherry picked from commit 82ebb9058479de56860f348ab969160e0d8294b6)
Shadows could be painted outside of the allowed drawing region
for the components for which they are the shadow.
Bug: http://b.android.com/215402
Change-Id: I2d2821b745147f3723e8f11d648094fcd684fe51
(cherry picked from commit 9702fffc768db43d0aba4fb1bea54af50af11361)
This class was added in ServiceManager.java in commit 49ca529a85.
Layoutlib rewrites the entire ServiceManager class, so it also
needs to define ServiceNotFoundException.
Test: TestDelegates.testMethodDelegates
Change-Id: Ia68399e8baa973ae961eabe929ca3d1019f20ba7
The flag is a bit clunky for most cases, and a method is more
clear.
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test
android.server.cts.KeyguardTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test
android.server.cts.KeyguardLockedTests
Test: runtest systemui -c
com.android.systemui.keyguard.DismissCallbackRegistryTest
Bug: 30961403
Bug: 27422134
Change-Id: I39de90c7cfecd99350a74f72cd76418e337f2b79
When loading classes from the jar file, we can't just use the
URLClassLoader since it can not enumerate files in a jar directory.
Restoring the ModuleClassLoader and making all paths relative to the
system class loader (as opposed to relative to the class location).
Change-Id: Ib3f5d12dd5c964d0ba9cc6c5ec9cb556c989e653
(cherry picked from commit 2a4a6c81f8a103be5c48d8a0605a3e4416e8f7f1)
Settings needs to access a variant of getInstalledApplications() which
takes a |userId| argument. Since this is not currently exposed by
PackageManager, Settings calls into PackageManagerService directly. This
is ugly and breaks the regular abstraction layer hierarchy.
The CL fixes the problem by exposing the required variant of
getInstalledApplications() as a hidden API, analogously to what was done
before with getInstalledPackages().
Bug: 32692748
Test: Will be CTS-verifier-tested together with Settings
Change-Id: Id9c4e8e18524d312159821f1a4d5527263c7e950
On layoutlib, requestApplyWindowInsets wasn't being passed up to
ViewRootImpl so onApplyWindowInsets wasn't being called.
Test: Added new test testApplyWindowInsets
Bug: http://b.android.com/169308
Change-Id: I8f3174dc2879a7e6c3db1628a1bfb1c023d88efc
- Remove ModuleClassLoader as it can be replaced with a URLClassLoader
for now.
- Move CustomCalendar and CustomDate to a separate package that can be
used both by the Bridge tests and the actual test app.
- Move empty.xml out of the test app so it compiles.
- Update test app to use the latest build tools and SDK (some attributes
being used by the app weren't supported in API 21).
- Update gitignore to remove the new out directory.
Test: Update to existing tests
Change-Id: Ieb7324d5ae559f9c581771c57f2127cd83909015
Follow-up to commit 896cc3a794, the class file also needed to be
updated. The golden file of testActivity is also updated to be
the one built with jdk1.8.0_60 which is the one running on buildbot.
Test: Run testActivity
Change-Id: I7f3cfc1123160005c3cb5fa4213db6ae3a48457d
(cherry picked from commit aab13aee9a11c340952c24f2410940df59996816)
The date of the calendar is set by converting the epoch time based on
the local time zone. We choose at date at 12:00 GMT so that it will
be on the same day no matter which time zone is considered.
Test: part of testActivity
Change-Id: Ib36a5b45f69323265dd5ceaa17eeac553fc2d071
(cherry picked from commit 896cc3a794bb6e173c1e53e97f70007c3e24de38)
This is following commits f22859757b, 94931bd87e, 4387190d8e
and caa08ff5e9.
Test: Run TestDelegates
Change-Id: If90028492c036fc5f69913e4dcad5a1a5fca4b55
Put android:animateFirstView false in the test application theme
so that the date picker view displays fully.
Update the golden image to reflect the changes.
Change-Id: If57fac5c182dd69b4b4d4fcc30d6f17a8f67ad68
(cherry picked from commit 96970138fc1c8d928a6d3ec362865e6c626f56e4)
Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
Cleanup:
- Make sure all the state is nicely dumped.
- Remove some unused stuff.
- Fix a flicker when occluded -> unlocked
Bug: 32057734
Change-Id: Id87e26adccef740d608b325c2dc1f6db14dd4ec3
- Creating a PinnedStackController to keep track of the state of the PIP
to prevent changes in the system (ie. IME showing) and user interaction
from clobbering each other.
- Refactoring calls in AM into WM/controller
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ie59dfd45d5c54764ba69a589b3b8148845e92cc3
Signed-off-by: Winson Chung <winsonc@google.com>
- Ensure we use the right display size when calculating PIP bounds.
- Also update interface to take the display id.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackDefaultBounds
Test: #testPinnedStackMovementBounds
Change-Id: I01fd8ba6dee212c29a9a092673ee8f7843e41af6
Now display-specific settings, such as dimensions and orientation,
are stored in display override config. For default display it is
mirroring the global config. Each time when global config is updated,
override of the default display should be updated too and vice versa.
Test: Existing and manual tests still pass.
Change-Id: Ic6c2190092d328820f314a05bed43c875db18170
- This CL provides the framework for manipulating the pinned stack using
an input policy (to be determined later) provided by the SystemUI.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testNonTappablePipActivity
Change-Id: I025c41fff26ed05a35d68e59f10330680ed11ea8
NOTE: Linear blending is currently disabled in this CL as the
feature is still a work in progress
Android currently performs all blending (any kind of linear math
on colors really) on gamma-encoded colors. Since Android assumes
that the default color space is sRGB, all bitmaps and colors
are encoded with the sRGB Opto-Electronic Conversion Function
(OECF, which can be approximated with a power function). Since
the power curve is not linear, our linear math is incorrect.
The result is that we generate colors that tend to be too dark;
this affects blending but also anti-aliasing, gradients, blurs,
etc.
The solution is to convert gamma-encoded colors back to linear
space before doing any math on them, using the sRGB Electo-Optical
Conversion Function (EOCF). This is achieved in different
ways in different parts of the pipeline:
- Using hardware conversions when sampling from OpenGL textures
or writing into OpenGL frame buffers
- Using software conversion functions, to translate app-supplied
colors to and from sRGB
- Using Skia's color spaces
Any type of processing on colors must roughly ollow these steps:
[sRGB input]->EOCF->[linear data]->[processing]->OECF->[sRGB output]
For the sRGB color space, the conversion functions are defined as
follows:
OECF(linear) :=
linear <= 0.0031308 ? linear * 12.92 : (pow(linear, 1/2.4) * 1.055) - 0.055
EOCF(srgb) :=
srgb <= 0.04045 ? srgb / 12.92 : pow((srgb + 0.055) / 1.055, 2.4)
The EOCF is simply the reciprocal of the OECF.
While it is highly recommended to use the exact sRGB conversion
functions everywhere possible, it is sometimes useful or beneficial
to rely on approximations:
- pow(x,2.2) and pow(x,1/2.2)
- x^2 and sqrt(x)
The latter is particularly useful in fragment shaders (for instance
to apply dithering in sRGB space), especially if the sqrt() can be
replaced with an inversesqrt().
Here is a fairly exhaustive list of modifications implemented
in this CL:
- Set TARGET_ENABLE_LINEAR_BLENDING := false in BoardConfig.mk
to disable linear blending. This is only for GLES 2.0 GPUs
with no hardware sRGB support. This flag is currently assumed
to be false (see note above)
- sRGB writes are disabled when entering a functor (WebView).
This will need to be fixed at some point
- Skia bitmaps are created with the sRGB color space
- Bitmaps using a 565 config are expanded to 888
- Linear blending is disabled when entering a functor
- External textures are not properly sampled (see below)
- Gradients are interpolated in linear space
- Texture-based dithering was replaced with analytical dithering
- Dithering is done in the quantization color space, which is
why we must do EOCF(OECF(color)+dither)
- Text is now gamma corrected differently depending on the luminance
of the source pixel. The asumption is that a bright pixel will be
blended on a dark background and the other way around. The source
alpha is gamma corrected to thicken dark on bright and thin
bright on dark to match the intended design of fonts. This also
matches the behavior of popular design/drawing applications
- Removed the asset atlas. It did not contain anything useful and
could not be sampled in sRGB without a yet-to-be-defined GL
extension
- The last column of color matrices is converted to linear space
because its value are added to linear colors
Missing features:
- Resource qualifier?
- Regeneration of goldeng images for automated tests
- Handle alpha8/grey8 properly
- Disable sRGB write for layers with external textures
Test: Manual testing while work in progress
Bug: 29940137
Change-Id: I6a07b15ab49b554377cd33a36b6d9971a15e9a0b
This introduces a new feature of the IBinder command protocol
to allow the shell command implementation to call back into
its caller to ask it to open files in the calling context. This
is needed so that commands that have arguments specifying files
can open those files as the calling shell, not the system (or
whatever) process.
To test this all out, move the "am start" implementation over
to ActivityManagerShellCommand, in particular along with its
option to specify a file in which to write profiling data.
Test: Manual
Change-Id: I0c1e3857defefbd19a2ac29413aafbb34b1e48a3
If an attribute is not an actual theme reference, the call to
Resources.Theme.resolveAttribute will fail in layoutlib. This would
happen for example for color values.
The call in the Android framework simply returns the value.
Bug: 31553972
Change-Id: Idda768a659d94a6c3f848dc960303cf4241325c3
- Prevent third party apps from inadvertently changing internal SystemUI
flags through a call to setSystemUiVisibility(). These flags are only
set in the individual SystemUI components and can be updated in WMS
directly.
Bug: 29875297
Change-Id: I5ea238c8fb16a0eccd6e993d95a912acb359cee6
Add "wm surface-trace" command which enables tracing of surface
commands to be switched on at runtime. Primarily intended for use
by WM CTS tests. First target in CTS will be to use show/hide
events to eliminate polling in WM tests and increase speed. Next up
looking at things like verifying various transitions and relaunch
scenarios are flicker free. Later we may want to look at a smarter
or more structured format...but it's really not much hassle to parse
the commands off a pipe so I wanted to get us started.
Test: cts-tradefed run singleCommand cts -o --module CtsWindowManagerHostTestCases --test android.server.cts.SurfaceViewMovementTests#testSurfaceMovesWithParent
Change-Id: I1ff912c405a6cb9996ee9b6e2c465d57706191ba
Before this CL, only vertical offset was used when calculating the view
bounds in the ViewInfo object. This caused that in some cases where padding
was used, the bounds didn't match the actual output.
Bug: http://b.android.com/222231
Change-Id: I4889caee2811556442dc6ec97c1307661a798392
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug: 31055479
bug: 27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
(cherry picked from commit ad24f96def42016049de05220593aa049b136def)
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug:27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
