Before the new insets system, a window wouldn't receive visible insets
if it:
- has FLAG_LAYOUT_NO_LIMITS,
- is not TYPE_WALLPAPER or TYPE_SYSTEM_ERROR, and
- is not in multi-window mode.
This CL makes the visible insets compatible with the legacy insets
system.
Fix: 223536648
Test: atest InsetsStateTest
Change-Id: Ia73142cfae701d0532a9a397366c50aeef82abb2
* changes:
[automerge] Fixed status bar glitch for apps that access internal res 2p: 71eaca7ede 2p: acf060e065
[automerge] Fixed status bar glitch for apps that access internal res 2p: 71eaca7ede
Fixed status bar glitch for apps that access internal res
* changes:
[automerge] Fixed status bar glitch for apps that access internal res 2p: 71eaca7ede
Fixed status bar glitch for apps that access internal res
Otherwise, the latency_tracker must be manually
enabled via a SystemConfig (and the device must
minimally be debuggable).
Test: manual
adb shell device_config put latency_tracker enabled true
adb shell am broadcast -a com.android.systemui.latency.ACTION_FINGERPRINT_WAKE
Fixes: 227491682
Change-Id: Ia5a7f2f9eec619c26583bcac6b00b8445abdcbf1
Use new status_bar_height_default for
SystemBarUtils.getStatsusBarHeightForRotation().
Bug: 216782082
Test: make
Change-Id: I6376169bfeb470de5dc820b9c3633c64981079f0
In 12L, to support mulit-display devices, we changed the way to get the
status bar height by adding an API to calculate instead of directly
reading the resource of status_bar_height.
However, some apps still using Resources.getIdentify() to get this
internal resources dimen as status bar height to layout their UI which
cause status bar glitch in their app.
For compatibility purpose:
1. Create a new dimen res status_bar_height_default which will be used
by framework to determine the status bar heigth
2. For status_bar_height
- Set the value to the size which already consider the cutout size
for defualt display as before so that it won't breaking existing
app.
- It is only used for apps using Resources.getIdentifier()
Bug: 216782082
Test: verified on the apps with such issue.
Change-Id: I306efa187ffa69223c06fd248cfe57d183f96c59
Currently widget provider info are loaded from the manifests of
respective packages, which is not performant since loading the
resources from various apps could take a while.
This CL does the following:
1. Instead of persisting only the providers that are bound to the
workspace, we persists all providers.
2. In addition to providers, we also persists the provider info to avoid
loading them from app's resource during a reboot.
Bug: 202356231
Test: atest AppWidgetServiceImplTest
Change-Id: I91fead0b61b0cb84d876dd05781a585805a01400
Behaviorally, this is *almost* a pure refactoring. It does make
one very minor logic change(*) that could hypothetically fix a
race condition, although no particular bugs have ever been
observed as a result (nor do they seem especially probable), and
it's unknown what the severity would be if they ever were to occur.
Additionally, this change clarifies existing comments and adds
more inline documentation to help understand the rebuildList()
flow. Code cleanup identifies a few areas where the current design
seems a little clumsy, noted with new "TODO" comments in the code.
There's room for more improvement, but this function plays an
important role in preparing Sharesheet targets, so it's good to
bring attention to these thorny requirements.
For justifications of behavioral equivalence and other metacognitive
notes, see comments in the code review.
(*) The one behavior change is called out in code review comments;
briefly, the line of code that sends a synchronous "results
pending" event used to follow the line that started the async
flow that would result in a "results complete" event. This
could hypothetically race if the async work finished and sent
"results complete" before we got to the "results pending" line.
Bug: 227486788
Test: `atest ChooserActivityTest` (no behavior changes expected)
Change-Id: I2e74d68579be8b34716ba2202ac2a08361008400
Define the API for interacting with comparator model data;
provide implementations for our two current model types; and
(as a first step) re-write our legacy ResolverComparators
to be implemented internally in terms of their new model types.
This is the first CL in a multi-part cleanup of the
AbstractResolverComparator design. This demonstrates that the
role of an AbstractResolverComparator sub-class amounts to
(i.e., Ctrl+F "@Override") some amount of work to prepare model
data; some cleanup; and a set query methods against data that
*really should be* immutable (separated in this CL as the new
ResolverComparatorModel interace). Any remaining responsibilities
of the abstract base class would be better handled (in a subsequent
CL) by an external controller operating on a ResolverComparatorModel
(i.e., preferring composition to inheritance). The async
model-preparation steps should also be separated and cleaned
up (in a later CL).
I believe this to be a pure refactoring with no observable side
effects. While the new design aids in implementing the correct
"immutable snapshot" style, for now I've written the new
ResolverComparatorModel implementations to preserve any possible
quirks in the legacy implementations. Nevertheless, if some
inadvertant behavior change is introduced as a result of this CL,
it's most likely to be a bug-fix where we previously would've mixed
in stale data. A later CL will intentionally pursue those fixes.
Test: atest ResolverActivityTest ChooserActivityTest
Bug: 227486788
Change-Id: If88bf7a5a6394d81c021782d5d9bce7955f1c0e6
* changes:
[automerge] [Panlingual] Screen title is displayed incorrectly 2p: db37825c6f 2p: c120acc049
[automerge] [Panlingual] Screen title is displayed incorrectly 2p: db37825c6f
[Panlingual] Screen title is displayed incorrectly
Fix the issue that the screen title name of the app language page is
displayed incorrectly
Bug: 227285277
Test: Verify the issue by testing between the system language and app
language page
Change-Id: I229b9ff2defb68d70248a95886d8600e1bc464ea
