IssueTracker

Device used?

Any Android device since Android 6, where the now missing class file was first introduced, but that's irrelevant since it doesn't even compile.

How frequently does this issue occur?

100% of the time when compiling with compileSdkVersion 31

What steps are needed to reproduce this issue?

Try to compile with compileSdkVersion 31 the example already given, i.e. an MyVoiceInteractionService.java file containing:

import android.service.voice.AlwaysOnHotwordDetector;
import android.service.voice.VoiceInteractionService;

public class MyVoiceInteractionService extends VoiceInteractionService {
  private AlwaysOnHotwordDetector hotwordDetector;
}

What is the expected output?

A successfully compiled class

What is the current output?

Compilation failure, since the android.service.voice.AlwaysOnHotwordDetector class is no longer available, it's been removed by an @SystemApi.

The bug is even documented here:

https://source.android.com/setup/start/android-12-release#alwaysonhotworddetector

I can say that I used this in my app to activate it whenever the user said "Ok Google" instead of activating Google Assistant. This allowed me to provide a customized voice driven assistant in my own app.

It was fully usable at one point and my app worked on a normal non-rooted device and the app wasn't a system app.

Check out this video example (at this specific time): https://youtu.be/Dmm8TKS4G-I?t=134

Your assumption is wrong. My app has been using it successfully since Android 6, where it was first introduced, if it didn't i wouldn't use it. It may not work on Android 10+, but now i'm forced to remove the feature altogether, even for users for which it still work, just because i can no longer compile my code. This is not the first time public APIs have disappeared by inconsiderate use of @removed or @SystemApi:

• https://issuetracker.google.com/issues/128553845
• https://issuetracker.google.com/issues/64992660

Please, just replace the @SystemApi with @Deprecated so we can compile, as you say, we wont be able to use it on Android 12 anyway since it will fail permission checks. The developers on the Android team seems to lack knowledge of what the @removed or @SystemApi annotations actually does, they break existing code by excluding the APIs from the SDK (android.jar), severely worsening the Android "fragmentation" issue.

It was a security bug that this API was usable by non-system apps: CVE-2022-20446

I agree that it still should have been @Deprecated instead, but unfortunately once the API was finalized -- before this bug was filed, it became too late to fix that.

Sure, it was a security bug that this API was usable by non-system apps, but this issue is about the class being missing completely.

This means that currently it is not possible to build an app that uses it even though the app will eventually run as a system app.

This is nonsense, changing the @SystemApi annotation to @Deprecated is not unfeasible. The API doesn't have be functional on Android 12, it just has to be present so existing code still compile and work on older Android versions.

Luckily it's easy to work around anyway, by compiling an VoiceInteractionService "compatibility" project using compileSdkVersion 30. So this is just another unnecessary fragmentation of the Android API, and glaring evidence of how poorly managed it is.

If your app is running as a system app you can compile against the system sdk.

The API for Android 12 cannot be changed now (and couldn't have been even when this bug was filed), that's why this is infeasible.

Working around the compilation issue isn't going to help anyway since the API will no longer work when devices pick up the security patch, even on older Android versions since the security patch was backported. Code using this API should be deleted instead of finding a way to exploit a security bug.

I don't have context for why the API was changed in this way in Android 12, but now this can't be fixed.

If your app is running as a system app you can compile against the system sdk.

How can I set that up in Android Studio?

No, my app is not running as a system apps, that was never a requirement. There's no security exploitation here since the feature and API was public for years and used as designed/documented. Google may have found it had a security issue, but instead of fixing that the whole API was removed, that's usually not how bugs are fixed. As said, i have no problem with a feature stops working, but a public API should remain compatible. Google repeatedly proves it has no respect for backward compatibility, but it can't rewrite history.

Looking at the latest source for the AlwaysOnHotwordDetector its public surface seems to have remained the same, but i guess you can't revert your mistakes due to "non-SDK restrictions" preventing it. Sigh, even that's causing more fragmentation than it's supposed to resolve.