This is not a stable API surface, so modules shouldn't be building
against it. Compiling against core_platform also disables link-checking,
which can hide other problems.
Bug: 137191822
Test: m
Change-Id: I7ce7dad8c02b094c565daf8c178bc6f89bb610ef
* changes:
Migrate SoundTrigger implementation to new service
Implement the soundtrigger_middlewware service
Add a permission for preempting sound trigger sessions
Sound trigger middleware service definition
Add audio.common types AIDL definition
This service is intended to replace:
frameworks/av/include/soundtrigger/ISoundTriggerHwService.h
This change only adds the replacement service, follow up
changes migrate the clients to use the new service and remove
the old one. The new service is feature-equivalent to the new
one, but offers the following advantages:
- AIDL interface (as opposed to hand-written parceling code).
- Pure Java implementation all the way to the HAL.
- Better documentation.
- Rigorous error handling.
- Unit tests.
- Reduced code complexity (less layers, better separation of
concerns).
- Permission-based security model (as opposed to some baked-in
assumptions about process affinity).
Change-Id: I79f4eff105d3e6245990be068b933d4d48c35a0d
Bug: 142070343
These are the AIDL files that define the sound trigger middleware
interface.
This service is intended to replace the existing
frameworks/av/include/soundtrigger/ISoundTriggerHwService.h
using AIDL in order to avoid a large amount of hand-written
parceling code and other forms of boilerplate, and provide
cross-language support.
Change-Id: Ia783ba4f1ea7335a984396e7024cac0411699403
Bug: 142070343
We have decided to reuse the existing annotation @SystemApi for all Java
APIs regardless of whether they are for apps or platform internal
modules. This was because introducing new annotation types every time
when we have to create new API surfaces will only increase the confusion
without giving much benefit.
Instead, to differenciate the different API surfaces of @SystemApi, the
annotation type is parameterized. Specifically, it has to axises.
client: specifies the intended client of the API.
process: specifies the process(es) that the API is available.
The default for client and process are priv-apps and all, respectively,
which corresponds to the today's @SystemApi for privileged apps like
GMS.
Bug: 140202860
Test: m
Change-Id: I3305b71e22970e80db95f3daf3d7713603c7d68d
This is a subset of the types defined in
hardware/interfaces/audio/common/2.0/types.hal.
Specifically, the subset that sound trigger depends on.
These files were auto-generated using the hidl2aidl tool, and
later manually edited to workaround some missing features in
the conversion tool or AIDL (mostly around enum support).
Change-Id: I1c0ffe8a2ebaf09eb4516beaaf4b6fc80985bfc9
Bug: 142070343
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
Change-Id: I09ad88da47540d31ad089aad5e1151a4b6877ec2
When there is no *.aidl file in a filegroup, include path for the aidl
compiler is not set to the path property of the filegroup. This blocks
the plan to cut the dependency from API stubs libs to the framework,
because then we have to rely on the include paths deducted from the
input filegroups, rather than AIDL include paths exported from the
framework.
To make that happen, this change first removes the *-without-aidls
filegroups and replace the reference to them with the corresponding file
groups having AIDLs. Adding the AIDL files for media apex to the API
stubs is fine because the AIDL files are @hidden ones.
Bug: 70046217
Bug: 135922046
Test: m
Change-Id: I794f6d0a7bcbef311d345d6e18ca311800af8ef4
The path property specifies the base directory for Java files. This can
be used by the build system to filter (or filter-out) Java files by
their package names.
Bug: 135922046
Test: m
Change-Id: I6bece92e702b560e53bc087b5960bff577dc3175
(cherry picked from commit 7954524e3cc618830f0bf7b23687bf222ecd285b)
Bug: 134566750
Test: m
Change-Id: I0260942108a13cc5e9bed1d6005abfb8daffe0ac
Exempt-From-Owner-Approval: minor build change
Due to the @UnsupportedAppUsage on
MediaMetadata.getKeyFromMetadataEditorKey, we'd better not to move the
class to APEX. This CL moves the MediaMetadata back to framework.
Also, in order to avoid hidden framework API usages in mainline module,
this CL moves the usage of hidden constructor of MediaMetadata.Builder()
from MediaSessionEngine to MediaSession.
Bug: 123488217
Test: make update-api -j; make -j;
vendor/google/tools/flashall;
atest CtsMediaTestCases:android.media.cts.MediaSessionTest;
atest CtsMediaTestCases:android.media.cts.MediaControllerTest;
Change-Id: I21b4f0f59214478071bb0eafa93bb9538e44bf4e
- media2-abi-* included in updatable-media.jar
- Moves the media2-abi files into media/apex
- Resolves a hidden api usage
Bug: 123209084
Test: build
Change-Id: I9f9b0b9c288da5c7acbfedcb56867ff405ac0d61
"media2.jar" is renamed to "updatable-media.jar" in order to
show its purpose clearly.
Test: build & boot & MediaPlayer2Test
Bug: 112766913
Change-Id: Ia2ea05e0ed1a8bb2cfea20c9e2585e3d3cbfffd9
The only hidden API usuage, c-tor of TimedText, is temporarily commented
out.
Test: make media2
Bug: 112766913
Change-Id: I6330724e65bb42db678f23134677dfd8675a3970
