Window management files on the client side have normally been dumped in
either android.view or android.app package. This CL starts to
centralized them in android.window package so there is better
separation.
Test: they pass
Bug: 147406652
Bug: 152113464
Bug: 152117221
Change-Id: I4d64bd256e9b3581af0ccf9396f7dd2454132719
The conversation titles weren't transforming before and
fading in / out before as a result. Also the icon and
its background was animating which was leading to some
strange flickers.
Bug: 150905003
Test: add group message, observe normal transitions
Change-Id: I8fa3b0e4ba4beae2661025b8456222ead7f5faaa
The transition was using getTop instead of absolute positions which
didn't work well for the conversation layout.
Also, we were fading in views that were GONE and making them VISIBLE
which lead to bugs during the transitions.
Additionally, the header text would become visible when a notification
was removed from a group and reset.
Bug: 150905003
Test: visual, add conversations in groups and non-groups
Change-Id: I3c31006a1fc79f7d58cc1dd3d5af44129c9f02bb
Update existing strings, and add strings that we will need to complete
the implementation
Bug: 151322044
Test: visual
Change-Id: Iee922e8f6db6c3058dc9c5ce77eef63c9b6bd2db
When transforming from single line horizontal
to vertical display, the transition got messed up.
We're now looking at the absolute positions instead
of just local adaptions
Bug: 150905003
Test: add group with two messages, observe normal expansion
Change-Id: I20fb2deefd7e39ff8d8473611946284f9598bb9a
Previously image messages were embedded in the
messaging list instead of at the root.
Also rendering the images slightly differently such that
they don't always use the aspect ratio but can scale
Bug: 150905003
Test: add messaging layout with image, observe nice display
Change-Id: Iba25a1f81d77b58bfccbe2f9b8dfc502fdf8bdd4
- Documentation clarity and method rename per API review feedback.
- Specifying in documentation and implementation that the implementing service must be exported by the Profile Owner.
Bug: 150866056
Bug: 136085151
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest KeyguardUpdateMonitorTest
Test: atest AdminSecondaryLockScreenControllerTest
Change-Id: I58175bd6cf8936f5b1267625ca15b4f9c57f4144
This will enable access to this resource from other packages, e.g.
Settings.
Bug: 151221154
Test: Manual verification with overlay true / false.
Change-Id: Ia53d5edcb55b8df0f5d68f88740b3e8f64aae5c5
This does a few things.
1. Fixes the logic around restricting the amount of adjustment. Its
supposed to make sure that at-least 1/3 of the primary split is
visible.
2. Fixes an issue where windowcontainertransactions weren't applying
configuration updates to tiles specifically
3. Includes configuration changes among the things that will send
onTaskInfoChanged updates to task-organizers. Previously, the
changes were actually applied late.
- The reported changes are restricted to only configs that
task organizers can set.
4. To adapt to config changes being reported, divider code needed
to be changed.
Bug: 151181674
Test: Using various snaps of split, open ime in secondary and
verify that primary remains visible.
Change-Id: I7001bd29872a15950f91ab2407848fde8c3f1d02
Test: Manual:
1. Create a work profile via TestDPC (go/testdpc)
2. Set a work profile lock pattern/PIN/password via Settings > Security
3. Launch the work profile instance of TestDPC
4. Scroll down to "Lock screen"
5. Tap "Lock screen restrictions"
6. Select the "Work profile" tab
7. Set "Max password failures for local wipe" to 3
8. Lock & unlock the screen
9. Launch work profile app
10. Enter the wrong pattern/PIN/password >3 times
Before: Work profile is not deleted
After: Work profile is deleted and appropriate dialog is shown
Fixes: 148374841
Change-Id: I45a0aa7ac83f67603c6cf0a06337f8a34c38586f
- Adds some user education strings that aren't used yet, that'll
be fixed in a follow up
- Removes some strings that aren't ever used
Test: treehugger
Bug: 151965589
Change-Id: I31a4dcb518b37505ed07fc2d454ddfec7598fb01
Deflake NotificationEntryManagerInflationTest by moving back
to the countdown latch approach and providing our own executor
to AsyncInflationTask.
It was infeasible to depend on the exact number of main thread messages
as other main thread messages from other tests could interfere. Thus.
we move back to the countdown latch for when NotificationEntryManager
finishes inflation. This makes us dependent on the listener API for
determining when inflation is finished, but it's unlikely we can do
better unless we can inject an executor into RowInflaterTask.
In addition, using AsyncTask's SERIAL_EXECUTOR on hwasan builds seemed
to be much slower than normal. This lead to other tests' AysncTask
work delaying the work in this test and leading to the timeout
happening before inflation finished. By providing a test executor
instead and synchronously controlling its execution, we avoid this
issue.
Bug: 150618180
Test: atest --iterations 100 NotificationEntryManagerInflationTest
Test: atest SystemUITests
Test: A forrest run coming soon!
Change-Id: I87c6e2d216c8f26aaf340d311f618c9dccaba8af
