When we set the buffer size from relayout window, there is a race
condition where the client may then submit its first buffer but the
transaction hasnt applied yet on the SF side and so the buffer is
rejected. Setting a defualt size when creating fixes this. Luckily
SurfaceControlViewHost size is known at add time, since we force the
window size based on the values passed in to the SurfaceControlViewHost API.
Bug: 157153874
Test: Existing tests pass
Change-Id: I2566844aea81df92f1694f43254a480fc3b3c019
Add checks during boot in case the persist.sys.timezone property is set
to a bad ID.
This can happen in the rare case of a mainline rollback: i.e. if a device has
been set to a new ID and then the update is rolled back. Using GMT as a
fallback probably works without this change (it does in java.util.TimeZone),
but relies on all code, including native code that uses
persist.sys.timezone directly, knowing to interpret a bad ID as "GMT".
This commit makes that choice more explicit and defensive.
This change also removes the possibility of IOException, which is never
thrown, from some ZoneInfoDb methods.
Bug: 155738410
Test: boot with a valid id, verify persist.sys.timezone is unchanged
Test: boot with an invalid id set, verify persist.sys.timezone is "GMT"
Merged-In: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd
Change-Id: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd
Exempt-From-Owner-Approval: Approved / landed internally
UidAtomTests:testAppOps is a test class and test method of
CtsStatsdHostTestCases. To run this in Test Mapping, it should
specify CtsStatsdHostTestCases. as the name in TEST_MAPPING file,
and android.cts.statsd.atom.UidAtomTests as the options.
Bug: 155714228
Test: presubmit test.
Change-Id: I7df08ae811425020ebbeae6a8e9f1317065c00c9
Currently when a package is installed / updated in a sharedUid the
signatures for the sharedUid are not updated unless the new package
adds a new signer to the lineage; in this case the new lineage is
assigned to the sharedUid without consideration for the existing
lineage. This leads to the following problems:
1. If the current sharedUid lineage is A -> B and the new package has
lineage B -> C then this is used for the sharedUid and A is lost from
the lineage.
2. If the new lineage revokes one or more capabilities from a previous
signer in the lineage these updated capabilities are ignored unless the
lineage added a new signer as well.
3. If the new lineage revokes the sharedUid capability from a previous
signing key in the lineage and another app is installed as part of the
sharedUid and signed with that key the new app's installation is allowed
to proceed.
4. If only a single app is installed as part of a sharedUid, and that
app is updated with a rotated key and a lineage that revokes the
previous signing key's sharedUid capability the update is blocked.
5. If an app is installed as part of the sharedUid and has a diverged
signer in the lineage (ie sharedUid lineage is Y -> A -> B and new app
lineage is Z -> A -> B -> C) the installation is allowed and Y is lost
from the lineage.
Problems 1 and 2 are addressed with the new SigningDetails
mergeLineageWith method that merges common signers between two lineages
and also updates their capabilities to the most restrictive between
the two lineages (capabilities are anded together). Problems 3 is
addressed by checking the signatures of each of the packages in the
sharedUid for any signed with an ancestor for which the sharedUid
capability may have been revoked. Problem 4 is addressed by checking
if the package being updated is the only one in the sharedUid; if so
the update to the new lineage is allowed to proceed. Problem 5 is
addressed by verifying the new app's lineage is the same, a subset, or
a superset of the other.
Bug: 152046935
Test: atest PkgInstallSignatureVerificationTest
Test: atest SigningDetailsTest
Test: atest PackageManagerTests
Test: atest PackageManagerTest
Change-Id: I420c309f522bb47b65ca40ee848024c85cd5804d
