This will allow javadoc links to androidx packages to resolve.
Test: No behavior changes
Bug: 144042891
Change-Id: I01c1cd637f46c666c28669c1796a1d5a0d249c24
This reverts commit 159799d7c971777231d17c0aabd60d36044ab331.
Reason for revert: b/70221552 is fixed
Change-Id: Iaae0df6736a3141847376b9ab0115f1c7a31fdb1
Metalava no longer requires it at least for droidstubs in this
directory. Even when local_sourcepath is not set, the -sourcepath option
is set to the module directory (frameworks/base in this case), and
metalava tries to find package.html files under the directory to know if
a package is hidden or not.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 144264106
Test: m
Merged-In: Idfa2aa392ae1da9582e7691a8c06c986baad5088
(cherry picked from commit e53786e864fd3f3097603ef9dfcfcb6b604ee7b1)
Change-Id: Idfa2aa392ae1da9582e7691a8c06c986baad5088
The api_dir property is removed, and the api dir path for aidl_interface
is fixed to aidl_api/{module_name}.
Bug: 113134692
Test: m -j
Change-Id: I0fdc074579647be0e5f5b025a909c3c0c41194c9
This creates a java API for registering pullers. Will implement the
statsd side in a follow up CL.
Test: builds, boots
Change-Id: Ib6735984297ce3148839a6370a3c15b2a585baf5
The purpose of the java lib framework-annotation-proc is to run some
annotation processesors on source files in framework-all-sources.
However, running an annotation processor requires the compilation
of the entire source files; in fact, the output of the annotation
processors are created as byproduct of the compilation. This is a
duplicated compliation because we already are compiling the source files
for the framework-all java lib. To reduce the duplication, replacing
the references to framework-annotation-proc with framework-all, and
removing framework-annotation-proc.
Test: m
Change-Id: I449488cba235211374e2825df97aae84395e60b6
Metalava no longer requires it at least for droidstubs in this
directory. Even when local_sourcepath is not set, the -sourcepath option
is set to the module directory (frameworks/base in this case), and
metalava tries to find package.html files under the directory to know if
a package is hidden or not.
Bug: 144264106
Test: m
Change-Id: Idfa2aa392ae1da9582e7691a8c06c986baad5088
Test: m offline-sdk-docs
diffed against previous version to ensure this did not change it
Bug: 129765390
Change-Id: I28b5b76744b096c56959ef3b0a6f31fe163b5e4d
The annotations are already merged into the stubs that are exported
from libcore so this is unnecessary.
Bug: 142113521
Test: m checkbuild
test this change does not change offline-sdk-docs
Change-Id: Icb0b61f80c91f96eaa22a7f1b92ffdf1825636c8
This change adds a bare-bones system service, implementation will follow
later.
Bug: 143559646
Test: atest cts/tests/BlobStore/src/com/android/cts/blob/BlobStoreManagerTest.java
Change-Id: Idf21dfcd11dd32a42b62c6ad965d6f5ad7eed1b4
Please review the fundamental AIDL interfaces for enabling
the Incremenetal feature. Basically there are three services:
+ android.os.incremental.IIncrementalService:
Provides basic file operation functions. Will be implemented in native.
+ android.os.incremental.IIncrementalServiceProxy:
Started by SystemServer, is it the proxy that starts native
Incremental Service. The proxy also handles Java tasks like finding
data loader service package, binding to data loader service and talking
to it. Essentially the native Incremental Service controls the
data loader service via this proxy. Will be implemented in Java.
+ android.service.incremental.IIncrementalDataLoaderService:
Defines inteface for the base data loader service. I understand that
data loader is being re-designed but I would like to get the
"placeholder" in master first, and we can iterate on the implementation
details in master.
Test: builds
Change-Id: Ifc3a43633356951b239486d66ee80d120bc4ab76
The com.android.okhttp and com.android.org.conscrypt packages are no
longer present in the input source so do not need hiding.
Bug: 142113521
Test: m checkbuild
Change-Id: I303b054ec114450b5fce3482eddf3cc3749d3814
It is okay to use callback interfaces because with Java 8 default interface
methods avoid the extensibility issue interfaces had previously.
Test: make checkapi
Change-Id: I7c931af638b83b4242f03dde9bc460b0981f66cd
There is an overlap between the source code provided by the
metalava-api-stubs-default and that provided by the
non_openjdk_java_files and openjdk_java_files filegroups. That causes
problems when switching the API generation from libcore implementation
code to libcore stubs code.
Removing the libcore implementation sources will remove any mappings
from class/member signatures to source location for any files from
libcore but that should not be a problem as that was only used for
batch addition of UnsupportedAppUsage annotations and that has alreadu
been done.
Bug: 143864733
Test: m hiddenapi-mappings && m checkbuild
Change-Id: Id47dcb8fc497c9bafa6f501cb2debb835a5f6942
And move mms util code to the new folder.
Test: basic sanity
Bug: 140763963
Merged-in: I0d92ed3fca1fc186484ea8d3c5d17b6e332e7d22
Change-Id: I0d92ed3fca1fc186484ea8d3c5d17b6e332e7d22
(cherry picked from commit d355153dcbc125b80113c31dafc80afe1a5fddd6)
