droiddoc modules for the SDK API documentation and stubs library
generations have depended on the 'framework' (which was recently changed
to framework-minus-apex' module to get the list of Java source files to
be processed.
This however caused a circular dependency when we tried to modularize
some classes in the framework library as a separate library. The
separate java library depended on the stubs library (because it should
only use SDK APIs) and the stubs library depended on the framework
library. The framework library itself depended on the separated library
(or its stub) to use APIs from the separated library, thus forming a
circular dependency.
This change fixes the problem by directly giving the framework source
files via a filegroup `framework-sources-to-document` where all Java
and AIDL files that are to be documented are included in.
This change also put the generated R.java and Manifest.java files from
framework-res into the filegroup for framework sources.
Bug: 70046217
Bug: 135922046
Test: m
Exempt-From-Owner-Approval: Approved internally
Merged-In: I09ad88da47540d31ad089aad5e1151a4b6877ec2
(cherry picked from commit 20426538f8)
Change-Id: I09ad88da47540d31ad089aad5e1151a4b6877ec2
Remove logic to set heap target utilization to 0.8. The default is
0.75 and this should not have any fragmentation benefit since the
GC is compacting.
Removed some unused logging and a variable.
Test: TH
Change-Id: Ife7219e94fa0aa7f489569e16248cdd23d09089a
This reverts commit 098a533e78.
Reason for revert: Base CL caused slower app startup (I don't know why).
Change-Id: Ib67852b900ff2baeb34f5d553fb0d233f5475888
To com.android.internal.compat.IPlatformCompat. This solves a java9
issue because libcore exported api has the same package android.compat.
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make framework
Change-Id: I0918344f670669cecb04f1e9e54dbcb471b587d5
This CL topic moves the default MimeMap implementation to frameworks.
Libcore starts with a minimal implementation sufficient to pass
CtsLibcoreTestCases, but frameworks can inject the real implementation.
Before this CL topic, the data files and logic (MimeMapImpl) were part of
core-*.jar on device; after this CL, they instead live in framework.jar.
Tests from MimeMapTest that check behavior of that default
implementation also move to a non-libcore CTS test.
Specifically, the logic and android.mime.types now live in
frameworks/base/mime. The default implementation is injected
into libcore from RuntimeInit. I chose to use a separate directory
(frameworks/base/mime/) and build java_library target ("mimemap")
in order to keep this as separate as possible from the rest of
frameworks code, to make it as easy as possible to factor this
out into a separate APEX module if we ever choose to do so.
Planned work for follow-up CL:
1. Make CTS more opinionated, with a plan to assert that all of
the default mappings are present. How exactly the expectated
mapping will be bundled in CTS is still TBD.
2. Add a vendor.mime.types file (defaults to empty) where vendors
can add additional mappings; I plan to make it such that mappings
in that file are parsed last but never override any earlier
mappings, as if each mime type / file extension was prefixed
with '?'.
3. Perhaps enforce that public APIs android.webkit.MimeTypeMap
and java.net.URLConnection.getFileNameMap() behave consistently
with MimeMap.getDefault().
Test: atest CtsLibcoreTestCases
Test: atest CtsMimeMapTestCases
Bug: 136256059
Change-Id: Ib955699694d24a25c33ef2445443afb7c35ed9e7
This combines ag/8888937 and ag/9019277 into one CL, plus fixes another issue
where the timer could restart if the user had removed a notification and then
restarted the stream
Fixes: 138261464
Test: manual, atest NotificationMediaTemplateViewWrapperTest
Also checked the changes on the master branch since that had very
obvious issues when locking / unlocking the phone before
Change-Id: I6a0bbc675d33a5c7d4ce7f0884aec19606bff4fa
