According to Behdad this issue was fixed in HarfBuzz 2.0.0, October
2018.
Change-Id: I6e23ae7d637f79cb55b99a73ac8d16a0b0395610
Bug: 158944323
Test: drew a ZWJ in RTL and it worked fine
(https://screenshot.googleplex.com/AHrRaKNR6S4Nwgb.png)
Change-Id: I29e64f4577c819dfec0f3cbd878f0241bf706de0
java_library now supports using the "stream" type for proto properties,
so we can use this type here to remove workaround.
Bug: 215230097
Test: m StreamingProtoTest
Change-Id: I365457c5392ef3e0ede39d9d36d0aa1f2951c902
This linter ensures that any class (or method) that extends (or
overrides) another one annotated with @EnforcePermission, is also
annotated with the exact same annotation. The intent is to surface the
permissions verified at lower-level to the service implementation.
Test: atest --host com.google.android.lint.EnforcePermissionDetectorTest
Bug: 197828948
Change-Id: I042b7e5d99bae05681869f13702d1c169b8bdb05
git branch -vv can be incredibly slow (over 5s on my machine/repo), so
when aosp_sha.sh is called multiple times per commit, the repo upload
hook can take a very long time to run (>2 mins for my stack of changes).
The only output used from git branch -vv was the upstream of the current
branch, which can be determined in a much faster/simpler way via
printing the ref name of @{u} (git lingo for the upstream HEAD).
Test: $ { aosp_sha.sh HEAD && echo ok || echo no } in aosp and internal
Change-Id: I993496d8ec9e55c13803590bbb6c5d9d49cde158
Avoid writing test files in the build output directory which fails when
run with Bazel. This happens because Bazel's sandboxing environment
ensures that the test's working directory is unwritable.
See https://docs.bazel.build/versions/main/sandboxing.html for more
information.
Bug: 209687942
Test: atest --bazel-mode aapt2_tests
Test: atest aapt2_tests
Change-Id: I0fce701bbac255c3e308ad5c85aa27230c3b620b
This change introduces a new <apex-system-service> tag to the manifest.
A manifest may have multiple <apex-system-service> tags, with each tag
denoting one system service that lives in an apex. If the service is
not in SYSTEMSERVERCLASSPATH, the android:path attribute may be used to
indicate where the jar is located on the filesystem. The minSdkVersion
and maxSdkVersion attributes may be used to indicate which SDKs the
service should start on.
Test: atest PackageParserTest
Bug: 192880996
Change-Id: I28e595b397ed8db6c412f490f12c73537972efab
This reverts commit a22b7e05d4.
Reason for revert: This is a roll forwards with the fix applied.
Fixes: 208710019
Change-Id: Id4e9029ebe5864ddcc5583ce525e8e70da79f82c
This reverts commit 8d0ec8faa8.
Reason for revert: DroidMonitor: Potential culprit for Bug 208710019 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted
Change-Id: Ic1ff41e7648afc0fa50081de9b7d538a49c6468a
Design: go/sdk-android
Basic boilerplate code, only adding a concept of SDK library to the OS.
Additional public APIs and more custom processing are to follow.
Tests are added in ag/16348319.
Can't submit together because of the checked build error: AndroidManifest.xml:32: Error: Misspelled tag <sdk-library>: Did you mean <uses-library> ? [ManifestTypo]
Apparently it needs updated aapt2 before it can process the new manifest even though the aapt2 is part of this change.
Bug: 207413168
Test: atest AndroidPackageTest ScanTests PackageManagerSettingsTests PackageManagerComponentLabelIconOverrideTest PackageManagerShellCommandTest
Change-Id: I9ea77ba3a0550ef7d58778a3a6cb402f09e2d8d7
