Create the HotwordDetectionService to help to verify the audio data.
The VoiceInteractor app will implement the HotwordDetectionService
and create the validation algorithm to increase the hotword accuracy.
The HotwordDetectionService will be triggered by VoiceInteractor app
from the VoiceInteractionService after the VoiceInteractionService
is ready.
The VoiceInteractionManagerService will check if we need to bind the
HotwordDetectionService.
After receiving the audio data from the DSP, the
VoiceInteractionManagerService will pass the audio data to the
HotwordDetectionService, then the HotwordDetectionService will verify
the audio data and send the result back.
If the hotword is valid, then the VoiceInteractionManagerService will
inform the VoiceInteractionService. The VoiceInteractor app will show
the UI.
Local test:
1.Make sure the original hotword function to work well manually.
2.Add the additional test code and check the log to make sure the
basic flow of hotword detection service runs well manually.
Bug: 175738546
Test: Manually
Test: atest CtsVoiceInteractionTestCases
Change-Id: Idb662bab37bb9691da24c9c2910a2c3dafedcadd
FontManager is an interface of communicating with FontManaserService.
With this CL, system apps can know the primitive information about
what font files are installed and how it is configured.
This CL also adds shell command of dumping font configuration.
Example usages are:
# dump primitive font configuration.
adb shell dumpsys font
# dump fallback font list
adb shell cmd font dump serif
Bug: 173619554
Test: atest FontManagerTest
Test: Manually confirmed above commands works.
Change-Id: I5cb855308e199ac38bd7b56b60821346247bdce3
These changes have to be in this CL together because:
- Code in service-permission depends on IRoleManager in
framework-permission, so the APIs in framework-permission and the code
in service-permission need to be moved together.
- The changes to service-permission build rules doesn't make sense
without the code moved in, so they have to be together as well.
Other details:
- framework-annotations: Several annotations are added into
framework-annoatations. Since the discussion with API council seems to
allow user IDs in system server in-process APIs, @UserIdInt and
@AppIdInt is added. @MainThread and @AnyThread is added since
@WorkerThread is already added. @CallSuper is added since @CheckResult
is also already added and they are similar in terms of category of
functionality.
- framework-permission-s-shared-srcs: 3 classes (and 2 AIDL files)
from framework is copied as shared source files and jarjared for
framework-permission, and an additional 3 is added for
service-permission as service-permission-shared-srcs. Similar to
framework-wifi and service-wifi, the 3 classes in framework-permission
is also available to service-permission by the stub library
framework-permission-pre-jarjar, and the other 3 classes used only for
service-permission is included separately to minimize our impact on
classes loaded into boot classpath. framework-permission and
service-permission shares the same jarjar rules to make sure the
classes remain available, and for the same reason framework-permission
cannot be shrank during any optimization.
- framework-permission-s-shared: A java_library target for
framework-permission-shared-srcs is created to make sure that the
public classes won't be counted as APIs, as it would be if directly
included as srcs for framework-permission
java_sdk_library. service-permission-shared is the same thing for
service-permission.
- framework-permission-s: A new java_sdk_library target created to be
loaded into bootclasspath by Android S+.
- Dumpsys Protobuf: The dumpsys protobuf
file (rolemanagerservice.proto) is moved into the module, and both the
platform (incident.proto) and the module uses protoc-gen-javastream to
generate the Java classes from it. This should be fine since it's a
"source level inclusion", and we jarjar the generated classes in our
module to avoid conflict with platform copies.
Bug: 158736025
Test: manual
Test: device boots, default apps can be changed successfully.
Change-Id: I1914774f631e51d0c587a7e527a1c9bc05ee1595
* changes:
add API for ST clients run in battery saver mode
add SOUND_TRIGGER_RUN_IN_BATTERY_SAVER permission
add SoundTrigger service modes in battery saver
New system API interface for both SoundTriggerManager and
AlwaysOnHotwordDetector to indicate if a recognition should run in
battery saver mode or not.
Clients supply this information through the existing startRecognition
calls, and the client must hold a new privledged permission,
SOUND_TRIGGER_RUN_IN_BATTERY_SAVER, to indicate this intention.
As a prerequisite, the device PowerManagerService must have the
SoundTrigger service enabled in the battery saver mode battery policy.
If not enabled, recognition will be paused as if the client did not
provide the indication to run in battery saver mode.
Bug: 172294448
Test: build with Google search apk using this feature and verify
recognition keeps running in battery saver mode
Change-Id: Ia43be99290e6fd7c50ff8e4908d6c60ea513b19a
The flow has been replaced by @ChangeId ALLOW_TEST_API_ACCESS, making
old approach obsolete.
Bug: 147113465
Test: presubmit would be sufficient
Change-Id: I9cf8f80abb0165d4aefbf943bade57f5e031904b
Add clearOverrideForTest(changeId, packageName) to remove a single id
from package overrdies.
Bug: 147113465
Test: N/A
Change-Id: I35c6fe418abb9bc562218444878188bc393725e5
PowerStatsService will handle PowerStatsHal queries, PowerStatsInternal
will provide the LocalService for querying PowerStatsHal derived data
from other System services.
Bug: 173077356
Test: atest FrameworksCoreTests:com.android.internal.power.MeasuredEnergyStatsTest
Test: atest com.android.server.powerstats.PowerStatsServiceTest
Change-Id: Ibc0165a44ffdbbcc9328c250f1dca3d29616c766
