We can't expose APIs if the enclosing class is hidden, so these
annotations are redundant. We need to remove them so that we can enable the
check.
Exempt-From-Owner-Approval: Cherry-pick from goog/master
Bug: 159121253
Test: treehugger (i.e. this shouldn't trigger "API has changed" error.)
Merged-in: Ie1841a670bdf6c6f4b25a1fc5deed8ec2d18cda2
Change-Id: I36e3562b72e64b51e4febd1d42a3bc8e4dc60988
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
These were exposed for telephony mainline. Will be revisited in S.
Test: basic sanity
Bug: 148171847
Bug: 148171388
Merged-in: Ibdcac557cf35e723f09a7b7a2e59c7deae1fc94e
Change-Id: Ibdcac557cf35e723f09a7b7a2e59c7deae1fc94e
(cherry picked from commit c55b01552e)
Hide Context.NETWORK_POLICY_SERVICE as it has no usage.
Bug: 151266974
Test: make checkapi, build
Copy from ag/10796415
Change-Id: I0586a5ef22f76fa1407219b96cb246f162f02947
Merged-In: I0586a5ef22f76fa1407219b96cb246f162f02947
Users of the API receive a TetheringManager from getSystemService; they
do not call ServiceManager.getService.
Bug: 151243982
Test: m
(clean cherry-pick from internal branch)
Merged-In: If75f590da17f07ea9d65635065689d8f4e17b40f
Change-Id: I129ffa7abae1218bcf88ccb8ba074ec8ad50119b
Instead, have a dedicated method in android.net.NetworkStack allowing to
fetch the stable AIDL token for the service.
This avoids returning IBinder from getSystemService, as getSystemService
should generally return manager classes.
Test: atest FrameworksNetTests NetworkStackTests
Fixes: 151243982
Merged-In: I58a6e1f27aff052050197d1901f43a98d7aa1167
(clean cherry-pick from internal branch)
Change-Id: I75aba269595f3e315dd5e0693c878b2026e8e299
This reverts commit ffe0cbe5ca.
Reason for revert: Not needed for now; will be redone in S.
Bug: 148180958
Change-Id: I426e00e1eb79af5b520fc8c59439614459720fa6
with appOp as String and options as Bundle
Bug: 139077993
Bug: 146423958
Test: Build
Change-Id: I5325e08d60016741139251813a5df9b42f2efc82
Merged-In: I5325e08d60016741139251813a5df9b42f2efc82
This extra is not exposed and is not used by anyone as such.
Leaving it there for internal use/unsupported app usage.
Test: basic sanity
Bug: 140908357
Merged-in: I9fe6e904291affb1cd7b705212d47525b61a5679
Change-Id: I9fe6e904291affb1cd7b705212d47525b61a5679
(cherry picked from commit bb61b17cd9)
Original commit:
[DexLoadReporter] Report classloader contexts directly from classloader
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Exempt-From-Owner-Approval: This is a pure re-revert, previously owner approved.
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I8d1af791f93a3f8fa6eca78df50891cd2ebbb4a3
This change adds a feature flag that specifies the date associated
with the Vulkan dEQP tests that a device claims to pass.
Bug: 136573508
Change-Id: I0cec29fe5f69f228faaa2298b7f5b65bcf988dba
Merged-In: I0cec29fe5f69f228faaa2298b7f5b65bcf988dba
