EncodedBuffer is used a lot in incidentd. EncodedBuffer uses malloc
internally to acquire memory. Frequently creating and destroying
EncodedBuffer creates memory fragmentation, leading to high memory
usage after taking an incident report.
Also fixes a few other places with lots of malloc/free operations.
This change:
* Creates a pool of EncodedBuffer in incidentd. The saving is
significant. It reduces EncodedBuffer creation from 3 per section to
3 per report.
* Replaces malloc with mmap inside EncodedBuffer. mmap is guaranteed
to be mem page aligned, so there will be no mem fragmentation after
destroying EncodedBuffer.
* Replaces new with mmap inside TombstoneSection
* Forks a process to execute LogSection, because liblog malloc & free
significant amount of memory
Result:
PSS before taking a report: 1295 KB
PSS after taking a report: 1336 KB
Bug: 150311553
Test: heapprofd
Change-Id: I83bd9c969b751c80b2f42747020799bd85d8aae6
Before overlays could reference internal resources, overlays were
added to AssetManagers before shared libraries. Overlays are now
loaded as shared libraries so they must be assigned package ids
after non-overlay shared libraries so enabling and disabling
overlays does not affect the package ids of the non-overlay shared
libraries.
Since overlays are added to the end of the AssetManager by
ResourcesManager, enabling and disabling overlays will not change
the assets cookie of shared libraries loaded through ResourcesManager,
but it will change the apk assets cookie or overlays added through
AssetManager#addAssetPathAsSharedLibrary.
The package ids of shared libraries added through
AssetManager#addAssetPathAsSharedLibrary will not be affected by
overlays since overlay package ids are assigned last.
Bug: 146685730
Test: CtsHostsideWebViewTests
Change-Id: If7ea17d51b18769bf2465e29af3ae6a71004d06c
This change must be reverted because it broke packages with the same
package name but different package ids loaded at once.
Bug: 146685730
Test: MultiSplitInstallTest
This reverts commit fe50d739f7.
Change-Id: If6364fd660c76284452f77e7d4f09a3df9dede1d
The API is simple enough, so just reimplement everything using the
C API directly.
Bug: 148940365
Test: treehugger
Change-Id: I0a75744e975e8d3c2a557e533eacd03200388ddc
Update statsd to take in times in milliseconds instead of nanoseconds.
Also make appropriate updates for graphics stats, odpm, subsystem sleep
state, and LibStatsPullTests
Test: atest LibStatsPullTests
Test: bit statsd_test:*
Bug: 150788562
Change-Id: I593552d6c50bb4dcb89ca9cc1c737781653e7cc5
Currently there is a limitation where ResourcesLoaders cannot be used
on Resources object not created through ResourcesManager. This change
creates an update handler for Resources objects that are not registered
with ResourcesManager.
The handler changes the loaders on the asset manager owned by the
Resources instance.
Bug: 151666644
Test: atest ResourceLoaderValuesTest
Change-Id: I5a89f686386bdb088dc964014e7becc0c2b4770f
Querying in the native layer for assets provided through
AssetsProviders does not currently work. This change refactors the
AssetProvider API to return a file descriptor that is read in the
native layer and can bubble up to the java layer.
This change also removes the InputStream API to favor of developers
using memfd_create.
Bug: 142716192
Test: atest ResourceLoaderValuesTest
Change-Id: I1a7eca0994c3b7cc32008d9a72bf91086ff0e816
This API allows a directory to be loaded as if it was a zipped APK.
This is a substitute for the DirectoryAssetProvider API that
currently does not work in the native layer.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: Ia13e15653e75b421423dd56f9fe89e183ab4cb9a
To add the partner requested ResourcesProvider#loadFromDir APIs, this
change adds format type integer that allows us to reduce the number of
ApkAssets loading overrides.
This change also adds hidden offset and length based ResourcesProvider
APIs that could not make R.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: I926fde257cae701901dcd4ca408024feae8c90a6
Merged-In: I926fde257cae701901dcd4ca408024feae8c90a6
The check used in Readback.cpp did not take the transformation
matrix into account for judging whether the copy was scaling.
libs/hwui/pipeline/skia/LayerDrawable.cpp already incorporates
the logic to detect non-scaling copy, so we can just let it
check the condition. This version regards 90-degree rotation
without size change as non-scaling and disables filters.
Bug: 151126720
Bug: 150839078
Test: atest android.view.cts.PixelCopyTest
Change-Id: I69e987e6a2e48299c5e579f8c218c42a724dc606
This provides an example implementation of the Sidecar interface
for the Window support library, which allows mocking a foldable
device by reading its current configuration from settings.
This implementation also makes sure that the reported display
features are adjusted to the window position and coordinate space,
as required by the Sidecar interface contract.
The reported values can be updated by using the following shell
commands:
settings put global device_posture <posture>
settings put global display_features <type>-[<sX>,<sY>,<eX>,<eY>]
Bug: 146188055
Test: Manual, see instructions doc
Change-Id: I4764298d7633bc3ef574b5cbc2dee256e9cf3f03
(cherry picked from commit d66f77b0b7)
Revert "libui: rewrite Region with FatVector"
Revert submission 10248126-fatvector-region
Reason for revert: b/149254345
Reverted Changes:
I09dc2fddd:hwui: remove FatVector
I265c6c831:libui: rewrite Region with FatVector
also fix wrong license in FatVector.h
Test: boots
Bug: 149254345
Change-Id: I8ac66acb8b635324051edd41c5d4092c223157ff
There are cases where an app can ship overlays for itself,
but the "signature" policy as described would open up
a vulnerability by allowing the system actor to create
and sign any arbitrary overlay that will apply to the target.
To prevent this, redefine "signature" as target package only,
and introduce "actor" for checking against the actor signature.
Any app that wishes to use both can include both policies.
Bug: 130563563
Test: m aapt2_tests idmapt2_tests and run from host test output
Test: atest libandroidfw_tests
Change-Id: I1c583a5b37f4abbeb18fc6a35c502377d8977a41
To make it easier to add the actor policy in a follow up CL,
move most of the policy handling to a central location.
The strings and transformation between strings and flags is
now handled in libidmap2policies, with libandroidfw
containing the single source of policy flags.
This also extracts all the test resource IDs into an R.h
so they can be swapped without having to edit a dozen files
each time.
Bug: 130563563
Test: m aapt2_tests idmapt2_tests and run from host test output
Test: atest libandroidfw_tests
Change-Id: Ie533c9cebf938215df7586f00c38763ae467e606
* changes:
Export symbols for the newly exposed APEX/internal headers
Remove dependence on libandroid_runtime from Bitmap.cpp
Update Region.cpp to use AParcel NDK APIs
Cleanup header and build targets for libhwui clients.
Remove dependencies on headers outside UI module
Cleanup LOG_TAG when bundled in HWUI
Move android.graphics JNI & APEX files into HWUI
The end goal is to have Bitmap.cpp use AParcel, but until that
API is extended to support this use case this is an alternative
way to isolate the graphics files from the libandroid_runtime.
Test: CtsGraphicsTestCases
Bug: 145227478
Change-Id: Ie3854fe03dec4f7b1b485295bb9a5ebba52ddb7c
Targets that will also be contained within the UI module
are allowed to access internal headers. All other targets
that depend on libhwui are restricted to using the APEX headers.
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: Id92e9874dafb98bd79839d45ab8f22ab999689de
Bug: 143470518
Test: android.graphics.cts.ImageDecoderTest#testConserveMemoryPlusHardware
Follow up to ag/10045682, which was resolving a merge conflict. The
original fix (https://android-review.googlesource.com/1203783) was
on the single Bitmap constructor which took a GraphicBuffer parameter.
The conflict was with ag/9130111, which switched the input to an
AHardwareBuffer and split this version of Bitmap::createFrom into two
methods. The constructor no longer has access to the information
regarding the buffer stride, so that got moved into Bitmap::createFrom.
But both versions should have the fix. (In fact, it appears that the
version that did *not* have the fix is the one being called in
testConserveMemoryPlusHardware.)
Move the rowBytes computation into a common method so that both will
have the fix.
Change-Id: I16f77528abdb331af556bbe5d0485fe342f2325e
The graphics JNI code is now separate from libandroid_runtime
and it along with HWUI headers are no longer visible to targets
outside the boundary of what is to become the UI mainline module
The exposed headers to targets outside the module are now restriced
to C APIs contained in the apex header directory.
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: I30d34055b6870dc1039f190a88f4a747cee17300
I was looking for documentation of what these mean, but discovered
that these attributes have been obsolete for years.
Test: m
Change-Id: Ifcf47e99d22b1546780968d1030f835173612a27
Follow ProtoBestPractices and comments suggested by cl/295218381.
Changing proto definition, should be fine, because these are
fields added after the last Android release.
Move PipelineType enum inside GraphicsStats and add a default
UNKNOWN state.
Rename start_millis and end_millis in GraphicsStats atom.
Fields in GraphicsStatsProto cannot be renamed as these were
part of previous Android releases.
Test: Ran "adb shell cmd stats pull-source 10068"
Test: Ran "statsd_testdrive 10068" and it looks OK
Bug: 149646555
Change-Id: Idc326eb2a7eb9ff0be39026e6fec544491b7d8a6
ANativeWindow usage now has enough feature parity so that we can use
that instead.
Bug: 137012798
Test: builds
Test: Scroll through settings
Change-Id: I0054315058b28bcb5e779a6f71a3cfb164625a5f
