Can one "unhide" hidden methods?

19 hours ago 3
ARTICLE AD BOX

Can one overrule this @hide-annotation somehow?

You might be able to get past it via reflection. That will depend on whether or not it is on the restricted list.

creating a local copy might create code that gets out-of-sync with the actual implementation over time

On the flip side, you assume that this undocumented-and-unavailable method exists on all devices, which may not be the case. Device manufacturers routinely change Android's non-public API. How many have messed with this particular method is anyone's guess.

CommonsWare's user avatar

3 Comments

Thanks all for responding. I had assumed/expected that this might be version dependent (which is the reason I wanted NOT to copy it) but I hadn't expected that its availability might even be device and/or manufacturer dependent. So, I guess, I rather stick to emitting the integer value, instead. Thanks again!

2026-05-01T22:17:04.503Z+00:00

same comment to @gabe-sechan (unfortunately one can only respond to a single person...)

2026-05-01T22:17:54.007Z+00:00

2026-05-01T22:18:08.727Z+00:00

No, not in a supported way.
@hide means the method exists inside Android’s framework code, but it is not part of the public SDK. So normal Android apps are not supposed to call it directly.
You might be able to call it using reflection, but I would not recommend that. Hidden APIs are not guaranteed to work on every Android version or every device. They can be changed, removed, or blocked by Android’s hidden API restrictions.
For logging, the better option is to create your own small helper method:

static String audioEncodingToString(int enc) { switch (enc) { case AudioFormat.ENCODING_PCM_16BIT: return "PCM 16-bit"; case AudioFormat.ENCODING_PCM_8BIT: return "PCM 8-bit"; case AudioFormat.ENCODING_PCM_FLOAT: return "PCM float"; default: return "Unknown encoding: " + enc; } }

Then use it like this:
Log.d(TAG, "encoding: " + audioEncodingToString(AUDIO_ENCODING));

So technically, reflection may work in some cases, but the clean and safe solution is to keep your own helper method.

AneequeMalik's user avatar

New contributor

AneequeMalik is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

I really see no point in copy-pasting and recreating this method locally.

There is a point. Given that the method is hidden, it is not part of the public API. It is there now. It is probably there tomorrow. Is it there in 6 months? Is it there in the next android version?

Maybe. Maybe not. Maybe it changed slightly in ways that you aren't expecting, because this method has no spec. It does not explain what it does nor the preconditions you must adhere to when calling it.

Slamdunk case: Copy it. It's better that way.

Where you do get real dilemmas in having a good reason to call hidden API is if it does something that you think you understand and which will likely change in the future and you want automatically go along with the changes, or where it's a native bridge that cannot be copied.

Then this debate gets much more interesting. But for this specific case?

Copy it. It's the obvious solution. Future you will thank today's you.

rzwitserloot's user avatar

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.

Read Entire Article