6

I am the author of a library for use in Android applications. Currently checking how my library behaves with Android 14 (API 34).

Now, API 34 removes several existing methods. For example, the method android.webkit.WebSettings#setAppCacheEnabled has been removed. https://developer.android.com/about/versions/14/behavior-changes-14#non-sdk-restrictions

It is important to note that my library uses WebSettings#setAppCacheEnabled.

I have installed the library into a newly created application to make sure it works. My library is built with targetSdkVersion 28 and compileSdkVersion 28. And the app I created for Android 14 was built with targetSdkVersion 34 and compileSdkVersion 34.

The library and app's AndroidManifest will be merged by the ManifestMerger and both should work with API 34.

I expected this test app to not work correctly because WebSettings#setAppCacheEnabled was removed in API 34. But in fact, contrary to my expectations, no error occurred. Why is this?

Anyone who knows why, please tell me.

(I performed this test on an Android 14 (UpsideDown Preview) emulator.)

Peri
  • 253
  • 1
  • 2
  • 12
  • What do you mean by "no error occurred"? what did you expect? App crash or just this feature in the app doesn't work without crashing (like a button without any action)? – C.F.G Aug 03 '23 at 05:04
  • The "no error occurred" here means that the application ran normally without crashing or throwing an exception. – Peri Aug 03 '23 at 06:19
  • Does this feature work properly in the installed app? – C.F.G Aug 03 '23 at 06:22
  • Yes. So I wondered and asked the question. – Peri Aug 03 '23 at 07:34
  • Have you tested your app by downgrading to API 33? If yes, then the Android system does not proving access to that restricted part of your library. You can't access the library's functionality if that is not completable with your Current SDK. – M DEV Aug 05 '23 at 11:12
  • I think you should update your library to be up to date. That means targeting and compiling for API Level 34. Regarding the enabled app cache you might can just drop that because webview cache is on by default (see [here](https://developer.android.com/reference/android/webkit/WebSettings#LOAD_DEFAULT)). It's more the other way around. If you want the cache to be turned off you may need to switch to [this](https://stackoverflow.com/q/73488108/3559908) – Vall0n Aug 09 '23 at 09:12

4 Answers4

1

if your library has lower api than the application, there will be no problem. but if application has lower api version that your library, you may see some unexpected behavior

Sep
  • 147
  • 8
1

Here's how it might work in your case:

  1. The library is built with targetSdkVersion 28 and includes a call to WebSettings#setAppCacheEnabled.
  2. The app that uses the library is built with targetSdkVersion 34, which means it's designed for API 34 and higher. When the merged AndroidManifest is created by the ManifestMerger, it doesn't change the fact that the library's call to WebSettings#setAppCacheEnabled still exists in the code. However, when the app is actually run on an Android 34 device:

The part of the library that calls WebSettings#setAppCacheEnabled may never be executed. This could be due to conditional checks or code paths that prevent its execution on devices with higher API levels. Alternatively, if the library's code that calls WebSettings#setAppCacheEnabled is executed, it's possible that Android's runtime checks are preventing the method from being invoked on devices where it's no longer available. To determine why you're not seeing errors or unexpected behavior, you would need to analyze the code in your library, the way it's being used in the app, and any runtime checks or conditional statements that might be preventing the method call on devices with API 34.

It's also important to note that while the app might seem to work without errors, relying on removed methods can lead to unpredictable behavior, crashes, or other issues. It's generally best to follow Android's guidelines and avoid using deprecated or removed methods to ensure the stability and compatibility of your app across different Android versions.

Jamil Hasnine Tamim
  • 4,389
  • 27
  • 43
0

The Application Cache API is no longer supported and this method is a no-op on WebView 95 and later. source

You may want to check the WebView version by these Stackoverflow answers, or Go to settings > apps > Android System Webview > version

Mohammad Reza Khahani
  • 678
  • 4
  • 16
-1

For now, the method you are using could just be added to unsupported category hence you are able to use it. It may be blocked in future.

Conditionally blocked (greylist-max-x):-

Starting with Android 9 (API level 28), each API level has non-SDK interfaces that are restricted when an app targets that API level.

These lists are labelled by the maximum API level (max-target-x) that an app can target before the app can no longer access the non-SDK interfaces in that list. For example, a non-SDK interface that was not blocked in Android Pie but is now blocked in Android 10 is part of the max-target-p (greylist-max-p) list, where “p” stands for Pie or Android 9 (API level 28).

If your app attempts to access an interface that is restricted for your target API level, the system behaves as if the API is part of the blocklist.

Check this: https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces#list-names

AbdulAhad
  • 1
  • 1