CODEWITHSUNDEEP
androidannotationsandroidx
BamsBamx
BamsBamx

Reputation: 4256

Is it safe to use @SuppressLint("RestrictedApi") with AndroidX libraries?

I would like to now whether it is safe or not to use @SuppressLint("RestrictedApi") annotation. I am pretty sure that the answer is NO, so I want to ask why as well.

I guess that the development team wanted to hide such restricted code from the API users. Probably due to changes in the future or because the code is intended to work as internal functionality

Example code with androidx.preference:preference:1.1.1:

public abstract class CustomAdapterPreferenceFragment extends PreferenceFragmentCompat {

    @Override
    protected PreferenceGroupAdapter onCreateAdapter(PreferenceScreen preferenceScreen) {
        // this annotation removes warning that says PreferenceGroupAdapter can only be called from package names that start with androidx.preference        
        @SuppressLint("RestrictedApi")
        final PreferenceGroupAdapter adapter = new PreferenceGroupAdapter(preferenceScreen) {
            @Override
            public void onBindViewHolder(PreferenceViewHolder holder, int position) {
                super.onBindViewHolder(holder, position);
            }
        };
        return adapter;
    }

Link to annotation that restricts code usage in this example: AOSP AndroidX

Upvotes: 6

Views: 5896

Answers (1)

Ryan M
Ryan M

Reputation: 20157

You're correct: this is not safe. Symbols marked with @RestrictTo are not considered public API, and may change behavior or signature arbitrarily between releases. The only guarantee is that they won't break behavior that other AndroidX libraries rely on internally, and what that behavior is is not defined.

This is especially true for symbols that restrict to a single library or a library group that requires all libraries within the group to be pinned to the same version, as there is no need to maintain compatibility with different versions of other AndroidX libraries.

I guess that the development team wanted to hide such restricted code from the API users. Probably due to changes in the future or because the code is intended to work as internal functionality

This is exactly correct. There is sometimes a need to expose functionality internally that would not make sense as public API, though we try to avoid it in general, because it makes it harder to copy a part of the code out and customize your own version of it. This is especially true with Java code, which doesn't have Kotlin's internal modifier to expose classes to the entire library (package-private doesn't really cut it).

Upvotes: 3

Related Questions