This CL cleans up APIs around font variation settings.
- Remove FontConfig and FontManager public API.
- Remove FontManagerService from system service.
- Extract inner class FontConfig.Axis as top-level class FontVariationAxis.
This is used by Typeface.Builder public API to create new Typeface.
- Introduce and expose FontVariationAxis utility functions from/to string.
- Throws if the invalid font variation settings is passed.
Test: android.text.cts.FontVariationAxisTest passes
Test: android.graphics.cts.TypefaceTest passes
Test: android.graphics.cts.PaintTest passes
Change-Id: I9ccafe7a53935960566243e2856e166878ca59ae
If the snapshot starting window has different dimensions than the
snapshots we have taken, we do the following:
- Create a child Surface that has exactly the dimensions of the
snapshot.
- We fill the parent surface with the app background color, as well
as all screen background decorations (status bar background,
navigation bar background).
- We also clip of the status bar/navigation bar background in some
cases, as it looks ugly if it's not behind the system bars.
- Furthermore, we inherit all layout flags on the window and all
layout relevant SystemUI flags on the window such that it's very
likely that the size will match, and the system bars are drawn
correctly.
- In order to make the transition from the snapshot to the real
window a bit more predictable/less messy, we enforce a minimum
duration the snapshot is visible, which is slightly more than our
app transitions.
Test: TaskSnapshotSurfaceTest
Test: Open app, go home, go landscape, open app again
Test: Go to multi-window, open app from recents with a snapshot
taken in fullscreen.
Fixes: 36703868
Change-Id: Ia2d4add6971a18ab7aa2942d2b644d6e87a402af
(Finally) introduce a new ServiceConnection callback to
tell you when the binding has died. This allows you to robustly
have a weak service monitoring, and also is an easy way to find
out about breakages due to app updates etc.
Also clean up some debug output.
Test: moved to own suite and ran them.
Change-Id: I526cc00816c384fa9eb1312b92406f38085cbff9
- This CL has two main changes:
1) It modifies the activity multi-window and picture-in-picture mode
changed callbacks to provide the configuration of the activity with
the mode applied.
2) It modifies the order in which the multi-window and picture-in-picture
mode callbacks are made, to ensure that when going in and out of
picture-in-picture: first PiP, then MW, and then the config change.
- Previously, the ordering of the two callbacks was inconsistent. When
calling moveActivityToPinnedStack(), we reparent the task into the pinned
stack (triggering the picture-in-picture mode change), followed by the
resize animation (causes configuration changes). Inversely, when we
expand the task to fullscreen (and not just remove it), we run the
animation first, which resizes the task to the final size (causes
configuration changes) then reparent after the animation completes
(triggering the picture-in-picture mode change).
In this CL, we ensure that for both the transition in and out of PiP, we
defer to the bounds animation to trigger the PiP mode change. Normal
calls to reparent or adding a new task are unchanged. When the PiP
mode change is called from the animation, it provides the final target
bounds which we use to calculate the target configuration of the activity
for the callback. If the bounds animation is interrupted, an update will
also be scheduled if we change the fullscreen state we are animating to.
To work around the issue where we are scheduling MW/PiP mode changes in
both the animation and the configuration change, we also now keep track
of each state internally in the ActivityRecord.
Bug: 36099777
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testConfigurationChangeOrderDuringTransition
Change-Id: I03513bc3a4d4a72c250983f22f079ce9d7a2cb40
Signed-off-by: Winson Chung <winsonc@google.com>
Yum!
Also needed to have a Context.revokeUriPermission() variant that is sane,
so reasonable CTS tests can be written.
Test: new ClipDataJobTest added.
Change-Id: Ia3135ea788a6e32c971bae7dab3a844d0ef4139c
When in VR mode, launch all activities into the virtual display ID as
provided by the Compatibility display. This includes two cases -
- New activity launches
- Existing activity in the background.
Testing Done: Tested with PlanarVirtualDisplay app and Settings,
Calculator and GestureApp with different intent flags.
Bug: 36071574
Bug: 36071445
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testVrActivityLaunch
Test: #testVrActivityReLaunch
Change-Id: Ic590a7cbd6f9b339dc83b22a8ffb1252219ef22e
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
The ViewStructure typically represents a View, but it it can also be a virtual
view; in particular, WebView uses virtual views to represent HTML elements.
Although most of the properties of the HTML element maps to properties of
Android Views, some properties (such as 'name' and 'id' on <INPUT> fields)
don't, and those are crucial for autofilling web pages.
Rather than trying to artificially map these properties, it's better to create
a generic representation, for the following reasons:
1. Web standards move in a different velocity than Android APIs
2. Android APIs cannot be changed easily. Deprecated APIs continue to work,
and new added APIs don't work in older versions
3. The data used for autofill is opaque to the Framework - it's only relevant
to the node producers (like WebView) and consumers (Autofill services).
Also removed the setIdEntry() that was used for the same purpose.
Fixes: 36696757
Bug: 36718508
Test: VirtualContainerActivityTest with new checks pass
Change-Id: Ia626bd1f640b0b5861e81a5915504b95029874c9
Bug 36702993
Instead of throwing an exception during commitAllowStateLoss()
or commitNowAllowingStateLoss(), silently drop the transaction
when the FragmentManager is detached.
Test: I7093457c2b4936b95ab086dbe947571f0b525f63
Change-Id: I77641b69f2573fc895a27ec9da63c2d2ab6d7a4e
Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state. Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds. If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.
We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.
Bug 36130212
Test: CTS
Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
(cherry picked from commit 79047c62b5)
We were properly re-running jobs if the app hung during their
execution, but outright crashes wound up with the scheduled job
being dropped. That's bad; it can easily lead to broken monitoring
in the case of content-triggered jobs.
We now reschedule with backoff when this happens. In addition, to
mitigate the impact of repeatedly crashing apps, we now enforce a
minimum backoff interval of 10 seconds for automatic reschedules.
Bug 36030229
Test: manual
Change-Id: Ib5da583d7901d1255066c48558b35186eb641e17
It was consuming all keyShortcuts which broke system hotkeys
like shift+tab.
In order to prevent the decor/phonewindow from creating menus,
this creates a dummy view in onCreatePanelView.
This also includes a change to Activity to not send KEYCODE_TAB
keystrokes to the defaulthandler. This was preventing keyboard
navigation from working on any activity that had a default
search fallback.
Bug: 32482282
Bug: 18021345
Test: Added a CTS test (ToolbarTest#testKeyShortcuts) for toolbar
keyShortcuts. Verified Tab-navigation works in Play Store.
Change-Id: I5c732a2b21219157818bed49576debd20d5a8178
(cherry picked from commit b22faf524e)
Bug 36679897
When restoring the non-config fragments, the wrong index was
being used to lookup the fragment fromt the list of active
fragment states.
Test: Ic862fd9670408dab09ab5817cdec21e91aef001b
Change-Id: Ic5a8e723041949e6d01d4f5ddc6d54e491143b59
Do not wrap a null monitor, pass a null wrapper instead.
BackupManagerService expects null monitor wrapper, so this
will prevent extra work for BMS and potential NPEs.
Bug: 36470662
Test: manual
Change-Id: Ia45375049101f757542960bc7f1fd640fc9c3fb7
Problem:
Work profile status bar icon feeature is relied on two callbacks
1. onForegroundProfileSwitch (AMS.setResumedActivityLocked)
2. appTransitionStarting (WMS)
We assume callback 1 is always called before 2, but it is not the case.
These two callbacks are triggered by two handlers in two different threads,
and hence race condition happens.
Solution:
Not rely on onForegroundProfileSwitch to update mManagedProfileFocused
flag anymore. Query getLastResumedActivityUserId in appTransitionStarting.
Also, make sure mLastResumedActivity is updated before sending message
to WMS in setResumedActivityLocked.
Test: Start a work app, observe that the work icon is shown.
Test: Start a personal app, observe that work icon is gone.
Test: Dock the work app, tap on it (give it focus), observe that work
icon is shown.
Test: Start a work app, switch user, can see the icon is gone. Switch back,
icon is back.
Bug: 34159089
Change-Id: I2cee141d18e8b7d5607b26dd7a2fd5bc9cd0ebb3
This reverts commit 599be3d01e.
This change is being reverted because it broke git_master build.
Change-Id: I54ab9cd3d9e08dcf870f472fda08cc44e57986d0
bug: 34703669
Creates a new UI Context for UI based operations.
This UI Context is wired up the same way a normal app
Context would be, and is subject to change when overlays
are enabled/disabled.
For this reason, only UI should be using this new Context.
All other operations should be using the original system Context
so that changing themes don't impact the regular operations of
system_server.
Also added some sanity checks at key places where we show UI
(ShutdownThread, BaseErrorDialog).
Bug: 36059431
Test: $ adb shell am crash com.android.settings
Test: Observe crash and power off dialogs are blue with PixelTheme
Change-Id: I87227ee2e0be1e72dcde8f482b37725cb687260b
This Intent will be used in Settings to show the settings UI for the
Ephemeral resolver. Settings can get the correct component to send the
Intent to by calling
PackageManager.getInstantAppResolverSettingsComponent
Bug: 35918998
Test: Boots
Change-Id: I0edcf85704f2c19e0ee27f91b6ef057d52e32778
(cherry picked from commit aa49cb86e6)
To be consistent with other multi-window callbacks adding
Configuration param to the onMovedToDisplay, so that app
developer can handle configuration change at the same time
when it receives a notification about move.
Bug: 36649499
Test: android.server.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I80c765473bfc09ea1fb7aa4e2e77baf3b21606b8
(cherry picked from commit 2c32a11a71)
Not needed anymore, since the bug was found to be in the binder driver.
This reverts commit 9afb1fc495.
Change-Id: I3891866f6e30a3f3391df8005e56bf9b9777b3a6
(cherry picked from commit ab5523f337)
Support loading a WebView package which specifies the name of a "donor"
that provides missing files. This allows a preinstalled stub WebView to
function by loading its code and assets from the preinstalled Monochrome
implementation, as long as the versions are close enough that the
manifest contents are compatible, which should be fine since
preinstalled versions will match.
To do this, we replace the stub's code paths in AppplicationInfo with
the donor's, so that all Java and native code and resources are loaded
from the donor APK at runtime instead of from the (mostly empty) stub.
To get the ClassLoader with the modified path cached as if it was the
regular path, we introduce a new "cacheKey" parameter in
ApplicationLoaders.
Bug: 21643067
Test: build "new" stub WebView upstream in chromium and test loading
Change-Id: I08cc9122b1c9def3e1206974f3e0e8973cca3419
- The task overlay activity should only exist when there are activities
present in the task. When the last such activity is finished, we should
remove the whole task entirely including the task overlay.
- Exposing the task overlay apis to CTS
Bug: 36507456
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testFinishPipActivityWithTaskOverlay
Change-Id: I1dabe7782fb6769a90d832664e8052be158041e1
