androidreference
A. 如何調用Android系統程序詳細信息界面
調用Android系統「應用程序信息（Application Info）」界面「Android系統設置->應用程序->管理應用程序」列表下，列出了系統已安裝的應用程序。選擇其中一個程序，則進入「應用程序信息（Application Info）」界面。這個界面顯示了程序名稱、版本、存儲、許可權等信息，並有卸載、停止、清除緩存等按鈕，可謂功能不少。如果在編寫相關程序時（比如任務管理器）可以調用這個面板，自然提供了很大的方便。那麼如何實現呢？
在最新的Android SDK 2.3(API Level 9)中，提供了這樣的介面。在文檔路徑
docs/reference/android/provider/Settings.html#ACTION_APPLICATION_DETAILS_SETTINGS
下，有這樣的描述：
public static final String ACTION_APPLICATION_DETAILS_SETTINGS Since: API Level 9
Activity Action: Show screen of details about a particular application.
In some cases, a matching Activity may not exist, so ensure you safeguard against this.
Input: The Intent's data URI specifies the application package name to be shown, with the "package" scheme. That is "package:com.my.app".
Output: Nothing.
Constant Value: "android.settings.APPLICATION_DETAILS_SETTINGS"
就是說，我們只要以android.provider.Settings.ACTION_APPLICATION_DETAILS_SETTINGS作為Action；「package:應用程序的包名」作為URI，就可以用startActivity啟動應用程序信息界面了。代碼如下：
view plain
Intent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
Uri uri = Uri.fromParts(SCHEME, packageName, null);
intent.setData(uri);
startActivity(intent);
但是，在Android 2.3之前的版本，並沒有公開相關的介面。
通過查看系統設置platform/packages/apps/Settings.git程序的源碼，可以發現應用程序信息界面為InstalledAppDetails。
在這里(2.1)還有這里(2.2)，我們可以分別看到Android2.1和Android2.2的應用管理程序（ManageApplications.java）是如何啟動InstalledAppDetails的。
view plain
// utility method used to start sub activity
private void () {
// Create intent to start new activity
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setClass(this, InstalledAppDetails.class);
intent.putExtra(APP_PKG_NAME, mCurrentPkgName);
// start new activity to display extended information
startActivityForResult(intent, INSTALLED_APP_DETAILS);
}
但是常量APP_PKG_NAME的定義並不相同。
2.2中定義為"pkg"，2.1中定義為"com.android.settings.ApplicationPkgName"
那麼，對於2.1及以下版本，我們可以這樣調用InstalledAppDetails：
view plain
Intent i = new Intent(Intent.ACTION_VIEW);
i.setClassName("com.android.settings","com.android.settings.InstalledAppDetails");
i.putExtra("com.android.settings.ApplicationPkgName", packageName);
startActivity(i);
對於2.2，只需替換上面putExtra的第一個參數為"pkg"
綜上，通用的調用「應用程序信息」的代碼如下：
view plain
private static final String SCHEME = "package";
/**
* 調用系統InstalledAppDetails界面所需的Extra名稱(用於Android 2.1及之前版本)
*/
private static final String APP_PKG_NAME_21 = "com.android.settings.ApplicationPkgName";
/**
* 調用系統InstalledAppDetails界面所需的Extra名稱(用於Android 2.2)
*/
private static final String APP_PKG_NAME_22 = "pkg";
/**
* InstalledAppDetails所在包名
*/
private static final String APP_DETAILS_PACKAGE_NAME = "com.android.settings";
/**
* InstalledAppDetails類名
*/
private static final String APP_DETAILS_CLASS_NAME = "com.android.settings.InstalledAppDetails";
/**
* 調用系統InstalledAppDetails界面顯示已安裝應用程序的詳細信息。 對於Android 2.3（Api Level
* 9）以上，使用SDK提供的介面； 2.3以下，使用非公開的介面（查看InstalledAppDetails源碼）。
*
* @param context
*
* @param packageName
* 應用程序的包名
*/
public static void showInstalledAppDetails(Context context, String packageName) {
Intent intent = new Intent();
final int apiLevel = Build.VERSION.SDK_INT;
if (apiLevel >= 9) { // 2.3（ApiLevel 9）以上，使用SDK提供的介面
intent.setAction(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
Uri uri = Uri.fromParts(SCHEME, packageName, null);
intent.setData(uri);
} else { // 2.3以下，使用非公開的介面（查看InstalledAppDetails源碼）
// 2.2和2.1中，InstalledAppDetails使用的APP_PKG_NAME不同。
final String appPkgName = (apiLevel == 8 ? APP_PKG_NAME_22
: APP_PKG_NAME_21);
intent.setAction(Intent.ACTION_VIEW);
intent.setClassName(APP_DETAILS_PACKAGE_NAME,
APP_DETAILS_CLASS_NAME);
intent.putExtra(appPkgName, packageName);
}
context.startActivity(intent);
}
B. Android四大組件是什麼講講你對它們的理解
Android有四大組件：Activity、Service、Broadcast Receiver、Content Provider。
Activity
做一個完整的Android程序，不想用到Activity，真的是比較困難的一件事情，除非是想做綠葉想瘋了。因為Activity是Android程序與用戶交互的窗口，在我看來，從這個層面的視角來看，Android的Activity特像網站的頁面。
Activity，在四大組件中，無疑是最復雜的，這年頭，一樣東西和界面掛上了勾，都簡化不了，想一想，獨立做一個應用有多少時間淪落在了界面上，就能琢磨清楚了。從視覺效果來看，一個Activity占據當前的窗口，響應所有窗口事件，具備有控制項，菜單等界面元素。從內部邏輯來看，Activity需要為了保持各個界面狀態，需要做很多持久化的事情，還需要妥善管理生命周期，和一些轉跳邏輯。對於開發者而言，就需要派生一個Activity的子類，然後埋頭苦幹上述事情。對於Activity的更多細節，先可以參見：reference/android/app/Activity.html。後續，會獻上更為詳盡的剖析。
Service
服務，從最直白的視角來看，就是剝離了界面的Activity，它們在很多Android的概念方面比較接近，都是封裝有一個完整的功能邏輯實現，只不過Service不拋頭露臉，只是默默無聲的做堅實的後盾。
但其實，換個角度來看，Android中的服務，和我們通常說的Windows服務，Web的後台服務又有一些相近，它們通常都是後台長時間運行，接受上層指令，完成相關事務的模塊。用運行模式來看，Activity是跳，從一個跳到一個，呃...，這有點像模態對話框（或者還像web頁面好了...），給一個輸入（抑或沒有...），然後不管不顧的讓它運行，離開時返回輸出（同抑或沒有...）。
而Service不是，它是等，等著上層連接上它，然後產生一段持久而纏綿的通信，這就像一個用了Ajax頁面，看著沒啥變化，偷偷摸摸的和Service不知眉來眼去多少回了。
但和一般的Service還是有所不同，Android的Service和所有四大組件一樣，其進程模型都是可以配置的，調用方和發布方都可以有權利來選擇是把這個組件運行在同一個進程下，還是不同的進程下。這句話，可以拿把指甲刀刻進腦海中去，它凸顯了Android的運行特徵。如果一個 Service，是有期望運行在於調用方不同進程的時候，就需要利用Android提供的RPC機制，為其部署一套進程間通信的策略。
Android的RPC實現，如上圖所示（好吧，也是從SDK中拿來主義的...），無甚稀奇，基於代理模式的一個實現，在調用端和服務端都去生成一個代理類，做一些序列化和反序列化的事情，使得調用端和伺服器端都可以像調用一個本地介面一樣使用RPC介面。
Android中用來做數據序列化的類是Parcel，參見：/reference/android/os/Parcel.html，封裝了序列化的細節，向外提供了足夠對象化的訪問介面，Android號稱實現非常高效。
還有就是AIDL (Android Interface Definition Language) ，一種介面定義的語言，服務的RPC介面，可以用AIDL來描述，這樣，ADT就可以幫助你自動生成一整套的代理模式需要用到的類，都是想起來很乏力寫起來很苦力的那種。更多內容，可以再看看：guide/developing/tools/aidl.html，如果有興致，可以找些其他PRC實現的資料lou幾眼。
關於Service的實現，還強推參看API Demos這個Sample裡面的RemoteService實現。它完整的展示了實現一個Service需要做的事情：那就是定義好需要接受的Intent，提供同步或非同步的介面，在上層綁定了它後，通過這些介面（很多時候都是RPC的...）進行通信。在RPC介面中使用的數據、回調介面對象，如果不是標準的系統實現（系統可序列化的），則需要自定義aidl，所有一切，在這個Sample里都有表達，強薦。
Service從實現角度看，最特別的就是這些RPC的實現了，其他內容，都會接近於Activity的一些實現，也許不再會詳述了。
Broadcast Receiver
在實際應用中，我們常需要等，等待系統抑或其他應用發出一道指令，為自己的應用擦亮明燈指明方向。而這種等待，在很多的平台上，都會需要付出不小的代價。
比如，在Symbian中，你要等待一個來電消息，顯示歸屬地之類的，必須讓自己的應用忍辱負重偷偷摸摸的開機啟動，消隱圖標隱藏任務項，潛伏在後台，監控著相關事件，等待轉瞬即逝的出手機會。這是一件很發指的事情，不但白白耗費了系統資源，還留了個流氓軟體的罵名，這真是賣力不討好的正面典型。
在Android中，充分考慮了廣泛的這類需求，於是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發事件（有不知道Intent的么，後面會知道了...），當發生這樣事件的時候，系統會負責喚醒或傳遞消息到該Broadcast Receiver，任其處置。在此之前和這以後，Broadcast Receiver是否在運行都變得不重要了，及其綠色環保。
這個實現機制，顯然是基於一種注冊方式的，Broadcast Receiver將其特徵描述並注冊在系統中，根據注冊時機，可以分為兩類，被我冠名為冷熱插拔。所謂冷插拔，就是Broadcast Receiver的相關信息寫在配置文件中（求配置文件詳情？稍安，後續奉上...），系統會負責在相關事件發生的時候及時通知到該Broadcast Receiver，這種模式適合於這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。比如，監聽來電、郵件、簡訊之類的，都隸屬於這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應用自己來處理的，通常是在 OnResume事件中通過registerReceiver進行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運行期間保持對相關事件的關注。比如，一款優秀的詞典軟體（比如，有道詞典...），可能會有在運行期間關注網路狀況變化的需求，使其可以在有廉價網路的時候優先使用網路查詢詞彙，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗，一舉兩得一石二鳥一箭雙雕（注，真實在有道詞典中有這樣的能力，但不是通過 Broadcast Receiver實現的，僅以為例...）。而這樣的監聽，只需要在其工作狀態下保持就好，不運行的時候，管你是天大的網路變化，與我何干。其模式可以歸結為：啟動應用 -> 監聽事件 -> 發生時進行處理。
除了接受消息的一方有多種模式，發送者也有很重要的選擇權。通常，發送這有兩類，一個就是系統本身，我們稱之為系統Broadcast消息，在reference/android/content/Intent.html 的Standard Broadcast Actions，可以求到相關消息的詳情。除了系統，自定義的應用可以放出Broadcast消息，通過的介面可以是 Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者發出的稱為Normal broadcast，所有關注該消息的Receiver，都有機會獲得並進行處理；後者放出的稱作Ordered broadcasts，顧名思義，接受者需要按資排輩，排在後面的只能吃前面吃剩下的，前面的心情不好私吞了，後面的只能喝西北風了。
當Broadcast Receiver接收到相關的消息，它們通常做一些簡單的處理，然後轉化稱為一條Notification，一次振鈴，一次震動，抑或是啟動一個 Activity進行進一步的交互和處理。所以，雖然Broadcast整個邏輯不復雜，卻是足夠有用和好用，它統一了Android的事件廣播模型，讓很多平台都相形見絀了。更多Broadcast Receiver相關內容，參見：/reference/android/content/BroadcastReceiver.html。
Content Provider
Content Provider，聽著就和數據相關，沒錯，這就是Android提供的第三方應用數據的訪問方案。在Android中，對數據的保護是很嚴密的，除了放在SD卡中的數據，一個應用所持有的資料庫、文件、等等內容，都是不允許其他直接訪問的，但有時候，溝通是必要的，不僅對第三方很重要，對應用自己也很重要。
比如，一個聯系人管理的應用。如果不允許第三方的應用對其聯系人資料庫進行增刪該查，整個應用就失去了可擴展力，必將被其他應用拋棄，然後另立門戶，自個玩自個的去了。
Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都准備了一扇窗，這就是Content Provider。應用想對外提供的數據，可以通過派生ContentProvider類， 封裝成一枚Content Provider，每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST 更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列
表的，但實現者不需要按照這個模式來做，給你id的uri你也可以返回列表類型的數據，只要調用者明白，就無妨，不用苛求所謂的REST。
另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數，這樣，就可以像資料庫那樣進行投影，選擇和排序。查詢到的結果，以Cursor（參見：reference/android/database/Cursor.html ）的形式進行返回，調用者可以移動Cursor來訪問各列的數據。
Content Provider屏蔽了內部數據的存儲細節，向外提供了上述統一的介面模型，這樣的抽象層次，大大簡化了上層應用的書寫，也對數據的整合提供了更方便的途徑。Content Provider內部，常用資料庫來實現，Android提供了強大的Sqlite支持，但很多時候，你也可以封裝文件或其他混合的數據。
在Android中，ContentResolver是用來發起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的介面。但通常，Content Provider需要訪問的可能是資料庫等大數據源，效率上不足夠快，會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler（參見：reference/android/content/AsyncQueryHandler.html），幫助進行非同步訪問Content Provider。
在各大組件中，Service和Content Provider都是那種需要持續訪問的。Service如果是一個耗時的場景，往往會提供非同步訪問的介面，而Content Provider不論效率如何，都提供的是約定的同步訪問介面。我想這遵循的就是場景導向設計的原則，因為Content Provider僅是提供數據訪問的，它不能確信具體的使用場景如何，會怎樣使用它的數據；而相比之下，Service包含的邏輯更復雜更完整，可以抉擇大部分時候使用某介面的場景，從而確定最貼切的介面是同步還是非同步，簡化了上層調用的邏輯。
C. android用cmake怎麼導入cpp文件夾，undifined reference to
ndroid Studio升級到2.2之後，我們可以先配置好NDK開發的一些所需工具，如圖，在SDK Tools中勾選安裝CMake、LLDB、NDK。
CMake: 外部構建工具。如果你准備只使用 ndk-build 的話，可以不使用它。
LLDB: Android Studio上面調試本地代碼的工具。
Android Studio自帶DEMO了解CMAKE
Android Studio升級到2.2版本之後，在創建新的project時，界面上多了一個Include C++ Support的選項。勾選它之後將會創建一個默認的C++與JAVA混編的Demo程序。就讓我們先來看看這個官方標准Demo吧。
開始之前最好先下載好NDK，見NDK開發 從入門到放棄(一：基本流程入門了解)，即在Project Structure界面Android NDK location處下載或選擇正確的路徑。或者使用上方提供的工具安裝方法來進行下載。否則，創建的新project也會報錯，需要配置好後clean。
File -> New -> New Project，在如下界面中勾選Include C++ Support，然後一路 Next，直到 Finish 為止即可。
項目打開後我們查看目錄結構，與常規項目不同的是多了.externalNativeBuild文件夾、cpp文件夾、CMakeLists.txt文件，如下圖：
這三個東西都是NDK部分：
1. .externalNativeBuild文件夾：cmake編譯好的文件, 顯示支持的各種硬體等信息。系統生成。
2. cpp文件夾：存放C/C++代碼文件，native-lib.cpp文件是該Demo中自帶的，可更改。需要自己編寫。
3. CMakeLists.txt文件：CMake腳本配置的文件。需要自己配置編寫。
Gradle中也有兩處不同：
java代碼：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// Example of a call to a native method
TextView tv = (TextView) findViewById(R.id.sample_text);
tv.setText(stringFromJNI());
}
/**
* A native method that is implemented by the 'native-lib' native library,
* which is packaged with this application.
*/
public native String stringFromJNI();
// Used to load the 'native-lib' library on application startup.
static {
System.loadLibrary("native-lib");
}
}2223
從native-lib.cpp的代碼中我們能看到它使用的是靜態注冊的方式，動態注冊的方式代碼同傳統JNI。
#include <jni.h>
#include <string>
extern "C"
jstring
Java_com_example_person_myapplication_MainActivity_stringFromJNI(
JNIEnv* env,
jobject /* this */) {
std::string hello = "Hello from C++";
return env->NewStringUTF(hello.c_str());
}12345678910111234567891011
CMakeLists.txt文件中我們需要注意的是下面這三個地方。兩個library的名字（需一致）以及一個cpp文件的路徑，彼此需要對應一致，當我們自己定義library以及自己創建cpp文件時需要對應修改。
D. Android 開發，Android Studio編譯慢，卡死和狂佔內存怎麼破
已經使用Android Studio進行開發超過一年，隨著項目的增大，依賴庫的增多，構建速度越來越慢，現在最慢要6分鍾才能build一個release的安裝包，在網上查找資料，發現可以通過一些配置可以加快速度，這里跟大家分享一下。
開啟gradle單獨的守護進程
在下面的目錄下面創建gradle.properties文件：
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
並在文件中增加：
org.gradle.daemon=true
同時修改項目下的gradle.properties文件也可以優化：
# Project-wide Gradle settings.
# IDE (e.g. Android Studio) users:
# Settings specified in this file will override any Gradle settings
# configured through the IDE.
# For more details on how to configure your build environment visit
# http://www.gradle.org/docs/current/userguide/build_environment.html
# The Gradle daemon aims to improve the startup and execution time of Gradle.
# When set to true the Gradle daemon is to run the build.
# TODO: disable daemon on CI, since builds should be clean and reliable on servers
org.gradle.daemon=true
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
# Default value: -Xmx10248m -XX:MaxPermSize=256m
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. More details, visit
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
org.gradle.parallel=true
# Enables new incubating mode that makes Gradle selective when configuring projects.
# Only relevant projects are configured which results in faster builds for large multi-projects.
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:configuration_on_demand
org.gradle.configureondemand=true
同時上面的這些參數也可以配置到前面的用戶目錄下的gradle.properties文件里，那樣就不是針對一個項目生效，而是針對所有項目生效。
上面的配置文件主要就是做， 增大gradle運行的java虛擬機的大小，讓gradle在編譯的時候使用獨立進程，讓gradle可以平行的運行。
修改android studio配置
在android studio的配置中，開啟offline模式，以及修改配置。實際上的配置和上面的一大段一樣，主要是在這個地方配置的只會在ide構建的時候生效，命令行構建不會生效。
命令行構建
基於上面的配置，命令行構建時在命令後面加上這個參數即可 --daemon --parallel --offline。
引入依賴庫時使用aar
使用網上第三方的依賴庫時盡量使用aar，可以在mavenhttp://gradleplease.appspot.com/或者githuhttps://github.com/Goddchen/mvn-repo搜索。
自己的庫模塊也可以打包成aar，關於這個可以參考stormzhang的文章http://www.stormzhang.com/android/2015/03/01/android-reference-local-aar/。