# When Android Compat Libraries Do Not Prevent New API Compatibility Issues

DevFeed: [When Android Compat Libraries Do Not Prevent New API Compatibility Issues](<https://devfeed.tech/articles/when-compat-libraries-won-t-save-you-25895.md>)

Original publisher: [Read original article](<https://proandroiddev.com/when-compat-libraries-do-not-save-you-dc55f16b4160?source=rss-1331e67af4e1------2>)

Author: Danny Preussler

Published: 2021-01-04T19:34:03Z

Content type: tutorial

Language: en

Sources: [Stories by Danny Preussler on Medium](<https://devfeed.tech/sources/stories-by-danny-preussler-on-medium.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Jetpack](<https://devfeed.tech/topics/jetpack.md>), [deprecated](<https://devfeed.tech/topics/deprecated.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [deprecated](<https://devfeed.tech/tags/deprecated.md>), [fragmentation](<https://devfeed.tech/tags/fragmentation.md>), [jetpack](<https://devfeed.tech/tags/jetpack.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [linter](<https://devfeed.tech/tags/linter.md>)

## AI overview

This tutorial explains why Android compatibility libraries do not all work the same way. Some duplicate platform APIs, while others bridge to the original APIs, so developers still need appropriate API-level checks and should avoid using the "NewApi" suppression indiscriminately.

## Source excerpt

And why you should avoid using the "NewApi" suppression! https://unsplash.com/photos/EgGIPA68Nwo The idea of "Compat" libraries was probably one of the key aspects of Android dominating the mobile space. Other than with iOS, Android users often could not update their operating system after a new version launch, simply as their phones won't allow them to, the Android problem of fragmentation. But developers still wanted to use the latest features to compete. The solution was simple: instead of adding new APIs to the operating system, you shipped those directly with your app by using a "backport" version Google gave you. It all started with ActionBar Sherlock by Jake Wharton then got adopted by Google with in their "support libraries". Later on, this was mirrored as AndroidX under the Jetpack umbrella. Same but different Under the hood, not all of those "compat"-APIs are made the same way. Some, like the ones for Fragments, are complete copies of the code. You either use android.app.Fragment from the OS (actually deprecated) or androidx.fragment.app.Fragment. Both don't share any code or have a common base class (which is why we also have two versions of the FragmentManager). On the other handAppCompatActivity for example, simply extends the original Activity. AlsoAppCompatImageButton still is an ImageButton! We can see that sometimes these "Compat"-classes are just a "bridge" to add missing functionalities and sometimes they are complete duplicates. Let's look at another example! One area that changed a lot over time is the notification API from Android. There was a time where every Google I/O introduced a new API change. Good that we have NotificationManagerCompat to save us!? If, for example, we need to get the notification channel groups: val groups = notificationManagerCompat.notificationChannelGroups We don't need to worry about the groups being supported on all OS versions, as it is handled under the hood for us: public List<NotificationChannelGroup> getNotific