Follow up to ag/18795008. Lazy Bundles, (aosp/1787847), introduced a change in behavior where a Parcel created as part of initializing a Bundle is dependent on the next ART GCrun to be recycled, causing a short term memory-leak. We previously force recycled the parcel when bundle.clear() was called. This commit takes it a step further and adds reference counting for the number of lazy values in mMap. When this reaches 0, we can safely eager recycle the underlying parcel. This still does not work when parcel references have been shared outside the owning bundle (i.e, when mOwnsLazyValues is false.) We have two options here: 1. Allow the GC to eventually claim the parcel (current behaviour). 2. Track lazy values refs globally across bundles. High complexity cost, and likely high performance impact. We can not unmwrap the lazy values before copying, in case the originating classloader can not instantiate the given class type. See go/lazy-bundle In initializeFromParcelLocked(), renamed boolean parameter recycleParcel to ownsParcel since the method no longer recycles in all cases. Also, only create lazy values if ownsParcel = true so that we don't have lazy values referencing the passed in parcel in case the caller doesn't own the parcel (which means the parcel could be recycled out of our control). Bug: 233216232 Test: Reproduced linked bug on-device Test: atest android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest android.os.BundleRecylingTest Change-Id: I8a878a6d0055b04b2611909b4b17977ba5677a4f
* Copyright (C) 2019 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. INTRODUCTION The Android platform core tests that require additional mocking capabilities and use Extended Mockito, such as the ability to stub static methods. ExtendedMockito is not fully compatible with regular Mockito library, so tests that use it have to be verified and adapted. For that reason a separate module is used instead of adding to FrameworksCoreTests. For more information about ExtendedMockito see documentation of com.android.dx.mockito.inline.extended.ExtendedMockito class. See ../coretests/README for more information on FrameworksCoreTests. INSTRUCTIONS To build, install and run: atest FrameworksMockingCoreTests