* changes:
Revert "Replace AssetManager with AssetManager2 implementation"
Revert "libandroidfw: Make sure to set the 'app as lib' flag"
Revert "Make idiomatic use of ApkAssets and AssetManager"
Revert "libandroidfw: Add ApplyStyle and SetConfiguration benchmark"
Revert "libandroidfw: Improve performance of AssetManager2"
Revert "AssetManager2: Allow out of order type/type spec"
Revert "AssetManager2: Fix list function"
Revert "AssetManager2: Fix issue with native cast"
Send a protected system broadcast to apps that hold
the INSTALL_PACKAGES permission whenever a change to
properties like locale or display density happens.
Receivers can be registered in the manifest, and a process
will be woken up to receive the broadcast.
This will happen rarely, since the configuration changes
eligible to trigger this broadcast are rare themselves.
Bug: 63918966
Test: manual
Change-Id: I817a51ea05f762e02561691825d57d643db7dc30
Resources.getDrawable() was annotated @Nullable because there was one
very particular path where Bitmap decoding would fail and trigger a null
return.
As part of the switch to ImageDecoder, that path was changed to now throw
an IOException, which will result as a NotFoundException to the caller of
getDrawable.
This CL annotates that path as @NonNull to reduce pain of dealing with
@Nullable method that was very unlikely to be null in practice.
Also fixes many other missing nullability annotations, and relabel
many @Nullable paths that would never return null in practice as
@NonNull.
Bug: 69543526
Test: ResourcesTest
Change-Id: Ib01eca970c5c9969998ce5b265b120aa7048b41a
Add @GuardedBy for simple functions that require a single lock
and are named XYZLocked.
Bug: 73000847
Test: m
Test: m javac-check-framework RUN_ERROR_PRONE=true
Change-Id: Icb5114fea2ff2385e1cc7511121026099e05c0ee
Public EuiccManager and other related necessary files.
Mark EuiccCardManager and other related necessary files as @SystemApi.
Solve lint errors and warnings.
Bug: 35851809
Test: test on phone
Change-Id: Id7895f9b35ce9d4fb6fae42ba89ca9b29dbfa74c
commit: 5cdda3425c added a new flag,
GET_SIGNING_CERTIFICATES to PackageManager for use with getPackageInfo
that returns the signing certificate history, including the current signer,
of the given package. This is intended to replace the existing
GET_SIGNATURES flag and corresponding field. The previous commit did not,
however, implement the read/write Parcelable methods so that this
information could be reconstructed client side. Implement those methods
to actually expose the new API.
Bug: 64686581
Test: Test app pull of PackageInfo with GET_SIGNING_CERTIFICATES succeeds.
Change-Id: I1c023da2a6fd03e11432953080045a79b9f56839
* changes:
libandroidfw: Improve performance of AssetManager2
libandroidfw: Add ApplyStyle and SetConfiguration benchmark
Make idiomatic use of ApkAssets and AssetManager
libandroidfw: Make sure to set the 'app as lib' flag
Replace AssetManager with AssetManager2 implementation
This change adds some additional digest prefixes to instant app
resolution to make inverting the hash more difficult.
Change-Id: Ibf907495019338b5cac5dd22da275799e92f9b60
Fixes: 63445230
Test: manual - resolution still works with current production resolver
Test: Existing tests
Add a new (hidden) ImageDecoder.Source that accepts an AssetInputStream.
This allows us to create an AnimatedImageDrawable without fear of the
client closing the stream.
Call it from ResourcesImpl instead of Drawable.createFromResourceStream.
Change-Id: I07e00ca60c97538335a6310e830b73211fd8e7bb
Teach the overlay manager about upgrades and uninstalls of overlay
packages. Add two transient overlay states STATE_TARGET_UPGRADING and
STATE_OVERLAY_UPGRADING.
Test: atest OverlayHostTests
Change-Id: I2d04204150f9e749f070b4e4363eacbd59355014
Move away from using deprecated addAssetPath methods
and cache the instances of ApkAssets created.
Test: CTS passes
Change-Id: Ie95cd5a9e205a35806e7b142df5af02aa90d83ca
When generic intent resolution support was added to instant apps, it
added the requirement that web instant app resolution also require the
BROWSABLE category. This change relaxes that requirement.
Test: manual - sent intent without browsable and observed resolution
Change-Id: I7d4d891484f538b46d37f2c8e7c040b370b46b9e
Fixes: 72835413
Autofill helps users fill credentials, addresses, payment methods,
emails, etc without manually typing. When focus lands on a fillable
element the platform captures a snapshot of the screen content and
sends it to an autofill service for analysis and suggestions. The
screen snapshot is a structured representation of the screen content.
If this content is composed of standard widgets, autofill works
out-of-the-box. However, some apps do their own rendering and
the content in this case looks like a single view to the platform
while it may have semantic structure. For example, a view may render
a login page with two input test fields.
The platform exposes APIs for apps to report virtual view structure
allowing autofill services to handle apps that have virtual content.
As opposed to apps using standard widgets, this case requires the app
developer to implement the new APIs which may require a fair amount
of code and could be seen as a processes that could take some time.
The most prominent typs of apps that fall into this category are
browsers.
Until most apps rendering virtual content and specifically browsers
don't implement the virutal APIs, autofill providers need to fall-
back to using the accessibliity APIs to provide autofill support
for these apps. This requires developers to work against two sets
of APIs - autofill and accessibility - which is incovenient and error
prone. Also, users need to enable two plugins - autofill and
accessibility which is confusing. Additionally, the privacy and
perfomance impact of using the accessibility APIs cannot be addressed
while autofill providers need to use thes APis.
This change adds an autofill compatibility mode that would allow
autofill services to work with apps that don't implement the
virtual structure autofill APIs. The key idea is to locally enable
accessibility for the target package and remap accessibility to
autofill APIs and vise versa. This way an autofill provider codes
against a single set of APIs, the users enable a single plugin,
the privacy/performance implications of using the accessibility
APIs are addressed, the target app only takes a performance hit
since accessibility is enabled locally which is still more efficient
compared to the performance hit it would incur if accessibility is
enabled globally.
To enable compatibility mode an autofill service declares in its
metadata which packages it is interested in and also what is
the max version code of the package for which to enable compat
mode. Targeted versioning allows targeting only older versions of
the package that are known to not support autofill while newer
versions that are known to support autofill would work in normal
mode.
Since compatibility mode should be used only as a fallback we
have a white list setting with the packages for which this mode
can be requested. This allows applying policy to target only
apps that are known to not support autofill.
Test:
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
bug:72811034
Change-Id: I11f1580ced0f8b4300a10b3a5174a1758a5702a0
The majority of Manager-style classes already use Context.getUserId()
when making calls into the OS, so clean up the remaining callers to
unify behind this strategy.
This gives @SystemApi developers a nice clean interface to interact
across user boundaries, instead of manually adding "AsUser" or
"ForUser" method variants, which would quickly become unsustainable.
Test: builds, boots
Bug: 72863821
Exempt-From-Owner-Approval: trivial changes
Change-Id: Ib772ec4438e57a2ad4950821b9432f9842998451
openWrite() and openRead() are very flexible APIs, but their design
means they can't take advantage of the recent FileUtils.copy()
optimizations that leverage in-kernel copying.
So add new write() and read() methods where the untrusted caller
hands an FD into the OS, and then PackageInstaller drives the actual
copying process, allowing it to use FileUtils.copy() to speed
up the copying process. (Local benchmarks are showing a 24% speed
improvement.)
We still create a FileBridge to protect the session while an active
copy is happening.
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978, 25510838
Change-Id: Icc237b4c0f80d5d24b74a30f238b7fe505b856ce
