summaryrefslogtreecommitdiff
path: root/core/java/android/app/LoadedApk.java
Commit message (Collapse)AuthorAgeFilesLines
* Fix incorrect context classloader initialization in system_serveryuanhuihui2022-11-021-1/+1
| | | | | | | | | | | | | | | | | https://code.google.com/p/android/issues/detail?id=331471 not only mPackageName.equals("android") run in system_server, but also contains the following package: - com.android.providers.settings, - com.android.server.telecom, - com.android.location.fused. when make application for these package will modify system_server classloader which is not we want. Test: intern stability test Change-Id: I831f6d6ec1d63edad592b05df7c1c2493afeff10
* Set correct volume storage path for SDK sandboxSanjana Sunil2022-05-161-5/+8
| | | | | | | | | | | | | | Context.getDataDir() for SDK sandbox incorrectly returns /data volume path even if the actual storage is on another volume. This CL sets the correct storage path by checking the uuid from the ApplicationInfo of the client app and setting it to the same value. Bug: 229736419 Test: atest SdkSandboxStorageHostTest#testSdkSharedStorage_DifferentVolumeIsUsable Change-Id: Ib72ea559363cdeb4b7cfcc2f48ca8ddace96e352 Merged-In: Ib72ea559363cdeb4b7cfcc2f48ca8ddace96e352
* Set correct storage path for SDK sandboxSanjana Sunil2022-03-101-0/+21
| | | | | | | | | | | | | For WebView to run in an sdk sandbox process, Context.getDataDir() needs to return the shared sandbox storage. This CL sets the value in LoadedApk while binding the application and modifies bindSdkSandbox API to take in the client app package name to use in the path. Test: Manual, check that WebView in sandbox tries to access sandbox shared storage Bug: 216284889 Change-Id: I1f8bb7e533d155050710866b80047ec849a98f35
* Fix compat issue with apps directly calling LoadedApk.makeApplication().Makoto Onuki2022-03-091-5/+30
| | | | | | | | | | | Unfortuantely, it seems apps may be calling makeApplication() directly, in which case returning the cached instance would break their expectation. So let's not return the cached instance for external callers. Test: Launch the kr.go.kdca.coov-19 app Fix: 222737976 Change-Id: Idd7d2873d71edad182a7877117745fe021e18a80
* Never instatiate App class multiple timesMakoto Onuki2022-02-241-21/+13
| | | | | | | | | | | | | | - GMS-core is still sometimes seeing the app class being instatiated multiple times. Let's just cache the app instance to avoid such situations. - Also removed some tentative WTFs, which have never been triggered. (so they should be unrelated to the dup-app bug) Bug: 185177290 Test: Boot / treehugger Change-Id: I4c74a5798264472d1bfbf5604f399a49e5946c64
* Revert "Disable per-process app class to investigate"Makoto Onuki2022-02-231-6/+4
| | | | | | | | | | | | | | | Revert "Disable per-process app class to investigate (disabling CTS)" Revert submission 16804724-disable-per-proc-app Reason for revert: The revert has reached weekly. Now I'll revert it to see what change it made. Reverted Changes: I87f16857b:Disable per-process app class to investigate I87f16857b:Disable per-process app class to investigate (disa... Change-Id: Ib84035c7819acc347e0bbba8bfada66300778c63 Test: treehugger Bug: 185177290
* Improve broadcast tracingTim Murray2022-02-081-1/+5
| | | | | | | | | | Include the name of the broadcast that is being handled in the tracepoint for receivers registered both at runtime and in the manifest. Test: TH, traces Bug: 208747905 Change-Id: I624cd434c5066296e55f4c8bb8c46de65bfe635c
* Disable per-process app class to investigateMakoto Onuki2022-02-071-4/+6
| | | | | | Test: treehugger Bug: 185177290 Change-Id: I87f16857bc0c2b6ed5ff00a0c042a4706864d21a
* SDK -> SDK_PACKAGE to address API feedback.Alex Buynytskyy2022-01-281-0/+4
| | | | | | | | | | +documentation updated, +don't load SDKs automatically. Bug: 208096588 Bug: 210622326 Test: presubmit Change-Id: I52efce96111ba72a788404f5eca92da2554fc807
* Add checks to detect wrong conditions when creating ApplicationsMakoto Onuki2022-01-121-1/+32
| | | | | | Bug: 185177290 Test: Boot + monitor logcat Change-Id: Icd9f5e891c7b7fe32ee4144d95dd26139b87d9cf
* Support per-process Application class (AM and client side)Makoto Onuki2021-12-131-1/+3
| | | | | | | | | | | Now the <process> tag supports `android:name`, which takes a custom Application class name. If omitted, the system defaults to the class set in the <application> tag, or the default class which is `android.app.Application`. Bug: 197264681 Test: atest CtsProcessTest Change-Id: I0650a4a7c75dc37c00875e4f0ac53656f1cbeac9
* Merge "Allow a shared library to be positioned after the application on the ↵Brad Stenning2021-10-271-12/+41
|\ | | | | | | | | | | | | | | classpath" am: 3120b13f56 am: 6e2646eacd am: dfb49ce58c am: 779d574b3d Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1852914 Change-Id: I2e3425881355d2c5185038e2868b55b02867d973
| * Allow a shared library to be positioned after the application on the classpathBrad Stenning2021-10-271-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Check if APK paths are valid right before creating the context.Pierre Barbier de Reuille2021-10-251-0/+34
|/ | | | | | | | | | | | The check has to be done in RemoteViews and in AppWidgetHostView right before creating the context used to inflate the app widget. Further, the APK is cached potentially in two places: in the APK with code and the APK without codes, so both places are updated if present. Test: manual, see bug for details Fix: 202369942 Change-Id: I5718f67711a3332a942d3c037eef7f30379549a4
* Merge "[pm] drop non-APK paths from LoadedApk makePath" into sc-devTreeHugger Robot2021-06-231-0/+4
|\
| * [pm] drop non-APK paths from LoadedApk makePathSongchun Fan2021-06-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | After the introduction of the uses-native-library tag, sharedLibraryFiles might contain native library names such as "lib_aion_buffer.so". The old method makePath in the LoadedApk class was looking for APK paths under the assumption that all the paths in sharedLibraryFiles are APK paths. Parsing on the results of makePaths could lead to app crashes because the results are not valid APK paths. This CL fixes that. BUG: 190787130 Test: manual Change-Id: I2b3d439f8edda7ef27e1106046cf8c0b88d755d9
* | Register the DexLoadReporter before creating the main class loaderCalin Juravle2021-06-141-8/+15
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | We used to register the DexLoadReporter after the main class loader was created. That was done to avoid superfluous reports of the app's primary apks (since we already know about them). However that also means that if the app would start as an isolated process we would miss this signal in the DexManager. Make sure we get signals for isolated processes by registering the reporter before we create the main class loader. Test: manual, using chrome and maps go adb shell cmd package compile -m speed-profile com.android.chrome adb shell am start -n \ com.google.android.apps.mapslite/com.google.maps.lite.twa.MapsLiteTwaLauncherActivity adb shell dumpsys package dexopt (confirm that chrome is used by an isolated process) adb shell cmd package compile -m speed-profile com.android.chrome (confirm that chrome is speed compiled - or verify, based on the device setting) Bug: 163018062 Merged-In: I5d683ae85b3973cc2011dd33b4cb14837b18005f Change-Id: I5d683ae85b3973cc2011dd33b4cb14837b18005f (cherry picked from commit 875888eff38e3a6c1369bbb9c2336e7b97758c51)
* Merge "Don't call onNullBinding when the service host is dead" into sc-devJing Ji2021-05-281-6/+7
|\
| * Don't call onNullBinding when the service host is deadJing Ji2021-05-261-6/+7
| | | | | | | | | | | | Bug: 189038850 Test: atest CtsAppTestCases Change-Id: I8bcdaf545ee8ca46327fc25c14d9821e288600a4
* | Disable incremental hardening on own resourcesRyan Mitchell2021-05-271-0/+4
|/ | | | | | | | | | | | | | | When an application is incrementally installed, and a resources operation fails due to the resources not being fully present, the app should crash instead of swallowing the error and returning default values to not alter the experience of using the application. Disable IncFsFileMap protections on ApkAssets that are a part of the application that is running (base and splits). Bug: 187220960 Test: atest ResourcesHardeningTest Change-Id: Ibc67aca688720f983c7c656f404593285a54999b
* Update the use of registerAppInfoCalin Juravle2021-05-211-13/+19
| | | | | | | | | | | | | | Pass additional parameters to ART to assist with better profiling and debuggability. (cherry picked from commit 3e308c62708443e24ba44ecac683a7fe4d9a7ac2) Test: m Bug: 182793486 Bug: 185979271 Merged-In: Iae0beab92194d75f191147578922c760f04470b9 Change-Id: Iae0beab92194d75f191147578922c760f04470b9
* Apply AttributionSource during Intent delivery.Jeff Sharkey2021-05-151-1/+2
| | | | | | | | | | | | | | | | | | | | | 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
* Add a synchronized lock into the SplitDependencyLoaderImplRhed Jao2021-04-261-25/+40
| | | | | | | | | | | | | | | | | | - There's a potential race condition going on when components from the isolated split are creating the split class loader. Add a synchronized lock for the array of cached class loaders and resource paths to prevent the race. - Remove the synchronized class reference of LoadedApk. Using an explicit mLock object to synchronize the #createOrUpdateClassLoaderLocked() and cached split class loader instead. Bug: 172602571 Test: atest IsolatedSplitsTests Test: atest ClassloaderSplitsTest Test: atest SplitTests Change-Id: Ifb77d067ddf06b5192d7ce9d4e78958b56faac7c
* Add IllegalStateException with packageName on null infoPatrick Baumann2021-03-091-0/+4
| | | | | | | | | | | | | This change returns the behavior of initializeJavaContextClassLoader in LoadedApk to throw an IllegalStateException calling out the package it attempted to fetch. This was removed when client-side caching was added resulting in a different stack trace without this critical piece of information that could help make sense of why this is happening. Bug: 180418767 Bug: 140788621 Test: N/A; builds Change-Id: Ia1ceff922f693093012eb6e3e0f6e1d90222cde7
* Add overlayPaths to ApplicationInfoRyan Mitchell2021-02-081-8/+21
| | | | | | | | | | | | | | | RROs have historically been APK packages. We now have the ability to generate RROs on-the-fly. These "fabricated" RROs are not APKs. ApplicationInfo#resourceDirs documentation states that it only contains paths to packages. To prevent changing the behavior of resourceDirs until we can deprecate and remove it, a new overlayPaths field has been added to ApplicationInfo. This new field contains APK overlay paths as well as non-APK overlay paths. Bug: 172471315 Test: boot enable/disable overlays and examine overlays working as well as package manager dumpsys Change-Id: I78c5eeef73b7d8bada61edc0f64a12a3cdc1ce16
* Add StrictMode check for unsafe intent launchingJeff Sharkey2021-01-201-1/+3
| | | | | | | | | | | | | | Exported components that are not guarded by a signature permission can receive Intents from any other app on a device. If an app unparcels and launches an Intent from the Intent delivered to this unprotected component then a malicious actor can potentially craft an Intent that could launch hidden components, grant URI permissions, etc. This commit adds a StrictMode check to report if a component launches an Intent unparceled from the delivered Intent. Bug: 160796858 Test: atest StrictModeTest Change-Id: I763b8a965f91f5b433ce2f4b619e10ef12f5c296
* Disable CE access checking for canAccessDataDir.Alan Stokes2020-12-161-2/+26
| | | | | | | | The access is correct, so we don't want StrictMode to kill us. Fix: 174750397 Test: Presubmits Change-Id: I14561a4fc1e0195d658dafd7532c8412f51ba386
* Add packageName to instantiation exception log.Martijn Coenen2020-12-041-1/+1
| | | | | | | | | So we can figure out what package we failed to instantiate an app class for. Bug: 174771490 Test: N/A Change-Id: I554138375ede9421ba053547bbc0250f3b2e812a
* Remove pi.append_native_lib_paths propertyPatrick Baumann2020-11-121-2/+1
| | | | | | | This change removes the "pi.append_native_lib_paths" property added as a kill switch for a feature that has been out in the wild now for several releases now. Change-Id: I21f9d158f60d0cf47e3631bb37ece711b3450494 Fixes: 173103133
* De-restrict LoadedApk.getCompatibilityInfo().Mathew Inwood2020-11-041-1/+1
| | | | | | | | It is relied on by blaze mobile-install. Bug: 172409979 Change-Id: Idefbd92fd4a2887f49b50455478b96435b6ce351 Fixes: 172083033
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-291-7/+7
| | | | | | | | | | | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. This is a resubmit of ag/12929664 with some APIs excluded that caused test failures; see bugs 171886397, 171888296, 171864568. APIs excluded: Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord; Landroid/os/Process;->myPpid()I Landroid/os/SharedMemory;->getFd()I Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I Bug: 170729553 Test: Treehugger Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
* Revert "Add maxTargetSdk restriction to unused APIs."Hongwei Wang2020-10-281-7/+7
| | | | | | | | | This reverts commit 72f07d6a8a32db4a0dedd7682a0b3385be2b9cd6. Reason for revert: Droidcop-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?testMethod=testAppZygotePreload&testClass=android.app.cts.ServiceTest&atpConfigName=suite%2Ftest-mapping-presubmit-retry_cloud-tf&testModule=CtsAppTestCases&fkbb=6936597&lkbb=6936969&lkgb=6936551&testResults=true&branch=git_master&target=cf_x86_phone-userdebug>, bug b/171886397 Bug: 171886397 Change-Id: Ibe0f0430a3451477c1ee8ef56a596e91ea1e7672
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-271-7/+7
| | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. Bug: 170729553 Test: Treehugger Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
* Don't override config of display contexts with activity display.Darryl L Johnson2020-08-201-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change migrates the previous usages of ResourcesManager#getResources() from using the display id of expected resources to an override display ID which will override the display properties from the parent token resources. This ensures that all contexts derived from a display context keep the overrides for their intended display. This also changes the meaning of ResourcesKey#mOverrideConfiguration and ResourcesKey#mDisplayId. Previously mDisplayId was used as both the current display of the ResourcesKey and used to apply overrides to mOverrideConfiguration. This made it unclear whether a particular key should keep its display override when an activity changes display or whether it should inherit the new display from the activity. Now the display IDs and overrides are managed by the ActivityResources struct and the ResourcesKey is expected to only contain the final display ID expected for the resources in 'mDisplayId' and the final configuration that should be applied to the global configuration in 'mOverrideConfiguration'. Fixes: 153866583 Fixes: 156758475 Fixes: 163813210 Fixes: 163812902 Fixes: 163813227 Test: ActivityThreadTest Test: ResourcesManagerTest Test: AppConfigurationTests#testActivityContextDerivedDisplayContextOrientationWhenRotating Change-Id: If93f98f93ee15b27d8c7292a2f830c2cc0f49277
* Don't include inaccessible data dirs in library paths.Alan Stokes2020-07-231-6/+30
| | | | | | | | | | | | | | When constructing a classloader for a different app, don't include it's private data dir in libraryPermittedPath if we don't have access to it. (Which we often won't, although it depends on target SDK, whether it has a shared UID, etc.) This avoids generating SELinux denials at boot and other times, e.g. when initialising WebView. Bug: 161356067 Test: Boots, denials not seen, WebView works. Change-Id: Ib246af979783e80fde3313f8aed6c3b7a886e6b2
* Introduce uses-native-library tagJiyong Park2020-07-211-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Android 7.0, partners were able to export some of their native shared libraries to apps. So far, the native libraries were provided to all apps regardless of whether they are actually needed or not. Even worse, it was impossible to prevent the installation of an app to the device where the some (or all) of the required native libs don't exist; the apps had to manually handle the case, which sometimes impossible when the dependency is so fundamental. This change introduces a new tag <uses-native-library> to the app manifest. Similary to the existing <uses-library> tag which is for (java) shared libraries, the new tag is used to describe the depedencies to the native shared libraries. Apps targeting Android S or higher are required to use the tag to import the native shared libraries. Libraries that are not depended on won't be available to the app even if the libraries are listed in the public.libraries*.txt files. Furthermore, when the dependency can't be satisfied for an app, the package manager refejects installing the app. The dependency can be optional using the `android:required` attribute. When it is set to true, the absence of the lib on the device doesn't prevent the app from being installed. However, the app has to gracefully deal with the absence. The changed behavior only affects apps targeting S or higher. Existing apps are unaffected; they still get all the public native libraries regardless of whether they have <uses-native-library> tags or not; the tags are simply ignored. This is the first version of the implementation and therefore needs further refinements. The followings are two major TODOs. 1) The native shared lib dependencies of the java shared libraries are not enforced. For example, if an app depends on a java shared library foo and foo depends on some native shared libraries, the classloader where code from foo is loaded still gets all native shared libraries. This should be fixed. 2) New APIs should be added. SharedLibraryInfo should be extended to represent native shared libraries. The meaning of ApplicationInfo.sharedLibraryFiles should be revised. Finally, the new tag should be made public. Bug: 142191088 Test: atest CtsUsesNativeLibraryTest Change-Id: Iceb038aa86872d23e9faf582ae91b1fdcaf5c64c
* Allow to load implicit layer from /vendor/app.Peiyong Lin2020-06-031-0/+28
| | | | | | | | | | | | | | | Currently when loading implicit layers from apks, NativeLoaderNamespace doesn't allow to dlopen the binaries if they come from apks from /vendor/app. Implicit layers ship within /vendor/app should work like other implicit layers. This patch extracts the construction of library paths of the implicit layers and includes those paths when NativeLoaderNamespace is created as the part of the permitted library paths. Bug: b/157832445 Test: atest android.gputools.cts.CtsRootlessGpuDebugHostTest Test: setup debug layer and use adb logcat to check vulkan loader output Change-Id: Ie2ca989bcab890578b5aa540d07f2aee2a0182bd
* Don't include the data dir in zygote library paths.Torne (Richard Coles)2020-03-251-0/+5
| | | | | | | | | | | | | | When creating a LoadedApk in a zygote context (app zygote or WebView zygote), don't add the app's data dir to the list of paths the dynamic linker is allowed to load libraries from, because the linker's attempt to canonicalize the path causes SELinux access denials. The process can't access the data directory at all, so cannot load libraries from there in any case. Fixes: 149481620 Test: check for avc denials from webview_zygote Change-Id: I9aceecaf6067e748cc2251782b0f41661cbb35d8 (cherry picked from commit e1579d4d14119e688fa3952d6bbc44ef81f942fe)
* Merge "Resolve conflicting values of usesCleartextTraffic for shared processes"Ashwini Oruganti2020-02-211-0/+4
|\
| * Resolve conflicting values of usesCleartextTraffic for shared processesAshwini Oruganti2020-02-211-0/+4
| | | | | | | | | | | | | | | | Bug: 148240416 Test: Manually tested by installing two apps running in a shared process and starting their shared process activities in various orders. The value of usesCleartextTraffic gets set as expected. Change-Id: Ib350c09c42d5524734fb259a2ab787790f2d8e30
* | Cache package and permission informationDaniel Colascione2020-02-201-11/+5
|/ | | | | | | | | | We use the package settings class as a central point for invalidating on package information changes; for permission changes, we invalidate from inside the individual permission data objects. Bug: 140788621 Test: boots, package tests (pending) Change-Id: Iec14d4ec872124e7ef4612c72d94c89a7319ace0
* Refactor ResourcesLoader APIsRyan Mitchell2020-01-281-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes refactors the ResourcesLoader APIs. The main changes are: Rather than pairing a ResourcesLoader with a ResourcesProvider, a ResourcesProvider is paired with an AssetsProvider which is only responsible for overriding the values of file-base resources and assets. An AssetsProvider can be shared between multiple ResourcesProviders. ResourcesLoader now holds a list of ResourcesProviders. ResourcesLoaders are part of ResourcesKeys and requests for resources with the same loaders will use the same underlying ResourcesImpl. This allows the loader specific code in RM to be cleaned up. ResourcesLoaders and Resources objects use callbacks to notify RM of changes to the Resources instance that may require a new ResourcesImpl. When a context is created from another context, the new context will include the loaders of the original context. Change to list of either context's loaders will not change the loaders of the other context, but changes to the providers a loaders uses will update all Resources objects that use that loader. Activity resources will include the loaders of the application context at the time of the Activity's creation. Bug: 147359613 Test: atest ResourceLoaderTests Change-Id: I2957c803d3f0c1280abfd3c723d76b18df2c3789
* Merge "Rewrite R constants before creating Application"TreeHugger Robot2020-01-221-14/+14
|\
| * Rewrite R constants before creating ApplicationRyan Mitchell2020-01-161-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | An app accessing R constants in the constructor of its Application must be able to use resources from shared libraries that it uses. This changes moves onResourcesLoaded to be invoked before creating the Application. Bug: 147686280 Test: adb shell am start-activity \ com.android.phone/com.android.phone.CallFeaturesSetting Change-Id: I574f144bf983080cef43fc79dbc4814266586d2d
* | Add instrumented app to JAR path (isolated splits)Jason O'Brien2020-01-161-1/+3
|/ | | | | | | | | | The base APK is loaded during normal execution even when isolated splits are requested. This preserves that behavior during instrumented tests, which previously skipped the base APK (causing class loading errors). Test: tested on device with a trivial automated instrumented test Bug: 146183755 Change-Id: Ia54072ee91b7c06cb4a787a8954ad2e69b322cac
* Check mIncludeCode before building appComponentFactoryWinson2020-01-101-1/+1
| | | | | | | | | | | | | It should be impossible to resolve a custom appComponentFactory if the LoadedApk doesn't contain any code paths, so just skip it to avoid logging an incorrect error. Bug: 146219140 Test: manual force updateApplicationInfo call, verify bunch of errors before fix, no logs after fix; rest of device works Change-Id: Icbb8533c95c9437ec0a946886e00b9c341e21796
* Merge "Use ro.product.vndk.version for unbundled product apks" am: ↵Automerger Merge Worker2020-01-031-7/+6
|\ | | | | | | | | | | cbfcd44f68 am: e0e165f06e am: bbce9e0c5a Change-Id: I781e0f1f9e70e584b986d5b2c7e7e87804c52157
| * Use ro.product.vndk.version for unbundled product apksJustin Yun2020-01-021-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using "ro.product.apps.unbundled", use "ro.product.vndk.version" to determine if product apks are unbundled. "ro.product.vndk.version" will be defined by PRODUCT_PRODUCT_VNDK_VERSION. If it is defined, all product apks must be unbundled. Bug: 144534640 Bug: 127738095 Bug: 128557860 Test: boot and check logs if product apps are loaded successfully Change-Id: I6d0f7c20e131dfe12203c63a14e6254a8223893b
| * Revert "Fix: vendor public libraries are accessible via System.loadLibrary"Jiyong Park2019-09-101-42/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit cfe38cdb1cc45c8b7dcbe4f39329551f6602b9ce. The CL 8f712189dfc02285573337e2b4ab17678011db14 in libcore project avoids the need for adding the new paths in LoadedApk. With the CL, a classloader does not give up even when loader.findLibrary() has failed due to some paths are not added to it. Instead, the classloader converts the given libname into a filename (e.g. foo -> libfoo.so) then calls dlopen() with the filename. The classloader reports failure only when the dlopen() call has failed. Therefore, manually adding these paths to the classloader is no longer needed and thus removed. Bug: 109720125 Test: System.loadLibrary("adsprpc") is successful in Pixel (because libadsprpc.so is in Pixel's vendor public lib list) Test: atest cts/tests/tests/jni Merged-In: I1970eba7e732728699042a36b89571915ec81451 (cherry picked from commit 37131e1ee61dd83121ef02744855ee514f0aa6c5) Change-Id: I1970eba7e732728699042a36b89571915ec81451
| * Merge "Update path to the new ART APEX."Martin Stjernholm2019-09-021-3/+3
| |\ | | | | | | | | | | | | | | | am: 0a4cf715f6 Change-Id: I7ab8cd227ce571041293880dfaca4e2ebb68e536
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-13 01:48:29 +0000