If an application caches an ApplicationInfo and uses it to call
Context#createApplicationContext, the app will not get the most recent
version of the overlays for that application. To make things worse, the
LoadedApk stored in ActivityThread#mResourcePackages is updated using
the old ApplicationInfo causing further uses of the cached LoadedApk to
return outdated information.
Deprecate Context#createApplicationContext, convert all internal uses
to Context#createPackageContext(String packageName, ...) and log
whenever any one calls Context#createApplicationContext with an
outdated ApplicationInfo to detect debug issues in using old infos.
Bug: 188059515
Test: change wallpaper and observe widgets get reloaded with most
recent overlays
Change-Id: I2aeefa8c0e66264859109975a54c4f73f76ad710
To avoid a non-system installer repeatedly silent updates and
'denial-of-service' against another app on the device. This CL
tracks for all the silent updated installs where the
`requireUserAction' is not required. And fall back to user
action required if a repeated silent update is requested within
the throttle time.
Bug: 185878964
Test: atest SilentUpdateHostsideTests
Test: atest StagingManagerTest
Test: atest PackageInstallerSessionTest
Change-Id: I4ea287bf66d8661eec2676b604f9109f6f9add28
In device booting, PackageParser2 uses a thread
local ParseTypeImpl obj as shared result and reset
it before parsing everty time. But it doesn't reset
the target sdk version, which could make deferError
returned unexpected error, cause apk scaned failed
and deleted by the system.
Test: atest com.android.server.pm.parsing
Change-Id: Ie6fbc4b79e94943c9282206b1ef6d20b4129fa0b
Signed-off-by: liulvping <liulvping@xiaomi.com>
Included changes:
* b692f37: Rename `Int64` in annotation processor to `Long`.
* 05fe08c: Get QueryLength from Native
* 8f46606: Logging stats for remove (1)
* 237c134: Alter inheritance of LongProperty for backwards compatibility.
Bug: 187820569
Bug: 173532925
Bug: 173532925
Bug: 187820569
Test: Presubmit
Change-Id: Ia27e00250e7aa7c7a1acc974f24c63cc456739be
Components within an application are often a good boundary for
developers to declare "attribution" information, such as an Activity
or Service used to offer a specific sub-feature.
This change expands the "android:attributionTags" manifest attribute
to apply to all component types, and it then automatically configures
the associated Context with Context.createAttributionContext() with
no additional developer action required. Developers can still
manually use Context.createAttributionContext() to adjust the
attribution tag again if desired.
Bug: 187097694
Test: atest CtsAppOpsTestCases:AttributionTest
Test: atest CtsAppTestCases:android.app.cts.AttributionTagsTest
Change-Id: Ia16c66e7b63bcbfb8c0d7348e9b5d4adb2a1f45d
There are some Parcelables which offer to perform Binder calls, and
when these are delivered via Intent extras they fallback to
ActivityThread.currentAttributionSource(), instead of being tagged
based on the relevant app component.
This change begins using Intent.prepareToEnterProcess() as a hook to
fix-up AttributionSource when those extras finally land in the
destination process. It uses the relevant AttributionSource based
on the Activity or Service the Intent is delivered to, which
developers have control over via AppComponentFactory.
In the case of <receiver> manifest elements, this change applies the
first android:attributionTags value to the Context used for that
BroadcastReceiver.
Bug: 187097694
Test: atest AttributionTest
Change-Id: I8f5197db7e8d7277d34f0ef2bb90bfdf1871186a
The method is called by CTS helper app to list all java shared libraries
present on the device. All classes present in the reported jar/apk files
are then collected by a CTS/GTS EDI collector.
Bug: 187823488
Test: m
Change-Id: I750065112d70bc3ab45c8b6c6cc8aa4d429488a8
Bug: 187429663
Test: Checked ApplicationInfo.hasRequestForegroundServiceExemption()
of a test app, with and without the new attribute set.
Change-Id: I98342a35a82e44327db896c9820806eb3eda5b4c
Change the usage of global compatibility mode enabled state back to
PackageParser first until the tests are ready to ensure the behavior
is consistent.
Bug: 186592266
Test: atest CtsCompatibilityModeTestCases
Change-Id: Ib57886c095a7b2f6e797ccdaa2890f3ad60f5482
Under specific conditions, parceled list can be written in such a
way that writing of new list starts when destination parcel is
just above MAX_IPC_SIZE. In that case "0" is written to parcel to
indicate that there will be no inline items written and writing of
the list will start with extra items.
When unparcelling such list, listElementClass is not determined and
stays equal to null, because it only can be determined if there
were some inline items read first, before switching to extra.
This leads to random unparcelling failures with the following
error message:
Can't unparcel type <typename> in list of type null.
Test: manually verified
Bug: 186193371
Fix: 151481291
Bug: 156514418
Fix: 169191099
Change-Id: I849bf46158b6d9b109139b19b93a6a1ba16ecc77
