在開發Android應用程序時,Min和Target SDK版本有什麼區別? 除非Min和Target版本相同,不然Eclipse不會讓我建立一個新項目! html
對於那些想要總結的人, java
android:minSdkVersion
是您的應用程序支持的最低版本。 若是您的設備有較低版本的Android,應用程序將沒法安裝。 android
而, web
android:targetSdkVersion
是您的應用程序設計運行的API級別。 意味着,您的手機系統不須要使用任何兼容性行爲來保持向前兼容性,由於您已通過測試直到此API。 瀏覽器
您的應用程序仍將在比給定的targetSdkVersion
更高的Android版本上運行,但Android兼容性行爲將啓動。 app
贈品 - 框架
android:maxSdkVersion
ide
若是您的設備的API版本較高,則不會安裝應用。 IE瀏覽器。 這是您容許應用安裝的最高API。 函數
即。 對於MinSDK -4,maxSDK - 8,targetSDK - 8個人應用程序將在最小1.6上運行,但我也使用僅在2.2中支持的功能,若是它安裝在2.2設備上,它將是可見的。 此外,對於maxSDK - 8,此應用程序不會安裝在使用API> 8的手機上。 工具
在撰寫此答案時,Android文檔在解釋它時沒有作得很好。 如今它獲得了很好的解釋。 在這裏查看
當您設置targetSdkVersion =「xx」時,您將證實您的應用程序在API級別xx上正常工做(例如,已通過完全和成功測試)。
在xx 以上的API級別運行的Android版本將自動應用兼容性代碼,以支持API級別xx以前或以前可能依賴的任何功能,但如今已在Android版本的更高級別上淘汰。
相反,若是您使用的是在 xx級別以前或以前已過期的任何功能,則不會在較高API級別(再也不包括這些功能)的操做系統版本自動應用兼容性代碼來支持這些用途。 在這種狀況下,您本身的代碼必須具備測試API級別的特殊狀況子句,而且若是檢測到的操做系統級別更高,再也不具備給定的API功能,則您的代碼必須使用正在運行的操做系統中可用的備用功能API級別。
若是它沒法執行此操做,則可能根本不會出現一般會觸發代碼中的事件的某些界面功能,而且您可能缺乏用戶觸發這些事件並訪問其功能所需的關鍵界面功能(如例子以下)。
如其餘答案中所述,若是您想使用最初在比minSdkVersion更高的API級別定義的API功能,則能夠將targetSdkVersion設置爲高於minSdkVersion,而且已採起措施確保您的代碼能夠檢測並處理這些功能的缺失比targetSdkVersion更低的級別。
爲了警告開發人員專門測試使用某個功能所需的最低API級別,若是代碼包含對在minSdkVersion以後的API級別定義的任何方法的調用,編譯器將發出錯誤(而不只僅是警告),即便targetSdkVersion大於或等於該方法首次可用的API級別。 要刪除此錯誤,請使用編譯器指令
@TargetApi(nn)
告訴編譯器在調用依賴於至少具備該API級別的任何方法以前,已編寫該指令範圍內的代碼(將在方法或類以前)以測試至少nn的API級別。 例如,如下代碼定義了一個方法,該方法能夠從app中的代碼調用,該代碼的minSdkVersion小於11且targetSdkVersion爲11或更高:
@TargetApi(11) public void refreshActionBarIfApi11OrHigher() { //If the API is 11 or higher, set up the actionBar and display it if(Build.VERSION.SDK_INT >= 11) { //ActionBar only exists at API level 11 or higher ActionBar actionBar = getActionBar(); //This should cause onPrepareOptionsMenu() to be called. // In versions of the API prior to 11, this only occurred when the user pressed // the dedicated menu button, but at level 11 and above, the action bar is // typically displayed continuously and so you will need to call this // each time the options on your menu change. invalidateOptionsMenu(); //Show the bar actionBar.show(); } }
您可能還須要申報更高targetSdkVersion若是你已經在這個更高的水平測試,一切正常,即便您沒有使用從比你的minSdkVersion更高的API級別的任何功能。 這只是爲了不訪問旨在從目標級別調整到最低級別的兼容性代碼的開銷,由於您已經確認(經過測試)不須要這樣的調整。
取決於聲明的targetSdkVersion的UI功能的一個示例是當這些應用程序在API 11及更高版本下運行時,顯示在targetSdkVersion小於11的應用程序的狀態欄上的三垂直點菜單按鈕。 若是您的應用的targetSdkVersion爲10或更低,則假定您的應用的界面取決因而否存在專用菜單按鈕,所以三點式按鈕彷佛取代了早期的專用硬件和/或屏幕版本當OS具備較高的API級別時,該按鈕(例如,如Gingerbread中所見),再也不假設設備上的專用菜單按鈕。 可是,若是將應用程序的targetSdkVersion設置爲11或更高,則假定您已利用該級別引入的功能替換專用菜單按鈕(例如,操做欄),或者您已經規避了須要有一個系統菜單按鈕; 所以,三垂直點菜單「兼容性按鈕」消失。 在這種狀況下,若是用戶找不到菜單按鈕,則沒法按下它,反過來,這意味着您的活動的onCreateOptionsMenu(菜單)覆蓋可能永遠不會被調用,這反過來又意味着應用程序功能的重要部分可能會被剝奪其用戶界面。 固然,除非您已實施操做欄或其餘一些替代方法,以便用戶訪問這些功能。
相比之下,minSdkVersion聲明要求設備的操做系統版本至少具備該API級別才能運行您的應用程序。 這會影響哪些設備能夠在Google Play應用商店(以及其餘應用商店)上查看和下載您的應用。 這是一種說明您的應用程序依賴於在該級別上創建的OS(API或其餘)功能的方式,而且沒有可接受的方式來處理這些功能的缺失。
使用的minSdkVersion確保不 API相關的一個特徵的存在的一個例子是對的minSdkVersion爲了設置爲8,以確保您的應用程序將只在Dalvik解釋的啓用JIT版本上運行(由於JIT介紹到API級別的Android解釋器8)。 因爲啓用JIT的解釋器的性能多是缺乏該功能的解釋器的五倍,若是您的應用程序大量使用處理器,那麼您可能須要API級別8或更高級別以確保足夠的性能。
若是您遇到一些編譯錯誤,例如:
<uses-sdk android:minSdkVersion="10" android:targetSdkVersion="15" />
。
private void methodThatRequiresAPI11() { BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Config.ARGB_8888; // API Level 1 options.inSampleSize = 8; // API Level 1 options.inBitmap = bitmap; // **API Level 11** //... }
你獲得編譯錯誤:
字段須要API級別11(當前最小值爲10):android.graphics.BitmapFactory $ Options#inBitmap
從Android開發工具(ADT)的第17版開始,有一個新的很是有用的註釋@TargetApi
能夠很容易地解決這個問題。 在包含有問題的聲明的方法以前添加它:
@TargetApi private void methodThatRequiresAPI11() { BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Config.ARGB_8888; // API Level 1 options.inSampleSize = 8; // API Level 1 // This will avoid exception NoSuchFieldError (or NoSuchMethodError) at runtime. if (Integer.valueOf(android.os.Build.VERSION.SDK) >= android.os.Build.VERSION_CODES.HONEYCOMB) { options.inBitmap = bitmap; // **API Level 11** //... } }
如今沒有編譯錯誤
,它將運行!
編輯:這將致使API級別低於11的運行時錯誤。在11或更高版本上它將運行沒有問題。 所以,您必須確保在由版本檢查保護的執行路徑上調用此方法。 TargetApi只容許您編譯它,可是您本身承擔風險。
老是能夠經過示例更好地提供概念 。 直到我深刻研究Android框架源代碼並進行一些實驗,即便在閱讀Android開發人員網站和相關的stackoverflow線程中的全部文檔以後,我也沒法理解這些概念。 我將分享兩個幫助我徹底理解這些概念的例子。
根據您放入AndroidManifest.xml文件的targetSDKversion( <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>
)的級別, DatePickerDialog看起來會有所不一樣。 若是將值設置爲10或更低,則DatePickerDialog將顯示爲左側。 另外一方面,若是將值設置爲11或更高,則DatePickerDialog看起來會像右邊同樣,代碼徹底相同 。
我用來建立這個示例的代碼很是簡單。 MainActivity.java
看起來:
public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); } public void onClickButton(View v) { DatePickerDialog d = new DatePickerDialog(this, null, 2014, 5, 4); d.show(); } }
而activity_main.xml
看起來:
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" > <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:onClick="onClickButton" android:text="Button" /> </RelativeLayout>
而已。 這就是我須要測試的全部代碼。
當您看到Android框架源代碼時,這種外觀變化很是清晰。 它像:
public DatePickerDialog(Context context, OnDateSetListener callBack, int year, int monthOfYear, int dayOfMonth, boolean yearOptional) { this(context, context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB ? com.android.internal.R.style.Theme_Holo_Light_Dialog_Alert : com.android.internal.R.style.Theme_Dialog_Alert, callBack, year, monthOfYear, dayOfMonth, yearOptional); }
如您所見,框架獲取當前的targetSDKversion並設置不一樣的主題。 這種代碼片斷( getApplicationInfo().targetSdkVersion >= SOME_VERSION
)能夠在Android框架中找到。
另外一個例子是關於WebView類。 Webview類的公共方法應該在主線程上調用,不然,運行時系統會在設置targetSDKversion 18或更高版本時拋出RuntimeException
。 可使用其源代碼清楚地傳遞此行爲。 它就是這樣寫的。
sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.JELLY_BEAN_MR2; if (sEnforceThreadChecking) { throw new RuntimeException(throwable); }
Android文檔稱,「 隨着Android隨着每一個新版本的發展,一些行爲甚至外觀均可能發生變化 。」 所以,咱們看到了行爲和外觀的變化,以及如何實現這種變化。
總之,Android文檔說「 此屬性(targetSdkVersion)通知系統您已針對目標版本進行了測試,系統不該啓用任何兼容性行爲來維持應用程序與目標版本的向前兼容性。 」 WebView案例很是清楚。 直到JELLY_BEAN_MR2發佈才能在非主線程上調用WebView類的公共方法。 若是Android框架在JELLY_BEAN_MR2設備上拋出RuntimeException,這是無稽之談。 它只是不該該爲其興趣啓用新引入的行爲,這會致使致命的結果。 所以,咱們要作的是檢查某些targetSDKversions上是否一切正常。 咱們經過設置更高的targetSDKversion得到外觀加強等好處,但它有責任。
編輯:免責聲明。 基於當前targetSDKversion設置不一樣主題的DatePickerDialog構造函數(我在上面展現的)實際上已在之後的提交中更改。 儘管如此,我使用了這個例子,由於邏輯沒有被改變,那些代碼片斷清楚地顯示了targetSDKversion概念。
android:minSdkVersion
和android:targetSdkVersion
都是咱們須要在android清單文件中聲明的Integer值,但二者都有不一樣的屬性。
android:minSdkVersion:
這是運行Android應用程序所需的最低API級別。 若是咱們將在較低的API版本上安裝相同的應用程序,則會出現解析器錯誤,而且將出現應用程序不支持問題。
android:targetSdkVersion:
目標sdk版本是設置app的Target API級別。 若是未在清單中聲明此屬性,則minSdk版本將是您的TargetSdk版本。 這始終是「app支持在咱們聲明爲TargetSdk版本的全部更高版本的API上安裝」。 要使app限制目標,咱們須要在清單文件中聲明maxSdkVersion ...