Hidden APIs and its (barred) usage

[Ajai Jose]

hi,

   I am not an app developer but an android systems programmer.

I have seen some developers in my company use certain hidden APIs (APIs with annotation @hide) by removing the "@hide" tag.

 I know APIs are hidden for a reason. they maybe refactored/dropped in subsequent versions. my review comment is "-1" to be inline with the hidden API semantics.

however 

Developers say if our implementation targets a particular old release where google has stopped development it is pretty much known that this API  under question has not changed in semantics.

In the absence of certain crucial functionality requested by a customer the developer would tend to go for using these APIs albeit in an incorrect way by removing the at hide tag.

the API ofcourse will now be available as public API for this custom built SDK.what is the stand of the framework team vis-a-vis this kind of usage.

Not every small company has access to google to talk and get support for an API that they need.

we in our small organization don;t wish to be bad android citizens. so looking for a positive outcome here.

Also would it even work ? as these APIs are then deemed public API however subsequent Android deliveries will break the change so is a continous effort.

will the build system have some quirks ?

will make update-api be sufficient or updating the system api text file be needed.

I have read through other posts already on this topic and they address the APIs buckets from google but dont adress such (contrived :-)  ) usage.

thanks

-Aj

[Cengiz]

An alternative way is utilizing reflection in Java. The classes marked as "hidden" are loaded in runtime anyway, as some system module uses them. What you need to do is just get class/method of interest and make invocations. This way, you do not need to change framework code. However, please note that with this method, you are basically pushing error checking to runtime from compile time.

[Colin Cross]

If you are talking about an app that is shipped with a specific version of the platform then it is fine to use APIs that are @hide in that platform.  Using @hide APIs in an app that for example targets Jellybean, on the assumption that Jellybean isn't changing any more, is a bad idea.  @hide APIs do not have any CTS testing, so there is no guarantee that they exist or have the same behavior on devices shipped by different OEMs.

In old releases there is no difference between hidden and visible APIs at runtime, only whether or not they were found in the SDK android.jar to compile against.  After https://developer.android.com/about/versions/pie/restrictions-non-sdk-interfaces, @hide APIs may not be usable at all at runtime for non-platform apps.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.