android p(什么是AndroidP)
一、android p是什么版本
android p指的是安卓9.0版本。在开发时，安卓9.0戴好为android p，p是pistachio ice cream的简称，也可以理解为pie，在正式发布后，谷歌将这款系统称为安卓9.0，它的上市时间是2018年8月，增加了许多新的功能，比如全面屏手势才做、神经网络、自适应功能等等。
android p是什么版本
1、android p指安卓9.0版本，在2018年1月开始出现，代号为pie，也就是pistachio ice cream的简称，中文里面叫做开心果冰淇淋，在2018年的8月7日，谷歌正式发布这个系统，它的正式明明就是android p，也叫作派。
2、该系统是安卓变化非常大的一个版本，因为它添加了许多新的功能，与以前系统最大的差别就是它支持刘海屏的操作，屏幕内容的显示、操作以及使用等等都做了全新的变化，并且优化的电池的续航能力，以及多屏操作。
3、android p的特点功能有：多摄像头的更多画面、通知栏的多种通知、神经网络、自适应功能、全面屏以及折叠屏支持等等，它还有全局黑夜模式，并加入原生的天气支持和通话录音，操作上更人性化和简洁方便。
4、在不少手机上都曾测试过android p，比如索尼Xperia xz2、一加6、小米mix2s等等，但在安卓9.0正式版发布后，大部分的安卓手机都开始预装这个系统，而且以前的旧手机也可以升级到这个系统，国产手机由于定制化的ui，虽然各家厂商使用操作系统有差别，但也都是在安卓系统上开发的。
5、在android p系统里，仪表功能、黑暗模式、电池管理功能是最受大家欢迎和认可的，可以查看手机解锁次数、使用时间、各项APP的使用时间，并且有emojis表情，如果手机是支持这个系统的，最好是升级到安卓9.0以上的版本。
二、问答:Android P都更新了哪些功能
Android P的新功能特性集中在了UI、通知体验、室内定位、图像存储几个方面，解决了之前一直存在的痛点。例如WiFi RTT一定程度上弥补了蜂窝网络在室内环境下的定位问题，HEIC图像格式则重点解决了存储容量问题。同时，Android P也在通知丰富度及操作便捷性等功能方面有所增强和提升。
一、WiFi RTT功能——复杂地形精确导航
WiFi RTT功能是Android P新引入的一个功能，从原理上来说与蜂窝网络的定位原理一致，但这个功能极大的弥补了蜂窝网络在室内定位的短板，WiFi RTT将能够在室内提供高精度的定位，这是蜂窝网络很难做到的。
WiFi RTT是全新的功能，在android.net.wifi包下增加了rtt包，用于存放WiFi RTT相关类和接口。
WiFi RTT的API以WifiRttManager为核心，借助AP热点或WiFi，利用RTT原理完成测距，通过三个以上的测距点就能够准确地定位到设备所在位置。
WiFiRTTManager提供了测距接口，是一个异步测距操作，根据官方文档（）说明，其测距接口如下：
void startRanging(RangingRequest request, RangingResultCallback callback, Handler handler);
注：SDK Platforms Android P Preview Revision 1的相关接口定义与此不同，但实际的官方镜像中接口与此一致，开发者需要更新最新的Android P Preview Revision 2，此版本中Google已经修正该接口。
接口中，RangingRequest通过RangingRequest.Builder构建，RangingRequest.Builder构建出RangingRequest所需要的参数可以通过WiFiManager等系统服务获取到相关的内容，如List<ScanResult> scanResults= wifiManager.getScanResults();
以下提供一个简单的测试Demo，以供参考：
private WifiRttManager wifiRttManager;
private WifiManager wifiManager;
@Override
protected void onCreate(Bundle savedInstanceState){
//......
if(getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI_RTT)){
Object service= this.getApplicationContext().getSystemService(Context.WIFI_RTT_RANGING_SERVICE);
if(service instanceof WifiRttManager){
wifiRttManager=(WifiRttManager) service;
Log.i(TAG,"Get WifiRttManager Succ.");
}
wifiManager=(WifiManager) this.getApplicationContext().getSystemService(Context.WIFI_SERVICE);
IntentFilter wifiFileter= new IntentFilter();
wifiFileter.addAction(WifiManager.NETWORK_STATE_CHANGED_ACTION);
wifiFileter.addAction(WifiManager.WIFI_STATE_CHANGED_ACTION);
wifiFileter.addAction(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION);
registerReceiver(new WifiChangeReceiver(), wifiFileter);
}
//......
｝
private void startScanAPs(){
wifiManager.setWifiEnabled(true);
wifiManager.startScan();
}
class WifiChangeReceiver extends BroadcastReceiver{
@RequiresApi(api= 28)
@Override
public void onReceive(Context context, Intent intent){
if(intent.getAction().equals(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION)){
List<ScanResult> scanResults= wifiManager.getScanResults();
Log.i(TAG,"Wifi Scan size:"+ scanResults.size());
for(ScanResult scanResult: scanResults){
Log.i(TAG, scanResult.toString());
RangingRequest.Builder builder= new RangingRequest.Builder();
builder.addAccessPoint(scanResult);
wifiRttManager.startRanging(builder.build(), new RangingResultCallback(){
@SuppressLint("Override")
@Override
public void onRangingFailure(int i){
// TODO
}
@SuppressLint("Override")
@Override
public void onRangingResults(List<RangingResult> list){
// TODO get result from list
for(RangingResult result: list){
Log.i(TAG, result.toString());
}
}
}, new Handler());
}
}
}
}
使用WiFi RTT时，需要在AndroidManifest.xml中增加如下声明：
<uses-feature android:name="android.hardware.wifi.rtt"/>
通过上面的简单代码，就能够实现WiFi RTT的功能。
WiFi RTT功能适用于复杂地形的大型室内外场所，如商场、娱乐场所、大型休闲、游乐场等等，提供场所内的局部区域精确化导航等功能。相信在很快的时间内，就能够在各大地图应用内体验到这项便利功能，对于路痴、地图盲的伙伴们将是极大的福音。
二、显示剪切——支持刘海屏
随着iPhone X的推出，“刘海屏”达到了空前的高潮。Android P里提供了对异形屏幕的UI适配兼容方案，通过DisplayCutout类提供的相关接口，能够获取到屏幕中Cutout区域的信息。
借助DisplayCutout，可以获取到如下信息：
DisplayCutout displayCutout= view.getRootWindowInsets().getDisplayCutout();
if(displayCutout!= null){
Region bounds= displayCutout.getBounds();
Log.d(TAG, String.format("Bounds:%s", bounds.toString()));
int top= displayCutout.getSafeInsetTop();
int bottom= displayCutout.getSafeInsetBottom();
int left= displayCutout.getSafeInsetLeft();
int right= displayCutout.getSafeInsetRight();
Log.d(TAG, String.format("Cutout edge:[left:%d, top:%d,right:%d, bottom:%d]", left, top, right, bottom));
}
public Region getBounds()能够获取到Cutout区域的所有信息，Region就是Cutout区域。
public int getSafeInsetTop()
public int getSafeInsetBottom()
public int getSafeInsetLeft()
public int getSafeInsetRight()
以上四个接口，可以获取到去除Cutout区域后的安全区域边界值。
通过上述数据，开发者能够精准的控制UI的绘制，避免将UI内容绘制到Cutout区域造成UI显示异常。
Android机器里，刘海屏目前还是极为罕见的Google为了方便开发者调试，在Android P Preview镜像中，特别提供了Cutout的支持，具体打开方式可以参考Google提供的特性说明文档cutout小节内容。
cutout小节：
如图所示，笔者使用手头的Pixel 2 XL体验了Android P的Cutout设置。
三、通知优化——操作更多样，内容更丰富
Android P在通知内容的丰富度和操作上做了优化。
最近的版本中，Android系统的通知管理方面一直优化升级，Android O提供了更细粒度的Channel功能，通知栏推送时需要指定NotificationChannel，用户可以对通知的Channel选择，只允许感兴趣的Channel推送的通知显示。通过通道设置、免打扰优化等方式，极大增强了消息体验。
增强消息体验
Android P继续改进和增强消息通知[v1]。早在Android 7.0时，就提供了在通知中直接应答和输入，Android P对这一功能做了更多的增强。
Android P的通知中支持图像内容，可以通过setData()方法，给出消息的图像内容，在通知上展示给用户。
Android P同样简化了通知的配置形式。Android P中增加了Notification.Person类，用于区分同一个对话的参与者信息，如参与者的头像、URI等。根据官方说明，Android P中，通知消息的其他一些API，也使用Person替代之前的CharSequence。
简单的体验下新的API的开发：
NotificationChannel channel= new NotificationChannel("WtTestChannel",
"WtTestChannel", NotificationManager.IMPORTANCE_DEFAULT);
channel.enableLights(true);// luncher icon right corner's point
channel.setLightColor(Color.RED);// read point
channel.setShowBadge(true);// whether show this channel notification on long press icon
Notification.Builder builder=
new Notification.Builder(MainActivity.this,
"WtTestChannel");
Notification.Person p= new Notification.Person();
p.setName("WeTest");
p.setUri(""+
"ui/1.2.0/pc/static/image/newLogo-16042.png");
Notification.MessagingStyle messageStyle= new Notification.MessagingStyle(p);
Notification.MessagingStyle.Message message=
new Notification.MessagingStyle.Message("WeTestMessage", 2000, p);
//show image
Uri image= Uri.parse(
"");
message.setData("image/png", image);
messageStyle.addMessage(message);
builder.setStyle(messageStyle);
builder.setSmallIcon(R.mipmap.ic_launcher);
Notification notification= builder.build();
NotificationManager notifyManager=
(NotificationManager) getSystemService(
MainActivity.this.getApplicationContext().NOTIFICATION_SERVICE);
notifyManager.createNotificationChannel(channel);
notifyManager.notify("WeTest", 1, notification);
通道设置、广播和免打扰优化
Android P中，重点做了内容丰富上的工作，同时也对Channel的设置方面做了一些简化处理。
Android O版本里，首次推出了NotificationChannel，开发者需要配置相应的Channel，才能够推送通知给用户。用户能够更加细粒度[v1]的针对App的Channel选择，而不是禁止App的所有通知内容。
而在Android P中，对通知的管理做了进一步的优化，包括可以屏蔽通道组、提供新的广播类型和新的免打扰优先级。
屏蔽通道组：用户可以在通知设置中屏蔽App的整个通道组。开发者可以通过isBlocked()来判断某个通道组是否被屏蔽了，并根据结果，不向已经被屏蔽的通道组发送任何通知。另外，开发者可以在App中使用新接口getNotificationChannelGroup()来查询当前的通道组设置。
新的广播类型：新广播类型是针对通道和通道组的功能增加的“通道(组)屏蔽状态变化”广播。开发者App中可以对所拥有的通道(组)接收广播，并根据具体广播内容作出动作。开发者可以通过NotificationManager，查看广播相关的具体信息。针对广播的动作可以通过Broadcasts查看具体的方法和信息。
免打扰优先级：NotificationManager.Policy增加了两个新的优先级常量，PRIORITY_CATEGORY_ALARMS(警告优先)，PRIORITY_CATEGORY_MEDIA_SYSTEM_OTHER(媒体、系统和游戏声音优先)。
四、支持多摄像机和相机共享
近一段时间，双摄、多摄等机型纷纷面世。双摄及多摄提供了单摄像头所无法完成的能力，如无缝缩放、散景和立体视觉。Android P在这方面也提供了系统级的API支持。
Android P提供了系统API，支持从两个或者多个物理摄像头同步获取数据流。此前OEM厂商提供的双摄设备多是厂商自行定制系统实现，此时Android P推出了API，从系统层面上制定了API规范。
新的API提供了在不同相机之间切换逻辑数据流或混合数据流的调用能力。在捕捉延迟方面，提供新的会话参数，降低初始捕捉延迟。同时，提供相机共享能力，以解决在多种使用相机的场景下重复停止、开启相机流。闪光灯方面，Android P增加基于显示的闪光灯支持。光学防抖方面，Android P向开发者提供OIS时间戳，用于图像稳定性优化以及其他特效使用。
此外，Android P还支持外部USB/UVC相机，可以使用更强大的外置摄像头模组。
五、支持图像媒体后期处理
Android P引入了新的ImageDecoder，该类除了支持对各种图片格式的解码、缩放、裁剪之外，其强大之处在于支持对解码后的图像做后期处理（post-process)，使用该功能可以添加复杂的自定义特效，比如圆角，或是将图片放在圆形像框中。编写后期处理回调函数，你可以添加任何绘图指令实现需要的效果。
此外，Android P原生支持GIF和WebP格式的动图，新增了AnimatedImageDrawable类，并被新增的解码器类ImageDecoder直接支持，用法跟矢量动画类AnimatedVectorDrawable类似，实现方式也类似，通过新增渲染线程和工作线程，不需要在UI线程处理动图更新，可以说是无痛使用，非常省心。
下面通过编写代码，显示一张gif图，并利用后期处理机制，在图像中间绘制一个绿色的实心圆。
final ImageView image=(ImageView) findViewById(R.id.image);
File gifFile= new File("/data/local/tmp/test.gif");
if(!gifFile.exists()){
Log.d(TAG,"gifFile is not exsited!");
return;
}
ImageDecoder.Source source= ImageDecoder.createSource(gifFile);
try{
d= ImageDecoder.decodeDrawable(source, new ImageDecoder.OnHeaderDecodedListener(){
@Override
public void onHeaderDecoded(ImageDecoder imageDecoder, final ImageDecoder.ImageInfo imageInfo, ImageDecoder.Source source){
imageDecoder.setPostProcessor(new PostProcessor(){
@Override
public int onPostProcess(Canvas canvas){
int w= imageInfo.getSize().getWidth();
int h= imageInfo.getSize().getHeight();
Paint paint= new Paint();
paint.setAntiAlias(true);
paint.setColor(Color.GREEN);
canvas.drawCircle(w/2, h/2, h/4, new Paint(paint));
return 0;
}
});
}
});
image.setVisibility(View.VISIBLE);
image.setImageDrawable(d);
} catch(IOException e){
Log.d(TAG, e.toString());
}
Button button=(Button) findViewById(R.id.buttonText);
button.setOnClickListener(new View.OnClickListener(){
@Override
public void onClick(View view){
if(d!= null&& d instanceof AnimatedImageDrawable){
AnimatedImageDrawable ad=(AnimatedImageDrawable) d;
if(ad.isRunning()){
Log.d(TAG,"stop running");
ad.stop();
} else{
Log.d(TAG,"start running");
ad.start();
}
}
}
});
六、支持HDR VP9和HEIF
Android P内置了对HDR VP9和HEIF(heic)图像编码的支持。HEIF是苹果在iOS11推出的一种高效压缩格式，目前在IphoneX、Iphone 8、IPhone 8P上已经支持。该格式的压缩率更高，但是编码该格式需要硬件的支持，解码并不需要。最新的支持库中的HeifWriter支持从YUV字节缓冲区、Surface或是Bitmap类转换为HEIF格式的静态图像。
Android P新引入了MediaPlayer2，支持DataSourceDesc创建的播放列表。
功能优化提升一览
一、神经网络API 1.1
在前不久发布的Android 8.1(API level 27)上，Google首次在Android平台上推出了神经网络API，这意味着我们的Android机器智能化水平又提高了一大步。而本次Android P，进一步丰富了神经网络的支持，不仅对之前的相关API进行了优化，并且提供了9个新的操作，为具体的数据操作方面提供了更深入的支持。
二、改进表单自动填充
Android 8.0（API等级26）中引入了自动填充框架，这使得在应用中填写表单变得更加容易。 Android P引入了自动填充服务并实现了多项改进，得以在填写表单时进一步增强用户体验。
三、安全增强
Android P引入了许多新的安全功能，包括统一的指纹验证对话框和敏感交易的高确信度的用户确认。应用程序内的指纹认证UI也将会更加一致。
统一的指纹验证对话框
如果第三方APP想要使用指纹，Android系统框架为应用提供了指纹认证对话框，该功能可以提供统一的外观和使用体验，用户使用起来更放心。如果您的程序还在使用FingerprintManager，现在改用FingerprintDialog替代吧，系统来提供对话框显示。对了，在使用FingerprintDialog之前，别忘了调用hasSystemFeature()方法检查手机设备是否支持指纹。
敏感交易的高确信度的用户确认
Android P系统提供了受保护的确认API，借助这组全新的API，应用可以使用ConfirmationDialog对话框向用户提示，请求用户批准一条简短的声明，该声明允许应用提醒用户，即将完成一笔敏感交易，例如支付。
如果用户接受声明，应用将会收到一条key-hash的消息认证码（HMAC)，该签名由TEE产生，以保护用于输入和认证对话框的显示。该签名表示用于已经看到了声明并同意了。
硬件安全模块
Android P还提供了StrongBox Keymaster（强力沙盒秘钥大师），一个存储在硬件安全模块的具体实现。在这个硬件安全模块中有自己的CPU、安全存储空间，真随机数生成器，以及额外的机制抵御应用被篡改或是未授权应用的恶意加载。当检查存储在StrongBox Keymaster中的密钥时，系统通过可信执行环境（TEE）确认密钥的完整性。为了降低能耗，StrongBox支持了一组算法和不同长度的秘钥：
●RSA 2048
●AES 128 and 256
●ECDSA P-256
●HMAC-SHA256(支持8字节到64字节任意秘钥长度)
●Triple DES 168
需要说明的是，这个机制需要硬件支持。
安全秘钥导入KeyStore
使用新的ASN.1编码的秘钥格式添加导入秘钥到Keystore，Android P提供了额外的密码解密安全能力。之后KeyMaster就可以解密KeyStore存储的秘钥，这种工作方式使得秘钥明文永远不会出现在设备内存中。这项特性要求设备支持Keymaster 4。
四、支持客户端侧Android备份加密
Android P支持使用客户端密钥对Android备份进行加密。这项隐私措施，需要设备的PIN、图案密码或标准密码才能从用户设备备份的数据中恢复数据。
五、Accessibility优化
为了使App使用更便捷，Android在多个方面为开发者提供了易用性的优化。
1、Navigation semantics
Android P在App的场景切换和操作上为开发者提供了很多的优化点。
2、Accessibility pane titles
Android P中对Section提供了新的机制，被称为accessibility pane titles， Accessibility services能够接收这些标题的变化，使得能够对一些变化提供更加细粒度的信息。
指定Section的标题，可以通过android:accessibilityPaneTitle新属性来设置，同样运行时可以通过setAccessibilityPaneTitle()来设置标题。
3、顶部栏导航
Android P提供了新的顶部栏导航机制，通过设置View实例的android:accessibilityHeading属性为true,来显示逻辑标题。通过这些标题，用户就可以从一个标题导航到下一个标题，
4、群组导航和输出
针对屏幕阅读器，Android P对View提供了新的属性android:screenReaderFocusable代替原有的android:focusable来做标记，来解决在一些场景下为了使屏幕阅读器工作而设置View为可获取焦点的操作。这时，屏幕阅读器需要同时关注android:screenReaderFocusable和android:focusable设置为ture的View。
5、便捷操作
tooltips交互
Android P中，可以使用getTooltipText()去读取tooltips的文本内容。使用新的ACTION_SHOW_TOOLTIP和ACTION_HIDE_TOOLTIP控制View显示或者隐藏tooltips。
新全局交互
Android P在AccessibilityService类中提供了两个全新的操作。开发者的Service可以通过GLOBAL_ACTION_LOCK_SCREEN帮助用户锁屏，通过GLOBAL_ACTION_TAKE_SCREENSHOT帮助用户完成屏幕截图。
窗体改变的一些细节
Android P优化了在App多窗体同步发生变化时的更新内容获取。当出现TYPE_WINDOWS_CHANGED时，开发者可以通过getWindowChanges()API获取窗体变化情况。
当多窗体发生改变时，每个窗体都会发出自己的事件，开发者可以通过getSource()获取到事件窗体的根View。
如果你的App为View定义了accessibility pane titles，UI更新时你的Service就能够识别到相应的改动。当出现TYPE_WINDOW_STATE_CHANGED事件时，使用新方法 getContentChangeTypes()返回的类型，就能够获取到当前窗体的变化情况。例如，现在就能够通过上述的机制，检测到一个[v1]窗格是否有了新标题，或者一个窗格的消失。
六、新的Rotation方案
旋转屏幕，是一些游戏、视频等场景必要的操作，但有一些场景，用户旋转屏幕并不是为了让应用显示从竖屏变成横屏或反过来。为了避免这种误操作，Android P提供了新的机制，开发者可以指定屏幕不随重力感应旋转，而是用户通过一个单独的按钮自行控制屏幕显示转向。
三、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后没有响应，系统会dump出此进程堆栈，如果超过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
发生这种情况，需要dumpsys 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.upddteTrackCpuTiinesByProcStdteLocked(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
_ZN7android14SurfaceFlinger12waitForEventEv
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:1229
需注意两点：
1、需用带debug信息的LINK目录里面的so库，机顶盒上的so库是无法定位的：
out/target/product/xx/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/LINKED/libsurfaceflinger.so
或者：out/target/product/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只dump 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] Modules 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系统完全堵塞，导致任何输入都无响应。