android常見的異常
① android，java常遇到的異常以及如何解決
比較常見異常有以下幾個
第一種：空指針異常 解決方式：先判斷數據是否為空再進行下一步
第二種：數組下標越界 解決方式：先查看一下數組的length
② Android 中的異常處理
異常發生時，如果沒有一個異常處理器來處理這個異常，程序會被中止。在 JVM 當中有一個預先定義好的異常處理層次結構。
結構中的第一層是 catch 塊。
如果第一個 catch 塊無法處理這個異常，異常便會被傳遞給下面的 catch 塊。如果所有的 catch 塊都無法處理某個異常，該異常便會交由當前線程的 UncaughtExceptionHandler 來處理。 UncaughtExceptionHandler 是個只有一個方法的介面。
UncaughtExceptionHandler 可以調協在當前線程里，未被 catch 塊捕獲的異常處理流程會先來到這里；還可以設置在 ThreadGroup 當中，當前線程的 UncaughtExceptionHandler 無法處理的異常會在這里被處理。如果 ThreadGroup 的 UncaughtExceptionHandler 還是無法處理該異常，那麼最終將會被交由默認異常處理程序 ( default uncaught exception handler ) 處理，也就是列印出異常棧，並終止程序。當然你也可以覆蓋這種行為：
③ 安卓手機上應用程序常見的流量異常消耗原因
後台程序運行過多。
運行完程序如瀏覽器、電子郵件等功能後，建議按「返回鍵」退出，如果按「主屏鍵」，應用程序仍在後台運行，不是真正的關閉（或者您可以進入任務管理器中結束後台運行的程序）。
手機如果帶有wifi功能，在能使用wifi的地方盡量使用wifi。瀏覽網頁如果可以關閉圖片、動畫聲音，盡量關閉，上傳圖片盡量壓縮小之後再上傳。
下載東西時，盡量使用帶斷點續傳功能的軟體下載，以免中途斷線又要重新下載。經常查看聯網的後台程序，如果可以設置軟體聯網時間間隔，可以盡量設大(如檢查電子郵件時間)。關閉軟體自動更新，自動網路獲取信息等功能。
當前很多企業的網路帶寬很大，正常情況下可以完全滿足企業的網路需求，但是常常卻發生網路堵塞的情況。
有些企業以為是網通、電信的帶寬不足，不得不花費巨資增加帶寬，但是網路堵車卻仍舊屢屢發生。原因在於P2P下載軟體流量佔用了寬頻接入的大量帶寬，據統計已經超過了50%。
這對於乙太網接入等共享帶寬的寬頻接入方式提出了很大的挑戰，大量的使接入層交換機的埠長期工作在線速狀態，嚴重影響了用戶使用正常的Web、E-mail以及視頻點播等業務。
④ 在android中,數據下標越界,則發生什麼異常
在android中，數據下標越界，會發生IndexOutOfBoundsException——下標越界異常。
Android應用使用Java語言進行開發，常見的異常還有：
1、NullPointerException - 空指針引用異常；
2、ClassCastException - 類型強制轉換異常；
3、IllegalArgumentException - 傳遞非法參數異常；
4、ArithmeticException - 算術運算異常；
5、ArrayStoreException - 向數組中存放與聲明類型不兼容對象異常；
6、NegativeArraySizeException - 創建一個大小為負數的數組錯誤異常；
7、NumberFormatException - 數字格式異常；
8、SecurityException - 安全異常；
9、UnsupportedOperationException - 不支持的操作異常。
⑤ Android實現錄屏MediaProjection以及相關異常解決
需要實現一個手機的錄屏功能，於是從網上找了些相關資料和源碼，發現跑不起來，於是開始bug，發現坑還是很多的，這里記錄一下實現過程和一些些遇到的異常以及一個我調整完可以跑的Demo。
首先在AndroidManifest中靜態配置許可權：
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.RECORD_AUDIO"/>
然後在Activity中動態申請
if (ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.WRITE_EXTERNAL_STORAGE)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(this,
new String[] {Manifest.permission.WRITE_EXTERNAL_STORAGE}, STORAGE_REQUEST_CODE);
}
if (ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.RECORD_AUDIO)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(this,
new String[] {Manifest.permission.RECORD_AUDIO}, AUDIO_REQUEST_CODE);
}
因為項目中需要用到一個自定義的Application，所以要需要配置一個全局的Application，同樣在AndroidManiest中在application添加自定義的類名，如果在裡面啟動服務了也要一並配置。
<application
android:name=".RecordApplication"
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
</application>
然後可以使用封裝好的實現其錄屏功能的service，這個封裝類是網上找的，看很多人在用，我解決了一些異常，並根據自己需求修改了一下。
其中主要異常有：
1.mediaRecorder報空指針，解決方案，在聲明的時候聲明為靜態
private static MediaRecorder mediaRecorder;
2.mediaRecorder.start()方法異常，在每次調用stop時要先調用
mediaRecorder.stop();
mediaRecorder.release();
兩個方法，並將
mediaRecorder = null。
mediaRecorder.setAudioSource（MediaRecorder.AudioSource.MIC）異常，這里是設置音頻源，可嘗試將參數改為
MediaRecorder.AudioSource.DEFAULT
4.stop方法異常，如果是running狀態不正常，可能是其狀態丟失，需要將聲明的running也改為靜態的
0.增加需求，在生成視頻時大部分人都會根據mediaRecorder.setVideoSize(width, height);方法來定死視頻大小，導致一些手機會解析不了，或者是視頻比屏幕小，這里提供一種根據屏幕大小動態設置視頻大小的方法。
這里就要用到我們之前定義的全局的Application，然後調用getInstance（）獲取其實例，
然後通過
DisplayMetrics dm = RecordApplication.getInstance().getResources().getDisplayMetrics();
private int width = dm.widthPixels;
private int height = dm.heightPixels;
private int dpi = dm.densityDpi;
來獲取屏幕的長、寬和dpi的值，這里不用WindowsManager方法是因為我是在非Activity去獲取屏幕長寬的，所以用了getDisplayMetrics();
這樣這個功能基本就是實現了。
Demo地址： https://github.com/han103070/Screencap
⑥ 安卓常見異常
在Java中異常機制的一些概念。寫本文的目的在於方便我很長時間後若是忘了這些東西可以通過這篇文章迅速回憶起來。
1. 異常機制
1.1 異常機制是指當程序出現錯誤後，程序如何處理。具體來說，異常機制提供了程序退出的安全通道。當出現錯誤後，程序執行的流程發生改變，程序的控制權轉移到異常處理器。
1.2 傳統的處理異常的辦法是，函數返回一個特殊的結果來表示出現異常（通常這個特殊結果是大家約定俗稱的），調用該函數的程序負責檢查並分析函數返回的結果。這樣做有如下的弊端：例如函數返回-1代表出現異常，但是如果函數確實要返回-1這個正確的值時就會出現混淆；可讀性降低，將程序代碼與處理異常的代碼混爹在一起；由調用函數的程序來分析錯誤，這就要求客戶程序員對庫函數有很深的了解。
1.3 異常處理的流程
1.3.1 遇到錯誤，方法立即結束，並不返回一個值；同時，拋出一個異常對象
1.3.2 調用該方法的程序也不會繼續執行下去，而是搜索一個可以處理該異常的異常處理器，並執行其中的代碼
2 異常的分類
2.1 異常的分類
2.1.1 異常的繼承結構：基類為Throwable，Error和Exception繼承Throwable，RuntimeException和 IOException等繼承Exception，具體的RuntimeException繼承RuntimeException。
2.1.2 Error和RuntimeException及其子類成為未檢查異常（unchecked），其它異常成為已檢查異常（checked）。
2.2 每個類型的異常的特點
2.2.1 Error體系 Error類體系描述了Java運行系統中的內部錯誤以及資源耗盡的情形。應用程序不應該拋出這種類型的對象（一般是由虛擬機拋出）。如果出現這種錯誤，除了盡力使程序安全退出外，在其他方面是無能為力的。所以，在進行程序設計時，應該更關注Exception體系。
2.2.2 Exception體系 Exception體系包括RuntimeException體系和其他非RuntimeException的體系
2.2.2.1 RuntimeException RuntimeException體系包括錯誤的類型轉換、數組越界訪問和試圖訪問空指針等等。處理RuntimeException的原則是：如果出現 RuntimeException，那麼一定是程序員的錯誤。例如，可以通過檢查數組下標和數組邊界來避免數組越界訪問異常。
2.2.2.2 其他（IOException等等）這類異常一般是外部錯誤，例如試圖從文件尾後讀取數據等，這並不是程序本身的錯誤，而是在應用環境中出現的外部錯誤。
2.3 與C++異常分類的不同
2.3.1 其實，Java中RuntimeException這個類名起的並不恰當，因為任何異常都是運行時出現的。（在編譯時出現的錯誤並不是異常，換句話說，異常就是為了解決程序運行時出現的的錯誤）。
2.3.2 C++中logic_error與Java中的RuntimeException是等價的，而runtime_error與Java中非RuntimeException類型的異常是等價的。
3 異常的使用方法
3.1 聲明方法拋出異常
3.1.1 語法：throws（略）
3.1.2 為什麼要聲明方法拋出異常？方法是否拋出異常與方法返回值的類型一樣重要。假設方法拋出異常確沒有聲明該方法將拋出異常，那麼客戶程序員可以調用這個方法而且不用編寫處理異常的代碼。那麼，一旦出現異常，那麼這個異常就沒有合適的異常控制器來解決。
3.1.3 為什麼拋出的異常一定是已檢查異常？ RuntimeException與Error可以在任何代碼中產生，它們不需要由程序員顯示的拋出，一旦出現錯誤，那麼相應的異常會被自動拋出。而已檢查異常是由程序員拋出的，這分為兩種情況：客戶程序員調用會拋出異常的庫函數（庫函數的異常由庫程序員拋出）；客戶程序員自己使用throw語句拋出異常。遇到Error，程序員一般是無能為力的；遇到RuntimeException，那麼一定是程序存在邏輯錯誤，要對程序進行修改（相當於調試的一種方法）；只有已檢查異常才是程序員所關心的，程序應該且僅應該拋出或處理已檢查異常。
3.1.4 注意：覆蓋父類某方法的子類方法不能拋出比父類方法更多的異常，所以，有時設計父類的方法時會聲明拋出異常，但實際的實現方法的代碼卻並不拋出異常，這樣做的目的就是為了方便子類方法覆蓋父類方法時可以拋出異常。
3.2 如何拋出異常
3.2.1 語法：throw（略）
3.2.2 拋出什麼異常？對於一個異常對象，真正有用的信息時異常的對象類型，而異常對象本身毫無意義。比如一個異常對象的類型是 ClassCastException，那麼這個類名就是唯一有用的信息。所以，在選擇拋出什麼異常時，最關鍵的就是選擇異常的類名能夠明確說明異常情況的類。
3.2.3 異常對象通常有兩種構造函數：一種是無參數的構造函數；另一種是帶一個字元串的構造函數，這個字元串將作為這個異常對象除了類型名以外的額外說明。
3.2.4 創建自己的異常：當Java內置的異常都不能明確的說明異常情況的時候，需要創建自己的異常。需要注意的是，唯一有用的就是類型名這個信息，所以不要在異常類的設計上花費精力。
3.3 捕獲異常如果一個異常沒有被處理，那麼，對於一個非圖形界面的程序而言，該程序會被中止並輸出異常信息；對於一個圖形界面程序，也會輸出異常的信息，但是程序並不中止，而是返回用戶界面處理循環中。
3.3.1 語法：try、catch和finally（略）控制器模塊必須緊接在try塊後面。若擲出一個異常，異常控制機制會搜尋參數與異常類型相符的第一個控制器隨後它會進入那個catch 從句，並認為異常已得到控制。一旦catch 從句結束對控制器的搜索也會停止。 3.3.1.1 捕獲多個異常（注意語法與捕獲的順序）（略）
3.3.1.2 finally的用法與異常處理流程（略）
3.3.2 異常處理做什麼？對於Java來說，由於有了垃圾收集，所以異常處理並不需要回收內存。但是依然有一些資源需要程序員來收集，比如文件、網路連接和圖片等資源。
3.3.3 應該聲明方法拋出異常還是在方法中捕獲異常？原則：捕捉並處理哪些知道如何處理的異常，而傳遞哪些不知道如何處理的異常
3.3.4 再次拋出異常
3.3.4.1 為什麼要再次拋出異常？在本級中，只能處理一部分內容，有些處理需要在更高一級的環境中完成，所以應該再次拋出異常。這樣可以使每級的異常處理器處理它能夠處理的異常。
3.3.4.2 異常處理流程對應與同一try塊的catch塊將被忽略，拋出的異常將進入更高的一級。
4 關於異常的其他問題
4.1 過度使用異常首先，使用異常很方便，所以程序員一般不再願意編寫處理錯誤的代碼，而僅僅是簡簡單單的拋出一個異常。這樣做是不對的，對於完全已知的錯誤，應該編寫處理這種錯誤的代碼，增加程序的魯棒性。另外，異常機制的效率很差。
4.2 將異常與普通錯誤區分開對於普通的完全一致的錯誤，應該編寫處理這種錯誤的代碼，增加程序的魯棒性。只有外部的不能確定和預知的運行時錯誤才需要使用異常。
4.3 異常對象中包含的信息一般情況下，異常對象唯一有用的信息就是類型信息。但使用異常帶字元串的構造函數時，這個字元串還可以作為額外的信息。調用異常對象的getMessage()、toString()或者printStackTrace()方法可以分別得到異常對象的額外信息、類名和調用堆棧的信息。並且後一種包含的信息是前一種的超集。
⑦ Android P 系統穩定性問題分析方法總結
Android系統最開始是為手機設計的，在機頂盒，電視，帶屏音箱等大屏上運行後，晶元廠家做些適配，產品廠家也會做系統客制化，有時候還要適配第三方應用..等待
這種適配容易引人系統的穩定性問題，系統穩定性對於用戶體驗至關重要，很多問題也都比較類似，android系統對系統性能，穩定性分析工具也比較多，下面根據工作中遇到的問題做個總結。
從表現來看有: 死機重啟, 自動關機, 無法開機,凍屏,黑屏以及閃退, 無響應等情況;
從技術層面來劃分無外乎兩大類: 長時間無法執行完成(Timeout) 以及異常崩潰(crash). 主要分類如下:
ANR(Application Not responding)，是指普通app進程超過一定時間沒有執行完，系統會彈出應用無響應對話框. 如果
該進程運行在system進程, 更准確的來說,應該是(System Not Responding, SNR)
ANR產生的原因可能是各種各樣的，但常見的原因可以分為：
1.logcat日誌
2.trace文件(保存在/data/anr/traces.txt)
從logcat里可以看到死鎖的列印
從traces.txt可以看到線程的函數調用棧
10-16 00:50:10 820 907 E ActivityManager: ANR in com.android.systemui, time=130090695
10-16 00:50:10 820 907 E ActivityManager: Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }
10-16 00:50:10 820 907 E ActivityManager: Load: 30.4 / 22.34 / 19.94
10-16 00:50:10 820 907 E ActivityManager: Android time :[2015-10-16 00:50:05.76] [130191,266]
10-16 00:50:10 820 907 E ActivityManager: CPU usage from 6753ms to -4ms ago:
10-16 00:50:10 820 907 E ActivityManager: 47% 320/netd: 3.1% user + 44% kernel / faults: 14886 minor 3 major
10-16 00:50:10 820 907 E ActivityManager: 15% 10007/com.sohu.sohuvideo: 2.8% user + 12% kernel / faults: 1144 minor
10-16 00:50:10 820 907 E ActivityManager: 13% 10654/hif_thread: 0% user + 13% kernel
10-16 00:50:10 820 907 E ActivityManager: 11% 175/mmcqd/0: 0% user + 11% kernel
10-16 00:50:10 820 907 E ActivityManager: 5.1% 12165/app_process: 1.6% user + 3.5% kernel / faults: 9703 minor 540 major
10-16 00:50:10 820 907 E ActivityManager: 3.3% 29533/com.android.systemui: 2.6% user + 0.7% kernel / faults: 8402 minor 343 major
......
10-16 00:50:10 820 907 E ActivityManager: +0% 12832/cat: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: +0% 13211/zygote64: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: 87% TOTAL: 3% user + 18% kernel + 64% iowait + 0.5% softirq
發生ANR的時間 00:50:10 ,可以從這個時間點之前的日誌中，還原ANR出現時系統的運行狀態
發生ANR的進程 com.android.system.ui
發生ANR的原因 Reason關鍵字表明了ANR的原因是處理TIME_TICK廣播消息超時
CPU負載 Load關鍵字表明了最近1分鍾、5分鍾、15分鍾內的CPU負載分別是30.4、22.3、19.94.CPU最近1分鍾的負載最具參考價值，因為ANR的超時限制基本都是1分鍾以內， 這可以近似的理解為CPU最近1分鍾平均有30.4個任務要處理，這個負載值是比較高的
CPU使用統計時間段 CPU usage from XX to XX ago關鍵字表明了這是在ANR發生之前一段時間內的CPU統計,類似的還有CPU usage from XX to XX after關鍵字，表明是ANR發生之後一段時間內的CPU統計
各進程的CPU使用率
以com.android.systemui進程的CPU使用率為例，它包含以下信息：
總的CPU使用率: 3.3%，其中systemui進程在用戶態的CPU使用率是2.6%，在內核態的使用率是0.7%
缺頁次數fault：8402 minor表示高速緩存中的缺頁次數，343 major表示內存的缺頁次數。minor可以理解為進程在做內存訪問，major可以理解為進程在做IO操作。 當前minor和major值都是比較高的，從側面反映了發生ANR之前，systemui進程有有較多的內存訪問操作，引發的IO次數也會較多
CPU使用匯總 TOTAL關鍵字表明了CPU使用的匯總，87%是總的CPU使用率，其中有一項iowait表明CPU在等待IO的時間，佔到64%，說明發生ANR以前，有大量的IO操作。app_process、 system_server, com.android.systemui這幾個進程的major值都比較大，說明這些進程的IO操作較為頻繁，從而拉升了整個iowait的時間
traces.txt 如下
----- pid 29533 at 2015-10-16 00:48:29 -----
Cmd line: com.android.systemui
DALVIK THREADS (54):
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x75bd5818 self=0x7f8549a000
| sysTid=29533 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f894bbe58
| state=S schedstat=( 289080040422 93461978317 904874 ) utm=20599 stm=8309 core=0 HZ=100
| stack=0x7fdffda000-0x7fdffdc000 stackSize=8MB
| held mutexes=
at com.mediatek.anrappmanager.MessageLogger.println(SourceFile:77)
Android系統中，有硬體WatchDog用於定時檢測關鍵硬體是否正常工作，類似地，在framework層有一個軟體WatchDog用於定期檢測關鍵系統服務是否發生死鎖事件。
watchdog 每過30s 檢測一次， 如果要監控的線程30s 後沒有響應，系統會mp出此進程堆棧，如果超過60s 沒有相應，會觸發watchdog，並重啟系統
10:57:23.718 579 1308 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.am.ActivityManagerService on foreground thread (android.fg), Blocked in handler on main thread (main), Blocked in handler on ActivityManager (ActivityManager)
10:57:23.725 579 1308 W Watchdog: android.fg annotated stack trace:
10:57:23.726 579 1308 W Watchdog: at com.android.server.am.ActivityManagerService.monitor(ActivityManagerService.java:26271)
10:57:23.727 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.727 579 1308 W Watchdog: at com.android.server.Watchdog DeliveryTracker.alarmTimedOut(AlarmManagerService.java:4151)
10:57:23.733 579 1308 W Watchdog: - waiting to lock <0x00aaee38> (a java.lang.Object)
......
10:57:23.736 579 1308 W Watchdog: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
10:57:23.739 579 1308 W Watchdog: ActivityManager annotated stack trace:
10:57:23.740 579 1308 W Watchdog: at com.android.server.am.ActivityStack$ActivityStackHandler.handleMessage(ActivityStack.java:405)
10:57:23.740 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.740 579 1308 W Watchdog: at android.os.Handler.dispatchMessage(Handler.java:106)
10:57:23.741 579 1308 W Watchdog: *** GOODBYE!
分析：
提示 ActivityManagerService的android.fg,main,ActivityManager 線程Block了,但logcat里只能看到
android.fg等待0x0bb47e39 鎖,main 等待0x00aaee38鎖,ActivityManager等待0x0bb47e39鎖,無法進一步分析,需要看traces.txt
Cmd line: system_server
......
"main" prio=5 tid=1 Blocked
當出現應用閃退，可以從兩個方面查看：
1、是否應用崩潰：
可以通過logcat –s AndroidRuntime DEBUG過濾日誌，查看應用奔潰的具體堆棧信息。
其中AndroidRuntime的TAG列印java層信息，DEBUG的TAG列印native層的信息。
2、是否被lowmemorykiller殺掉：
可以通過 logcat –s lowmemorykiller 過濾日誌，注意adj 0是代表前台進程。例如：
03-08 04:16:58.084 310 310 I lowmemorykiller: Killing'com.google.android.tvlauncher' (2520), uid 10007, adj 0
發生這種情況，需要mpsys meminfo 查看當前內存狀態，是否有進程內存泄漏，導致系統內存不夠，出現前台進程被殺，造成閃退。
測試過程中，經常遇到屏幕閃爍的現象，需要排除是OSD層閃爍，還是video層閃爍。
1、先通過android原生方法：screencap截圖, screenrecord 錄制視頻，這里都是截取的OSD層，查看是否有閃屏現象。
2、OSD沒有問題，就需要從更底層的顯示模塊分析，一般需要晶元廠家提供debug手段，不同晶元廠家方案不一樣。
3, 有時候輸出不穩定，hdmi/mipi信號干擾，輸出頻率異常等也會導致閃屏，這種情況需要硬體協助分析。
如果OSD層也閃爍，則需從系統和應用層面分析。如曾遇到在開機向導界面，有個應用不斷被喚起，導致走開機向導時出現連續閃灰屏的現象。
黑屏分UI黑屏，視頻播放黑屏但UI正常等，2種場景
1、screencap截屏，排查OSD層圖形是否正常，
2、如果OSD圖形正常，需要排查顯示輸出模塊是否異常。
3、電視機裡面屏顯是單獨控制，如果屏參配置錯誤會導致整改黑屏。
OSD異常，需要排查頂層activity是否黑屏，window是否有異常等.
1，排查視頻圖層或者window是否創建成功。
2，排查解碼是否有異常，不同的應用youtube,netflix,iptv解碼方式不一樣，需要具體問題具體分析。
如下，ActivityManager因為空對象引用而掛掉，導致system_server重啟
*** [FATAL EXCEPTION IN SYSTEM PROCESS: ActivityHanager [
^ava.lang.NullPointerException: Attempt to invoke virtual method 'void co®.android.internal.os.KernelSingleUidTimeReader.iBarkDataAsStale(boolean)' on a null object reference
at com.android.internal.os.BatteryStatsIiaplSConstants.(BatteryStatslnpl.java:13355)
at com.android.internal.os.BatteryStatsInplSConstants.upddteConstants(BatteryStatsImpl.java:13330)
at com.android.internal-o-batteryStatslMpl$Constants-onChange(BatteryStatsInpl-java:13316)
at android.database.Contentobserver.onChange(ContentObserver.java:145)
解決方法：修復空指針
DEBUG : pid: 296, tid: 1721, name: Binder：296_4 >>> /system/bin/surfaceflinger <<<
DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr ------
DEBUG : Abort message: 'status.cpp:149] Failed HIDL return status not checked: Status(EXTRANSACTIONFAILED):
DEBUG : r0 00000000 rl 000006b9
DEBUG ： C4 00000128 r5 000006b9
r2 00000006 r3 a5c5d620
r6 a235d60c r7 0000010c
DEAD_OB3ECT：
DEBUG : r8 00000019 r9 0000015d
DEBUG : ip a6ablbec sp a235d5f8
rlO a568f090 rll a620dce9
Ir a5be901d pc a5be0da2
/system/lib/libc.so (abort+62)
/system/lib/libbase.so (android::base::DefaultAborter(char const )+6)
backtrace:
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libbase.so (android::base::LogMessage::~LogMessage()+502)
/system/lib/libhidlbase.so (android::hardware::details::return_status::~return_status()+184)
(android::Hwc2::impl::Composer::getActiveConfig(unsigned long long, unsigned int )+56)
(HWC2::Display::getActiveConfig(std::_1::shared_ptr<HWC2：:Display::Config const>*) const+38)
(android::HWComposer::getActiveConfig(int) const+64)
(android::SurfaceFlinger::resyncToHardwareVsync(bool)+64)
可以根據backtrace來進行定位異常崩潰的地方。Android P上， backtrace使用Java上下文來顯示，省去使用addr2line來轉換的一個過程，方便調試分析問題。但是實際場景中，
有些native進程崩潰只有pc地址，而無函數信息，或者需要定位到具體的某個文件某個函數，則可藉助堆棧分析工具addr2line。
addr2line：根據堆棧定位具體函數和文件
addr2line -e libsurfaceflinger.so -f 00071a09
addr2line -e libsurfaceflinger.so -f 00071a09
_
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:1229
需注意兩點：
1、需用帶debug信息的LINK目錄裡面的so庫，機頂盒上的so庫是無法定位的：
out/target/proct/xx/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/LINKED/libsurfaceflinger.so
或者：out/target/proct/xx/symbols/system/lib/libsurfaceflinger.so
2、定位的文件，必現和機器上出現問題的版本一致，否則定位不準確
debuggerd：列印當前進程實時堆棧：debuggerd –b pid
主要可以分為以下3類
1)Data abort
Unable to handle kernel NULL pointer dereference at virtual address...
Unable to handle kernel paging request at virtual address...
Unhandled fault...at...
Unhandled prefetch abort...at...
2)BUG/BUG_ON
Oops - BUG...
例如：
Out of memory and no killable processes...
rbus timeout...
...
PS:WARN_ON只mp stacks，kernel還是正常
3)bad mode
Oops - bad mode...
日誌列印:
〃錯誤類型原因
[214.962667] 08:14:19.315 (2)-0488 Unable to handle kernel paging request at virtual address 6b6b6cl7
[214.973889] 08:14:19.326 (2)-0488 addr：6b6b6c17 pgd = d0824000
[214.980132] [6b6b6c17J •pgd=O000eO0e
〃Oopsttl誤碼序號
[214.983865] 08:14:19.336 (2)-0488 Internal error： Oops： 805 [#1] PREEMPT SMP ARM
[214.9914S3] Moles linked in: 8192eu ufsd(PO) jnl(O) fusion(O)
〃發生也錯誤的CPU序號
(215.001878] 08:14:19.354 (2)-0488 CPU： 2 PID: 488 Comm: system_server Tainted: P 4.4.3+ #113
(2)-0488 Hardware name: rtd284x
[215.011865] 08:14:19.364
〃當前PC指針 98:14:19.377 (2)-0488 PC is at mutex_unlo<k+0xc/0x38
(21S.024846] 08:14:19.383 (2)-0488 LR is at storage_pm_event+0xb4/0xe8
(21S.031026]
//Registers 08:14:19.390 (2)-0488 ：[<ceb78ffc>] Ir : [<C0542034>] psr: 200f0013
I 215.037644] sp : ccf79e38 ip : eceoeeee fp : 9b34648c
I 215.037644]
08:14:19.404 (2)-0488 rlO： 00000080 r9 ：Cl8b3864 r8 : oeeeeeoe
215.051370]
215.058692] 08:14:19.411 (2)-0488 P7 ： C1293a98 P6 ：C1293940 r5 : C1293940 r4 ：C1293a80
21S.067345]
[ 215.076014] 08:14:19.420 (2)-0488 r3 : 00000033 r2 ：00000000 ri : 000^000 re ：6b6b6c07
[ 215.085307]
08:14:19.428 (2)-0488 Flags: nzCv IRQs on FIQs on Mode SVC 32 ISA ARM Segment user
08:14:19.438 (2)-0488 Control: 10c5383d Table： 1082406a DAC： 00000055
//Process.不 ,定是該process的錯誤，只是發生錯誤時,剛好在運行該process
[215.093168]
//Stacks 08:14:19.446 (2)-0488 Process syste«i_server (pid: 488, stack limit = 0xccf78218)
(21S.101827] 08:14:19.454 (2)-0488 Stack: 0xccf79e38 (Oxccf79d7。 to 0xccf7a08Q) - par(0xcf796d4)
---[ end trace 45d55384id6a0974 ]--- Kernel panic not syncing: Fatal exception
[217.359794] 08:14:21.712 (0)-0488
解決方案: kernel異常一般找晶元原廠協助分析。
系統卡頓時，一般先分三步走：
1、查看當前系統的CPU，IO等參數，輸入top、iotop命令： （如：iotop -s io -m 9）
如果有異常飆高的進程，kill掉後會發現系統恢復正常。
之前項目上遇到過某些U盤IO性能比較差，媒體中心又在後台掃描媒體問題，導致系統各種卡頓，io wait時間比較長。
2、系統進程卡住，觸發Watchdog：ps –A |grep system_server,一般而言，system_server正常的進程號是200多，如果發現進程號變成幾千，則可能出現重啟，結合tombstone和 /data/anr下的trace文件分析重啟原因
3、當前應用出現卡頓，造成ANR。輸入logcat | grep ANR，如果有ANR列印，再去/data/anr下面查看相應進程的traces文件
有時在應用裡面操作卡頓，按鍵響應延遲，但是卻沒有生成ANR，此時如果退出該應用（如果無法退出，在抓取足夠信息的情況下，可以串口直接kill掉卡頓的應用），則一切正常，可能是應用自身實現問題，或者調用了其它介面導致（例如曾遇到應用調用了中間件、mediaplayer某些介面導致操作嚴重卡頓，按鍵響應延遲），這種情況則需應用和相應介面的實現者去排查。
系統完全卡死，一般分三種情況
1，串口無響應，大概率kernel panic，
2，串口日誌狂輸出，把系統堵塞， 優化日誌輸出，關注關閉後壓測。
3，Input系統完全堵塞，導致任何輸入都無響應。
⑧ Android開發常見異常與錯誤系列（一）
一、前言
這系列文章是自己在平時開發過程中遇到的問題。之前只是記在雲筆記上面，現在整理一下，發出來共享。
ps:像那些什麼沒有注冊Activity呀，許可權呀等最基本的就不再贅述。
二、ADB連接異常
有時我們發現，即使自己從任務管理器裡面把adb.exe給幹掉了，但還是不行，這時，你就可以嘗試以下操作：
[2014-07-30 17:09:11 - QtActivity] The connection to adb is down, and a severe error has occured.
[2014-07-30 17:09:11 - QtActivity] You must restart adb and Eclipse.
[2014-07-30 17:09:11 - QtActivity] Please ensure that adb is correctly located at 『D:\InstallFile\AndroidDevelop\ADT\sdk\platform-tools\adb.exe』 and can be executed.
adb起動失敗：
1，殺掉其它的adb.exe看，如果不行，
2，看sdk\tools路徑下面有沒有
hprof-conv.exe
如果有，則把它復制到sdk\platform_tools下
3，如果沒有，剛看sdk\platform_tools下有沒有
hprof-conv.exe
如果有，剛復制到tools下。
4，如果兩者都沒有，剛下一個
hprof-conv.exe
三、java.lang.IllegalStateException: Activity has been destroyed
這個異常在切換Fragment中比較容易出現，稍不注意就會出現如下異常：
FATAL EXCEPTION: main12-0909:20:14.689: E/AndroidRuntime(31223): java.lang.IllegalStateException: Activity has been destroyed12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1365)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)12-0909:20:14.689: E/AndroidRuntime(31223): at cn.com.topsky.community.tfd.DongTaiFragment.init(DongTaiFragment.java:209)12-0909:20:14.689: E/AndroidRuntime(31223): at cn.com.topsky.community.tfd.DongTaiFragment.onCreateView(DongTaiFragment.java:68)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.Fragment.performCreateView(Fragment.java:1500)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:927)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1104)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:682)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1467)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:440)12-0909:20:14.689: E/AndroidRuntime(31223): at android.os.Handler.handleCallback(Handler.java:605)12-0909:20:14.689: E/AndroidRuntime(31223): at android.os.Handler.dispatchMessage(Handler.java:92)12-0909:20:14.689: E/AndroidRuntime(31223): at android.os.Looper.loop(Looper.java:154)12-0909:20:14.689: E/AndroidRuntime(31223): at android.app.ActivityThread.main(ActivityThread.java:4624)12-0909:20:14.689: E/AndroidRuntime(31223): at java.lang.reflect.Method.invokeNative(Native Method)12-0909:20:14.689: E/AndroidRuntime(31223): at java.lang.reflect.Method.invoke(Method.java:511)12-0909:20:14.689: E/AndroidRuntime(31223): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:809)12-0909:20:14.689: E/AndroidRuntime(31223): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:576)12-0909:20:14.689: E/AndroidRuntime(31223): at dalvik.system.NativeStart.main(Native Method)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
經查，說這個是當前android-support-v4版本的一個bug,因為在當fragment進行到detached狀態時，它會重置它的內部狀態。
然而，它並沒有重置mChildFragmentManager.這導致在Fragment重新attach時，它(fragment)沒有重新attachm childFragmentManager，從而引發了上面的異常.
解決方案：
在每個調用getChildFragmentManager()的fragment中復寫onDetach()方法：
@OverridepublicvoidonDetach() {super.onDetach();try{Field childFragmentManager = Fragment.class.getDeclaredField("mChildFragmentManager");childFragmentManager.setAccessible(true);childFragmentManager.set(this,null);}catch(NoSuchFieldException e) {thrownewRuntimeException(e);}catch(IllegalAccessException e) {thrownewRuntimeException(e);}}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
四、java.lang.IllegalArgumentException: Illegal character in query at index
這個異常，在我們拼接請求參數時，可能會碰到，原因是裡面的特殊字元轉換異常。解決辦法如下：
url轉換問題
String url = baseUrl + 「?」 + 「name=」 + name + 「&age=」 + age;
url = url.replaceAll(「&」, 「%26」);
url = url.replaceAll(」 「, 「%20」);
解釋如下：
特殊符號替換符號
?%3F
&%26
|%124
=%3D
#%23
/%2F
+%2B
%%25
空格%20
五、eclipse連接小米2S調試程序的問題
雖然快2年沒用過eclipse了，但這個問題還是貼出來，也許正好有正在用eclipse的同學遇到了此問題：
小米Mi2S連接到eclipse上無法識別。即使開啟了調試模式，也無法識別.終於找到了一個可用的方法。
方法
用數據線連接手機和電腦。
打開手機撥號界面。
在撥號界面按 # #717717# # 自動就開啟了。
在通知欄會出現一個 Diag USB port enable。
當然，應該是需要ROOT許可權的。
這時候你的PC機會彈出安裝設備驅動。
如果不成功，多插拔幾次試試。
ok！安裝完就搞定了！這時候打開eclipse就會在Driver裡面看到你的手機了。
注意事項
在PC機上安裝新硬體向導時候可能會遭遇到缺少dll文件，比如我就遇到缺少了WinUSBCoInstaller2.dll，這個問題。這時候就要去網上找找嘍。這個東西分x64 和 x86的，注意不要搞錯了！
如果先打開eclipse，再安裝的話，可能導致eclipse掛掉，不明原因，可能是我機器配置不行。兩次均有這種狀況。所以建議先安裝後再開eclipse。
⑨ android 開發中常見的異常有哪些，如何處理
1.R.java消失或解析異常
查看res中資源文件，圖片，xml等。比如圖片文件名不能有大寫不能有空格。
搞定錯誤之後Project->clean就可以了。
2.自定義title欄。
首先要z在values->styles中定義一個style，然後在mainfest文件中設置android:theme.
最後在Activity中按照這個順序寫：
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_CUSTOM_TITLE);
setContentView(R.layout.activity_main);
getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE, R.layout.title_layout);
3.SQLite isFirst和isBeforeFirst方法的區別：
看下面一段代碼
Cursor c = queryTheCursor(type);
if(c.moveToLast())
while (!c.isBeforeFirst()) {
String tmpContent = new String();
tmpContent = c.getString(c.getColumnIndex("content"));
contents.add(tmpContent);
c.moveToPrevious();
}
c.close();
代碼的作用是逆序輸出表中的內容，第三行如果用的是isFirst（）的話就無法輸出第一行，正確做發是用isBeforeFirst（）。
4.eclipse刪除空行
在eclipse中刪除某一行就用ctrl+D快捷鍵。如果你想刪除一個文件中的所有空行呢。
可以用下面方法。
1)打開源碼編輯器
2)使用快捷鍵Ctrl+f
3)在Find輸入框中輸入：^\s*\n
4)Replace With輸入框的值為空
5)在【Options】選中的"Regular expressions"
6)點擊【Replace All】按鈕。