Currently, we add a work badge (briefcase icon) to app icons in
the sharesheet. If the target is an app, this results in the
regular app icon with a work badge. However, for direct share
targets we show the person, with the app icon as a badge. This
means that for direct share targets, we show an app icon badge
that itself has a (very tiny) work profile badge.
This change removes the "nested" work profile badge for direct
share targets.
Bug: 179783660
Fix: 179783660
Test: manual (shared something and verified that no direct share
targets have a work profile badge, but work profile apps are still
badged)
Change-Id: I5196184a6f1fb442eee905240656faa6c9fc4cfb
A deadlock path is found:
- FrameTracker$1.lambda$surfaceDestroyed (held A)
- InteractionJankMonitor.end (held B) -> FrameTracker.end (wait for A)
- FrameTracker.end -> InteractionJankMonitor.handleCujEvents (wait for B)
This cl resolves this by using a single lock among monitor and tracker.
Bug: 197804653
Test: atest InteractionJankMonitorTest --rerun-until-failure 100
Test: atest FrameTrackerTest --rerun-until-failure 100
Change-Id: Ia6aa196370bdb51b8a5c84c74a3d174a3d4b689f
Avoid autoboxing longs into Longs by using dedicated long SomeArgs
variables.
Bug: 204459169
Test: Android builds
Change-Id: I4a6056c0cf20a7105553b0db59739434461e9d7e
Avoid autoboxing longs into Longs by using dedicated long SomeArgs
variables.
Bug: 204459169
Test: Android builds
Change-Id: Ic683ffe641bf586b93c08990fb31762b42249b39
This CL introduces the task cancellation mechanism into
RemoteInputConnection and RemoteInputConnectionImpl.
The code idea is to ignore InputConnection tasks if the session IDs do
not match. By incrementing the session ID upon every "interruption",
we can effectively cancel any pending events issued before the
"interruption" happened.
Note that even with this CL RemoteInputConnection and
RemoteInputConnectionImpl still uses "0" as the session ID.
Hence there should be no user observable behavior change yet.
Fix: 203086369
Test: presubmit
Change-Id: I383c3958d2ac1a8d217706509fa12a92b381bbb3
This is useful if/when it's desired that an application contains the same
fully qualified class name that's also in the library.
The shared libraries that are treated in this manor are controlled by the resource
com.android.internal.R.config_shared_libraries_loaded_after_app
Bug: 179429740
Test: atest SharedLibraryLoadingTests
Change-Id: Ia37ff9bd545918d1e0f1f38548dcd86f177559d5
APEXes can already contain RRO APKs by using the 'rro' apex Soong
module field. However, these RROs were not being loaded properly by
Zygote or PackageManagerService.
For all RROs inside APEXes, the RRO uses the same overlay config that
is used for other RROs on the APEX's preinstalled partition.
For RROs targeting 'android', which are installed by Zygote
using AssetManager:
1. OverlayConfig looks for active APEXes in the apex-info-list file,
which is already accessible to Zygote.
2. OverlayConfig passes the APEX module names to OverlayConfigParser,
for each preinstalled-partition.
3. OverlayConfigParser uses OverlayScanner to scan the
each /apex/<APEX>/overlay directory.
For other RROs:
1. PackageManagerService already parses and provides RROs inside APEXes
to OverlayConfig.
2. RROs inside APEXes used to have no config rule applied because their
path prefix (/apex/) did not match any partition rule. Now, their
preinstalled path is used instead.
Bug: 199200417
Test: Define a static RRO targeting 'android' inside a /vendor APEX.
Define a static RRO for settings provider inside a /vendor APEX.
Observe APEXes are enabled by default.
Test: Make a change to an RRO inside a /vendor APEX.
m <apex>; adb install <apex artifact>; adb reboot;
Observe change has taken effect.
Change-Id: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
Merged-In: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
Add jank instrument support for splash screen avd and exit animation.
Bug: 195736656
Test: see trace in comment
Change-Id: I1fdb9e14145bcf519eea99e440de74238e3c765c
Also, simplify the design of MeasuredEnergyStats by separating
data from configuration
Bug: 191921016
Test: atest FrameworksCoreTests:BatteryStatsTests
Change-Id: Iff6eb6ded644fbc6886f6a7efdb6577b1fa42cf5
APEXes can already contain RRO APKs by using the 'rro' apex Soong
module field. However, these RROs were not being loaded properly by
Zygote or PackageManagerService.
For all RROs inside APEXes, the RRO uses the same overlay config that
is used for other RROs on the APEX's preinstalled partition.
For RROs targeting 'android', which are installed by Zygote
using AssetManager:
1. OverlayConfig looks for active APEXes in the apex-info-list file,
which is already accessible to Zygote.
2. OverlayConfig passes the APEX module names to OverlayConfigParser,
for each preinstalled-partition.
3. OverlayConfigParser uses OverlayScanner to scan the
each /apex/<APEX>/overlay directory.
For other RROs:
1. PackageManagerService already parses and provides RROs inside APEXes
to OverlayConfig.
2. RROs inside APEXes used to have no config rule applied because their
path prefix (/apex/) did not match any partition rule. Now, their
preinstalled path is used instead.
Bug: 199200417
Test: Define a static RRO targeting 'android' inside a /vendor APEX.
Define a static RRO for settings provider inside a /vendor APEX.
Observe APEXes are enabled by default.
Test: Make a change to an RRO inside a /vendor APEX.
m <apex>; adb install <apex artifact>; adb reboot;
Observe change has taken effect.
Change-Id: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
