够检查SDK_INT或延迟加载需要使用较新的Andr​​oid的API?为什么?加载、SDK_INT、Andr、API

2023-09-14 23:05:27 作者:沫墨

code,如:

 如果(android.os.Build.VERSION.SDK_INT> = Build.VERSION_ codeS.GINGERBREAD)
        ed.apply();
    别的ed.commit();
 

在产生的Froyo警告:

  

三月4日至27日:40:35.025:W / dalvikvm(3138):VFY:无法解析接口方法219:Landroid /内容/共享preferences $编辑;。适用()V

但据我所知,在旧设备,这将是抛出一个RuntimeError这将中止应用程序(见的这里和)。

那么,这样的条件调用新的API(方法)的API 8(升级Froyo)的安全及以上或有哪里延迟加载还是需要的情况下?

在Dalvik的变化是什么使这个可能吗?

相关

Android安全地支持新的API推荐的方法有错误,如果类实现一个新的接口。为什么呢? Android解决与SDK_INT黑客的兼容性;这是正确的? 的Andr​​oid的Dalvik核查Eclair的 解决方案   

在产生的Froyo警告

这是完全正常的。

  

但据我所知,在旧设备,这将是抛出一个RuntimeError这将中止应用程序

有关的Andr​​oid 1.x的,是的。

  

那么,这样的条件调用新的API(方法)安全的API 8(升级Froyo)及以上

是的。

  

在Dalvik的变化是什么使这个可能吗?

这不再遇到一个不明身份的象征时,失败快,而是等待再次尝试解决这个问题是执行语句时。通过检查 SDK_INT ,并确保不执行该语句,你不死机。

Code such as :

    if (android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.GINGERBREAD)
        ed.apply();
    else ed.commit();

produces a warning in Froyo :

04-27 03:40:35.025: W/dalvikvm(3138): VFY: unable to resolve interface method 219: Landroid/content/SharedPreferences$Editor;.apply ()V

But I understand that in older devices this would be a RuntimeError which would abort the application (see here and here).

So is this way of conditionally calling new API (methods) safe in API 8 (Froyo) and above or there are cases where lazy loading is still needed ?

What changes on Dalvik made this possible ?

Related

Android recommended way of safely supporting newer apis has error if the class implements a newer interface. Why? Android solving compatibility with SDK_INT hack; is this ok? Android Dalvik Verification in Eclair

解决方案

produces a warning in Froyo

This is perfectly normal.

But I understand that in older devices this would be a RuntimeError which would abort the application

For Android 1.x, yes.

So is this way of conditionally calling new API (methods) safe in API 8 (Froyo) and above

Yes.

What changes on Dalvik made this possible ?

It no longer "fails fast" when encountering an unidentified symbol, but instead waits to try again to resolve it when the statement is executed. By checking SDK_INT and ensure that the statement is not executed, you don't crash.