android文件分析

① Android系统文件夹结构详细解析！

\\system\\app
这个里面主要存放的是常规下载的应用程序，可以看到都是以APK格式结尾的文件。在这个文件夹下的程序为系统默认的组件，自己安装的软件将不会出现在这里，而是\\data\\文件夹中。下面是详细的介绍:
\\system\\app\\AlarmClock.apk 闹钟
\\system\\app\\AlarmClock.odex
\\system\\app\\Browser.apk 浏览器
\\system\\app\\Browser.odex
\\system\\app\\Bugreport.apk Bug报告
\\system\\app\\Bugreport.odex
\\system\\app\\Calculator.apk 计算器
\\system\\app\\Calculator.odex
\\system\\app\\Calendar.apk 日历
\\system\\app\\Calendar.odex
\\system\\app\\CalendarProvider.apk 日历提供
\\system\\app\\CalendarProvider.odex
\\system\\app\\Camera.apk 照相机
\\system\\app\\Camera.odex
\\system\\app\\com.amazon.mp3.apk 亚马逊音乐
\\system\\app\\Contacts.apk 联系人
\\system\\app\\Contacts.odex
\\system\\app\\DownloadProvider.apk 下载提供
\\system\\app\\DownloadProvider.odex
\\system\\app\\DrmProvider.apk DRM数字版权提供
\\system\\app\\DrmProvider.odex
\\system\\app\\Email.apk 电子邮件客户端
\\system\\app\\Email.odex
\\system\\app\\FieldTest.apk 测试程序
\\system\\app\\FieldTest.odex
\\system\\app\\GDataFeedsProvider.apk GoogleData提供
\\system\\app\\GDataFeedsProvider.odex
\\system\\app\\Gmail.apk Gmail电子邮件
\\system\\app\\Gmail.odex
\\system\\app\\GmailProvider.apk Gmail提供
\\system\\app\\GmailProvider.odex
\\system\\app\\GoogleApps.apk 谷歌程序包
\\system\\app\\GoogleApps.odex
\\system\\app\\GoogleSearch.apk 搜索工具
\\system\\app\\GoogleSearch.odex
\\system\\app\\gtalkservice.apk GTalk服务
\\system\\app\\gtalkservice.odex
\\system\\app\\HTMLViewer.apk HTML查看器
\\system\\app\\HTMLViewer.odex
\\system\\app\\IM.apk 即使通讯组件包含MSN、yahoo通
\\system\\app\\ImCredentialProvider.apk
\\system\\app\\ImProvider.apk
\\system\\app\\ImProvider.odex
\\system\\app\\Launcher.apk 启动加载器
\\system\\app\\Launcher.odex
\\system\\app\\Maps.apk 电子地图
\\system\\app\\Maps.odex
\\system\\app\\MediaProvider.apk 多媒体播放提供
\\system\\app\\MediaProvider.odex
\\system\\app\\Mms.apk 短信、彩信
\\system\\app\\Mms.odex
\\system\\app\\Music.apk 音乐播放器
\\system\\app\\Music.odex
\\system\\app\\MyFaves.apk T-Mobile MyFaves程序
\\system\\app\\MyFaves.odex
\\system\\app\\PackageInstaller.apk apk安装程序
\\system\\app\\PackageInstaller.odex
\\system\\app\\Phone.apk 电话拨号器
\\system\\app\\Phone.odex
\\system\\app\\Settings.apk 系统设置
\\system\\app\\Settings.odex
\\system\\app\\SettingsProvider.apk 设置提供
\\system\\app\\SettingsProvider.odex
\\system\\app\\SetupWizard.apk 设置向导
\\system\\app\\SetupWizard.odex
\\system\\app\\SoundRecorder.apk 录音工具
\\system\\app\\SoundRecorder.odex
\\system\\app\\Street.apk 街景地图
\\system\\app\\Street.odex
\\system\\app\\Sync.apk 同步程序
\\system\\app\\Sync.odex
\\system\\app\\Talk.apk 语音程序
\\system\\app\\Talk.odex
\\system\\app\\TelephonyProvider.apk 电话提供
\\system\\app\\TelephonyProvider.odex
\\system\\app\\Updater.apk 更新程序
\\system\\app\\Updater.odex
\\system\\app\\Vending.apk 制造商信息
\\system\\app\\Vending.odex
\\system\\app\\VoiceDialer.apk 语音拨号器
\\system\\app\\VoiceDialer.odex
\\system\\app\\YouTube.apk Youtube视频
\\system\\app\\YouTube.odex

\\system\\bin
这个目录下的文件都是系统的本地程序，从bin文件夹名称可以看出是binary二进制的程序，里面主要是linux系统自带的组件，Android手机网就主要文件做下简单的分析介绍：
\\system\\bin\\akmd
\\system\\bin\\am
\\system\\bin\\app_process 系统进程
\\system\\bin\\dalvikvm Dalvik虚拟机宿主
\\system\\bin\\dbus-daemon 系统BUS总线监控
\\system\\bin\\debuggerd 调试器
\\system\\bin\\debug_tool 调试工具
\\system\\bin\\dexopt DEX选项
\\system\\bin\\dhcpcd DHCP服务器
\\system\\bin\\mpstate 状态抓取器
\\system\\bin\\mpsys 系统抓取器
\\system\\bin\\dvz
\\system\\bin\\fillup
\\system\\bin\\flash_image 闪存映像
\\system\\bin\\hciattach
\\system\\bin\\hcid HCID内核
\\system\\bin\\hostapd
\\system\\bin\\hostapd_cli
\\system\\bin\\htclogkernel
\\system\\bin\\input
\\system\\bin\\installd
\\system\\bin\\itr
\\system\\bin\\linker
\\system\\bin\\logcat Logcat日志打印
\\system\\bin\\logwrapper
\\system\\bin\\mediaserver
\\system\\bin\\monkey
\\system\\bin\\mountd 存储挂载器
\\system\\bin\\netcfg 网络设置
\\system\\bin\\ping Ping程序
\\system\\bin\\playmp3 MP3播放器
\\system\\bin\\pm 包管理器
\\system\\bin\\qemud QEMU虚拟机
\\system\\bin\\radiooptions 无线选项
\\system\\bin\\rild RIL组件
\\system\\bin\\sdptool
\\system\\bin\\stil
\\system\\bin\\service
\\system\\bin\\servicemanager 服务管理器
\\system\\bin\\sh
\\system\\bin\\ssltest SSL测试
\\system\\bin\\surfaceflinger 触摸感应驱动
\\system\\bin\\svc 服务
\\system\\bin\\system_server
\\system\\bin\\telnetd Telnet组件
\\system\\bin\\toolbox
\\system\\bin\\wlan_loader
\\system\\bin\\wpa_cli
\\system\\bin\\wpa_supplicant

\\system\\etc
从文件夹名称来看保存的都是系统的配置文件，比如APN接入点设置等核心配置。
\\system\\etc\\apns-conf.xml APN接入点配置文件
\\system\\etc\\AudioFilter.csv 音频过滤器配置文件
\\system\\etc\\AudioPara4.csv
\\system\\etc\\bookmarks.xml 书签数据库
\\system\\etc\\dbus.conf 总线监视配置文件
\\system\\etc\\dhcpcd
\\system\\etc\\event-log-tags
\\system\\etc\\favorites.xml 收藏夹
\\system\\etc\\firmware 固件信息
\\system\\etc\\gps.conf GPS设置文件
\\system\\etc\\hcid.conf内核HCID配置文件
\\system\\etc\\hosts 网络DNS缓存
\\system\\etc\\init.goldfish.sh
\\system\\etc\\location 定位相关
\\system\\etc\\mountd.conf 存储挂载配置文件
\\system\\etc\\NOTICE.html 提示网页
\\system\\etc\\permissions.xml 权限许可
\\system\\etc\\pvplayer.conf
\\system\\etc\\security
\\system\\etc\\wifi WLAN相关组件
\\system\\etc\\dhcpcd\\dhcpcd-hooks
\\system\\etc\\dhcpcd\\dhcpcd-run-hooks
\\system\\etc\\dhcpcd\\dhcpcd.conf
\\system\\etc\\dhcpcd\\dhcpcd-hooks\\01-test
\\system\\etc\\dhcpcd\\dhcpcd-hooks\\20-dns.conf
\\system\\etc\\dhcpcd\\dhcpcd-hooks\\95-configured
\\system\\etc\\firmware\\brf6300.bin
\\system\\etc\\location\\gps
\\system\\etc\\location\\gps\\location 定位相关
\\system\\etc\\location\\gps\\nmea GPS数据解析
\\system\\etc\\location\\gps\\properties
\\system\\etc\\security\\cacerts.bks
\\system\\etc\\security\\otacerts.zip OTA下载验证
\\system\\etc\\wifi\\Fw1251r1c.bin
\\system\\etc\\wifi\\tiwlan.ini
\\system\\etc\\wifi\\wpa_supplicant.conf WPA验证组件

\\system\\fonts
字体文件夹，除了标准字体和粗体、斜体外可以看到文件体积最大的可能是中文字库，或一些unicode字库，从T-Mobile G1上可以清楚的看到显示简体中文正常，其中DroidSansFallback.ttf文件大小
\\system\\fonts\\DroidSans-Bold.ttf
\\system\\fonts\\DroidSans.ttf
\\system\\fonts\\DroidSansFallback.ttf
\\system\\fonts\\DroidSansMono.ttf
\\system\\fonts\\DroidSerif-Bold.ttf
\\system\\fonts\\DroidSerif-BoldItalic.ttf
\\system\\fonts\\DroidSerif-Italic.ttf
\\system\\fonts\\DroidSerif-Regular.ttf

\\system\\framework
framework主要是一些核心的文件，从后缀名为jar可以看出是是系统平台框架。
\\system\\framework\\am.jar
\\system\\framework\\am.odex
\\system\\framework\\android.awt.jar AWT库
\\system\\framework\\android.awt.odex
\\system\\framework\\android.policy.jar
\\system\\framework\\android.policy.odex
\\system\\framework\\android.test.runner.jar
\\system\\framework\\android.test.runner.odex
\\system\\framework\\com.google.android.gtalkservice.jar GTalk服务
\\system\\framework\\com.google.android.gtalkservice.odex
\\system\\framework\\com.google.android.maps.jar 电子地图库
\\system\\framework\\com.google.android.maps.odex
\\system\\framework\\core.jar 核心库，启动桌面时首先加载这个
\\system\\framework\\core.odex
\\system\\framework\\ext.jar
\\system\\framework\\ext.odex
\\system\\framework\\framework-res.apk
\\system\\framework\\framework-tests.jar
\\system\\framework\\framework-tests.odex
\\system\\framework\\framework.jar
\\system\\framework\\framework.odex
\\system\\framework\\input.jar 输入库
\\system\\framework\\input.odex
\\system\\framework\\itr.jar
\\system\\framework\\itr.odex
\\system\\framework\\monkey.jar
\\system\\framework\\monkey.odex
\\system\\framework\\pm.jar 包管理库
\\system\\framework\\pm.odex
\\system\\framework\\services.jar
\\system\\framework\\services.odex
\\system\\framework\\ssltest.jar
\\system\\framework\\ssltest.odex
\\system\\framework\\svc.jar 系统服务
\\system\\framework\\svc.odex

\\system\\lib
lib目录中存放的主要是系统底层库，如平台运行时库。
\\system\\lib\\libaes.so
\\system\\lib\\libagl.so
\\system\\lib\\libandroid_runtime.so Android运行时库
\\system\\lib\\libandroid_servers.so 系统服务组件
\\system\\lib\\libaudio.so 音频处理
\\system\\lib\\libaudioeq.so EQ均衡器
\\system\\lib\\libaudioflinger.so 音频过滤器
\\system\\lib\\libbluetooth.so 蓝牙组件
\\system\\lib\\libc.so
\\system\\lib\\libcamera.so 超相机组件
\\system\\lib\\libcameraservice.so
\\system\\lib\\libcorecg.so
\\system\\lib\\libcrypto.so 加密组件
\\system\\lib\\libctest.so
\\system\\lib\\libcutils.so
\\system\\lib\\libdbus.so
\\system\\lib\\libdl.so
\\system\\lib\\libdrm1.so DRM解析库
\\system\\lib\\libdrm1_jni.so
\\system\\lib\\libdvm.so
\\system\\lib\\libexif.so
\\system\\lib\\libexpat.so
\\system\\lib\\libFFTEm.so
\\system\\lib\\libGLES_CM.so
\\system\\lib\\libgps.so
\\system\\lib\\libhardware.so
\\system\\lib\\libhgl.so
\\system\\lib\\libhtc_ril.so
\\system\\lib\\libicudata.so
\\system\\lib\\libicui18n.so
\\system\\lib\\libicuuc.so
\\system\\lib\\liblog.so
\\system\\lib\\libm.so
\\system\\lib\\libmedia.so
\\system\\lib\\libmediaplayerservice.so
\\system\\lib\\libmedia_jni.so
\\system\\lib\\libnativehelper.so
\\system\\lib\\libnetutils.so
\\system\\lib\\libOmxCore.so
\\system\\lib\\libOmxH264Dec.so
\\system\\lib\\libpixelflinger.so
\\system\\lib\\libpvasf.so
\\system\\lib\\libpvasfreg.so
\\system\\lib\\libpvauthor.so
\\system\\lib\\libpvcommon.so
\\system\\lib\\libpvdownload.so
\\system\\lib\\libpvdownloadreg.so
\\system\\lib\\libpvmp4.so
\\system\\lib\\libpvmp4reg.so
\\system\\lib\\libpvnet_support.so
\\system\\lib\\libpvplayer.so
\\system\\lib\\libpvrtsp.so
\\system\\lib\\libpvrtspreg.so
\\system\\lib\\libqcamera.so
\\system\\lib\\libreference-ril.so
\\system\\lib\\libril.so
\\system\\lib\\librpc.so
\\system\\lib\\libsgl.so
\\system\\lib\\libsonivox.so
\\system\\lib\\libsoundpool.so
\\system\\lib\\libsqlite.so
\\system\\lib\\libssl.so
\\system\\lib\\libstdc++.so
\\system\\lib\\libsurfaceflinger.so
\\system\\lib\\libsystem_server.so
\\system\\lib\\libthread_db.so
\\system\\lib\\libUAPI_jni.so
\\system\\lib\\libui.so
\\system\\lib\\libutils.so
\\system\\lib\\libvorbisidec.so
\\system\\lib\\libwbxml.so
\\system\\lib\\libwbxml_jni.so
\\system\\lib\\libwebcore.so
\\system\\lib\\libwpa_client.so
\\system\\lib\\libxml2wbxml.so
\\system\\lib\\libz.so
\\system\\lib\\moles
\\system\\lib\\moles\\wlan.ko

② android中怎么解析复杂的xml文件

本文主要讲解Android开发中如何对XML文件的解析，由于XML文件具有与平台无关，广泛应用于数据通信中，因此解析XML文件就显得很有意义。Android对XML文件解析的方法主要有3种。 通常有三种方式:DOM、SAX和PULL，下面就分别针对这三种方式来进行讨论。

文件内容如下所示：
那么就是要对此XML文件做解析。下面我们就分别用DOM,SAX和PULL三种方式，分别对此XML文件做解析。

DOM方式

DOM方式解析xml是先把xml文档都读到内存中，然后再用DOM API来访问树形结构，并获取数据。由DOM解析的方式可以知道，如果XML文件很大的时候，处理效率就会变得比较低，这也是DOM方式的一个缺点。
现在我们来解析上文中提到的有关天气预报信息相关的xml文件。什么是解析呢？说的通俗一点，就是将这个带标签的XML文件识别出来，并抽取一些相关的，对我们有用的信息来给我们使用。那在这个文件里，时间，天气，温度，以及图标对我们来说是需要得到的。我们要对其做解析。
解析的具体思路是：
1. 将XML文件加载进来。
2. 获取文档的根节点
3. 获取文档根节点中所有子节点的列表
4. 获取子节点列表中需要读取的节点信息
根据这4个步骤，我们进行开发：
首先就是如何加载XML文件，假设此文件来源于网络。

SAX方式

SAX是Simple API for XML的缩写。是一个包也可以看成是一些接口。
相比于DOM而言SAX是一种速度更快，更有效，占用内存更少的解析XML文件的方法。它是逐行扫描，可以做到边扫描边解析，因此SAX可以在解析文档的任意时刻停止解析。非常适用于Android等移动设备。
SAX是基于事件驱动的。所谓事件驱动就是说，它不用解析完整个文档，在按内容顺序解析文档过程中，SAX会判断当前读到的字符是否符合XML文件语法中的某部分。如果符合某部分，则会触发事件。所谓触发事件，就是调用一些回调方法。当然android的事件机制是基于回调方法的，在用SAX解析xml文档时候，在读取到文档开始和结束标签时候就会回调一个事件，在读取到其他节点与内容时候也会回调一个事件。在SAX接口中，事件源是org.xml.sax包中的XMLReader，它通过parser()方法来解析XML文档，并产生事件。事件处理器是org.xml.sax包中ContentHander、DTDHander、ErrorHandler，以及EntityResolver这4个接口。
这四个接口的详细说明如下：

事件处理器名称

事件处理器处理的事件

XMLReader注册方法

ContentHander

XML文档的开始与结束，
XML文档标签的开始与结束，接收字符数据，跳过实体，接收元素内容中可忽略的空白等。

setContentHandler(ContentHandler h)

DTDHander

处理DTD解析时产生的相应事件

setDTDHandler(DTDHandler h)

ErrorHandler

处理XML文档时产生的错误

setErrorHandler(ErrorHandler h)

EntityResolver

处理外部实体

setEntityResolver(EntityResolver e)

我们用来做内容解析的回调方法一般都定义在ContentHandler接口中。
ContentHandler接口常用的方法：
startDocument()
当遇到文档的开头的时候，调用这个方法，可以在其中做一些预处理的工作。
endDocument()
当文档结束的时候，调用这个方法，可以在其中做一些善后的工作。
startElement(String namespaceURI, String localName,String qName, Attributes atts)
当读到开始标签的时候，会调用这个方法。namespaceURI就是命名空间，localName是不带命名空间前缀的标签名，qName是带命名空间前缀的标签名。通过atts可以得到所有的属性名和相应的值。
endElement(String uri, String localName, String name)
在遇到结束标签的时候，调用这个方法。
characters(char[] ch, int start, int length)
这个方法用来处理在XML文件中读到的内容。例如：<high data="30"/>主要目的是获取high标签中的值。
第一个参数用于存放文件的内容，后面两个参数是读到的字符串在这个数组中的起始位置和长度，使用new String(ch,start,length)就可以获取内容。
注意：
SAX的一个重要特点就是它的流式处理，当遇到一个标签的时候，它并不会纪录下之前所碰到的标签，即在startElement()方法中，所有能够知道的信息，就是标签的名字和属性，至于标签的嵌套结构，上层标签的名字，是否有子元属等等其它与结构相关的信息，都是不知道的，都需要你的程序来完成。这使得SAX在编程处理上没有DOM方便。
现在我们截取一段XML文件来做解析，其调用方法是这样的：
<?xml version="1.0"?> ----------> startDocument()
<weather> ----------> startElement
<forecast_information> ----------> startElement
<city> ----------> startElement
beijing ----------> characters
</city> ----------> endElement
</forecast_information > ----------> endElement
</weather > ----------> endElement
文档结束 ----------> endDocument()
SAX的解析步骤：
首先需要注意的是：
SAX还为其制定了一个Helper类：DefaultHandler它实现了ContentHandler这个接口，但是其所有的方法体都为空，在实现的时候，你只需要继承这个类，然后重载相应的方法即可。
使用SAX解析XML文件一般有以下五个步骤：
1、创建一个SAXParserFactory对象；
2、调用SAXParserFactory中的newSAXParser方法创建一个SAXParser对象；
3、然后在调用SAXParser中的getXMLReader方法获取一个XMLReader对象；
4、实例化一个DefaultHandler对象
5、连接事件源对象XMLReader到事件处理类DefaultHandler中
6、调用XMLReader的parse方法从输入源中获取到的xml数据
7、通过DefaultHandler返回我们需要的数据集合。
我们仍然来解析上述那个天气预报的XML文件。
编写代码如下：

[java] view plain
mySAX.setOnClickListener(new Button.OnClickListener(){
@Override
public void onClick(View v) {
try{
String url = "http://www.google.com/ig/api?&weather=beijing";
DefaultHttpClient client = new DefaultHttpClient();
HttpUriRequest req = new HttpGet(url);
HttpResponse resp = client.execute(req);
HttpEntity ent = resp.getEntity();
InputStream stream = ent.getContent(); //将文件导入流，因此用InputStream

SAXParserFactory saxFactory = SAXParserFactory.newInstance(); //获取一个对象
SAXParser saxParser = saxFactory.newSAXParser();//利用获取到的对象创建一个解析器
XMLContentHandler handler = new XMLContentHandler();//设置defaultHandler
saxParser.parse(stream, handler);//进行解析
stream.close();//关闭流
/*XMLReader xmlReader = saxFactory.newSAXParser().getXMLReader(); //获取一个XMLReader
xmlReader.setContentHandler(handler);
xmlReader.parse(new InputSource(stream));
stream.close();*/
}catch(Exception e){
e.printStackTrace();
}
}
});
}
public class XMLContentHandler extends DefaultHandler {
private static final String TAG = "XMLContentHandler";

@Override
public void characters(char[] ch, int start, int length)
throws SAXException {
Log.i(TAG, "解析内容："+new String(ch,start,length));
}
@Override
public void endDocument() throws SAXException {
super.endDocument();
Log.i(TAG, "文档解析完毕。");
}
@Override
public void endElement(String uri, String localName, String qName)
throws SAXException {
Log.i(TAG, localName+"解析完毕");
}
@Override
public void startDocument() throws SAXException {
Log.i(TAG, "开始解析... ...");
}
@Override
public void startElement(String uri, String localName, String qName,
Attributes attributes) throws SAXException {
Log.i(TAG, "解析元素："+localName);

if(localName.equals("high")){
Log.i(TAG, "解析元素："+localName);
i++;
if(i==2){
highestTmp.setText(String.valueOf((Integer.parseInt(attributes.getValue(0))-32)*5/9));
}
}
}
}

上面的那段注释：

[java] view plain
/*XMLReader xmlReader =saxFactory.newSAXParser().getXMLReader(); //获取一个XMLReader
xmlReader.setContentHandler(handler);
xmlReader.parse(newInputSource(stream));
stream.close();*/

是用XMLReader来做解析的另外一种方法。效果是一样的。这里可以传流，也可以传一个字符串，如下所示：是传字符串。
[java] view plain
xmlReader.parse(new InputSource(new StringReader(xmlStr)));
PULL方式
除了可以使用 SAX和DOM解析XML文件，也可以使用Android内置的Pull解析器解析XML文件。 Pull解析器的运行方式与 SAX 解析器相似。它也是事件触发的。Pull解析方式让应用程序完全控制文档该怎么样被解析。比如开始和结束元素事件，使用parser.next()可以进入下一个元素并触发相应事件。通过Parser.getEventType()方法来取得事件的代码值，解析是在开始时就完成了大部分处理。事件将作为数值代码被发送，因此可以使用一个switch对感兴趣的事件进行处理。
Pull解析是一个遍历文档的过程，每次调用next()，nextTag(), nextToken()和nextText()都会向前推进文档，并使Parser停留在某些事件上面，但是不能倒退。然后把文档设置给Parser。
Android中对Pull方法提供了支持的API，主要是
org.xmlpull.v1.XmlPullParser;
org.xmlpull.v1.XmlPullParserFactory;
二个类，其中主要使用的是XmlPullParser，XmlPullParserFactory是一个工厂，用于构建XmlPullParser对象。
应用程序通过调用XmlPullParser.next()等方法来产生Event，然后再处理Event。
我们仍然拿上述天气预报的XML文件的一部分来做例子。
例如：需要解析的XML文件是：

[java] view plain
<forecast_conditions>
<day_of_week data="周三"/>
<low data="22"/>
<high data="29"/>
<icon data="/ig/images/weather/chance_of_rain.gif"/>
<condition data="可能有雨"/>
</forecast_conditions>

这部分XML文件中day_of_week,low,high等是TAG，data是ATTRIBUTEA。当然，如果有<></>夹在开始和结束符号之间的部分，则为TXET。
要想解析文档先要构建一个XmlPullParser对象。

[java] view plain
final XmlPullParserFactory factory = XmlPullParserFactory.newInstance();
factory.setNamespaceAware(true);
final XmlPullParser parser = factory.newPullParser();
parser.setInput(new StringReader("xmlStr");

这里的xmlStr就是上边的XML文件。
此时，文档刚被初始化，所以它应该位于文档的开始，事件为START_DOCUMENT，可以通过XmlPullParser.getEventType()来获取。然后调用next()会产生
START_TAG，这个事件告诉应用程序一个标签已经开始了，调用getName()会返回" day_of_week ";若有TEXT，则再next()会产生TEXT事件，调用getText()会返回TEXT，由于此处没有，所以再next()，会产生END_TAG，这个告诉你一个标签已经处理完了，再next()直到最后处理完TAG，会产生END_DOCUMENT，它告诉你整个文档已经处理完成了。除了next()外，nextToken()也可以使用，只不过它会返回更加详细的事件，比如COMMENT, CDSECT, DOCDECL, ENTITY等等非常详细的信息。如果程序得到比较底层的信息，可以用nextToken()来驱动并处理详细的事件。需要注意一点的是TEXT事件是有可能返回空白的White Spaces比如换行符或空格等。
nextTag()--会忽略White Spaces，如果可以确定下一个是START_TAG或END_TAG，就可以调用nextTag()直接跳过去。通常它有二个用处：当START_TAG时，如果能确定这个TAG含有子TAG，那么就可以调用nextTag()产生子标签的START_TAG事件；当END_TAG时，如果确定不是文档结尾，就可以调用nextTag()产生下一个标签的START_TAG。在这二种情况下如果用next()会有TEXT事件，但返回的是换行符或空白符。
nextText()--只能在START_TAG时调用。当下一个元素是TEXT时，TEXT的内容会返回；当下一个元素是END_TAG时，也就是说这个标签的内容为空，那么空字串返回；这个方法返回后，Parser会停在END_TAG上。

小结一下，如果在一个XML文档中我们只需要前面一部分数据，但是使用SAX方式或DOM方式会对整个文档进行解析，尽管XML文档中后面的大部分数据我们其实都不需要解析，因此这样实际上就浪费了处理资源。使用PULL方式正合适。
当点击三种方式的任何一个按钮时，均能够得到相同的结果

③ Android之dropbox 分析

简介

adb查询

app接口

dropbox启动

dropbox日志路径：/data/system/dropbox

记录的系统错误
1.系统正常启动后的自检工作
1)SYSTEM_BOOT
开机一次，记录一次

2)SYSTEM_RESTART
如果system_server在设备运行过程中异常，则会有记录

3)SYSTEM_LAST_KMSG
kernel异常。
pstore是persistent storage的缩写，内核发生异常通过此把异常日志记录下来，方便定位问题。
ramoops指的是采用ram保存oops信息(kernel 异常信息)的一个功能，利用pstore技术实现。

4)SYSTEM_TOMBSTONE
TOMBSTONE 是 Android 用来记录 native 进程崩溃的 core mp 日志, 系统服务在启动完成后会增加一个 Observer 来侦测 tombstone 日志文件的变化, 每当生成新的 tombstone 文件, 就会增加一条 SYSTEM_TOMBSTONE 记录到 DropBoxManager 中.

5)SYSTEM_RECOVERY_LOG/SYSTEM_RECOVERY_KMSG
SYSTEM_RECOVERY_KMSG：recovery kerenl日志
SYSTEM_RECOVERY_LOG：recovery 升级或恢复出厂设置等等日志

6)SYSTEM_FSCK
文件系统完整性校验日志

7)SYSTEM_AUDIT
kernel 异常信息的查漏补缺日志

2.java/native crash。-- crash/native_crash
java/native层异常的区分在于eventType:crash/native_crash

3.anr 异常。-- anr
这里涉及广播、Service、Provider等组件的anr以及触摸按键事件的anr

4.wtf(What a Terrible Failure)。--- wtf
android.util.Log.wtf(String, String)，应用可调用布局异常点

5.strict mode。---**_strictmode
严格模式，主要为性能监测使用
StrictMode (严格模式), 顾名思义, 就是在比正常模式检测得更严格, 通常用来监测不应当在主线程执行的网络, 文件等操作. 任何 StrictMode 违例都会被 ActivityManagerService 在 DropBoxManager 中记录为一次 strict_mode 违例.

6.lowmem。低内存报告

7.watchdog
如果 WatchDog 监测到系统进程(system_server)出现问题, 会增加一条 watchdog 记录到 DropBoxManager 中, 并终止系统进程的执行.

8.其他
1)netstats_error/netstats_mp
NetworkStatsService 负责收集并持久化存储网络状态的统计数据, 当遇到明显的网络状态错误时, 它会增加一条 netstats_error 记录到 DropBoxManager.

2)BATTERY_DISCHARGE_INFO
BatteryService 负责检测充电状态, 并更新手机电池信息. 当遇到明显的 discharge 事件, 它会增加一条 BATTERY_DISCHARGE_INFO 记录到 DropBoxManager.

3)storage_benchmark/storage_trim
StorageManagerService 负责存储设备管理，例如sdcard或usb mass storage
fstrim提升磁盘性能，缓解Android卡顿

4)network_watchlist_report
NetworkWatchlistService

5)incident
frameworks/base/cmds/incidentd

6)keymaster
system/security/keystore

参考学习

④ Android 开发之系统 packages 文件解析

Android 系统中保存 app 信息的两个配置文件， packages.xml 和 packages.list ，此两个文件的初始路径为： /data/system/packages.xml 和 /data/system/packages.list 。系统中所有安装的app的基本信息在这里都能体现出来。这里以Android 6.0为基础来分析, 不同的Android版本, 可能内容会稍有出入, 但是基本上是相同的。

packages.list 文件位于 /data/system 目录下，该文件记录了系统中所有应用程序的基本信息，包含如下基本信息：

该文件的内容和格式相对简单，内容格式如下：

打开 packages.xml 文件，会发现这个文件非常的长，所以先列出这个文件的框架，以便对它有个整体的认知。

2.1 permissions

permissions块的类容如下:

它里面定义了系统中所有的申明的权限信息, 每个 item 块代表一个权限。name 表示权限的名字, package 表示申明权限的package, protection表示权限的级别, 如normal, dangerous之类的

2.2 keyset-settings

先看看keyset-settings块的内容:

另:

2.3 package

package 块内容如下:

package 块里包含了每个 app 的详细信息, 具体说明如下:

2.4 shared-user

以 android.uid.system 为例。

2.5 updated-package： 代表更新后的包信息。举个栗子：

⑤ Android-trace分析工具

1.TraceView

官方说明文档:

https://developer.android.google.cn/studio/profile/cpu-profiler

android CPU profiler

CPU profiler可以实时检查应用的CPU使用率和线程activity,并记录函数跟踪，以便于您可以优化和调试您的应用程序.

Flame Chart如果出现问题 颜色也会加深

2.systrace

简介:

systrace是Android4.1版本之后推出的，对系统Performance分析的工具。systrace的功能包括跟踪系统I/O操作,内核工作队列,CPU负载以及Android各个子系统的运行状况等。

主要由三部分构成:

1.内核部分

systrace采用了linux Kernel的ftrace功能，所以如果要使用systrace的话，必须开启Kernel和ftrace相关的模块.

2.数据采集部分

Android中定义了一个trace类,应用程序可以使用该类把统计信息输出给trace,同时，android有一个atrace程序，它可以从ftrace中读取统计信息然后交给数据分析工具来处理.

3.数据分析工具

Android提供一个systrace.py用来配置数据采集的方法(如采集数据的标签，输出文件名等)和收集ftrace统计数据并生成一个结果网页文件供用户查看。

简单的说,当机器以60帧/秒显示，用户会感知机器流畅。如果出现显示时丢帧的情况，就需要知道系统在做什么?Systrace是用来收集系统和应用的数据信息和一些中间生成数据的细节，在Android4.1和4.2系统之后出现。Systrace在分析一些显示问题上特别有用，如应用画图慢，显示动作或者动画时变形。

抓取systrace

进入本地Android/Sdk/platform-tools/systrace目录下,执行python systrace.py view --time = 10

python脚本的option

⑥ android 怎么解析tra文件

对于从事Android开发的人来说，遇到ANR(Application Not Responding)是比较常见的问题。一般情况下，如果有ANR发生，系统都会在/data/anr/目录下生成trace文件，通过分析trace文件，可以定位产生ANR的原因。产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件分析ANR问题。
对应的部分trace文件内容如下：
"PowerManagerService" prio=5 tid=24 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41dd0eb0 self=0x5241b218
| sysTid=567 nice=0 sched=0/0 cgrp=apps handle=1380038664
| state=S schedstat=( 6682116007 11324451214 33313 ) utm=450 stm=219 core=1
at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:~13045)
- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
at android.app.ContextImpl.sendBroadcast(ContextImpl.java:1144)
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.unblankAllDisplays(PowerManagerService.java:3442)
at com.android.server.power.DisplayPowerState$PhotonicMolator$1.run(DisplayPowerState.java:456)
at android.os.Handler.handleCallback(Handler.java:800)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:194)
at android.os.HandlerThread.run(HandlerThread.java:60)
"Binder_B" prio=5 tid=85 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x42744770 self=0x58329e88
| sysTid=3700 nice=-20 sched=0/0 cgrp=apps handle=1471424616
| state=S schedstat=( 1663727513 2044643318 6806 ) utm=132 stm=34 core=1
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.toString(PowerManagerService.java:~3449)
- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at com.android.server.power.PowerManagerService.mp(PowerManagerService.java:3052)
at android.os.Binder.mp(Binder.java:264)
at android.os.Binder.onTransact(Binder.java:236)
at android.os.IPowerManager$Stub.onTransact(IPowerManager.java:373)
at android.os.Binder.execTransact(Binder.java:351)
at dalvik.system.NativeStart.run(Native Method)
"android.server.ServerThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41a76178 self=0x507837a8
| sysTid=545 nice=-2 sched=0/0 cgrp=apps handle=1349936616
| state=S schedstat=( 15368096286 21707846934 69485 ) utm=1226 stm=310 core=0
at com.android.server.power.PowerManagerService.isScreenOnInternal(PowerManagerService.java:~2529)
- waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
at com.android.server.power.PowerManagerService.isScreenOn(PowerManagerService.java:2522)
at com.android.server.wm.WindowManagerService.(WindowManagerService.java:7749)
at com.android.server.wm.WindowManagerService.setEventDispatching(WindowManagerService.java:7628)
at com.android.server.am.ActivityManagerService.updateEventDispatchingLocked(ActivityManagerService.java:8083)
at com.android.server.am.ActivityManagerService.wakingUp(ActivityManagerService.java:8077)
at com.android.server.power.Notifier.sendWakeUpBroadcast(Notifier.java:474)
at com.android.server.power.Notifier.sendNextBroadcast(Notifier.java:455)
at com.android.server.power.Notifier.access$700(Notifier.java:62)
at com.android.server.power.Notifier$NotifierHandler.handleMessage(Notifier.java:600)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:194)
at com.android.server.ServerThread.run(SystemServer.java:1328)
从trace文件看，是因为TID为24的线程等待一个TID为12的线程持有的锁，TID为12的线程等待一个TID为85的线程持有的锁，而TID为85的线程确等待一个TID为24的线程持有的锁，导致了循环等待的现象，对应的trace文件的语句如下：
TID 24：- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
TID 12： - waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
TID 85：- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
既然是死锁，那么先看各线程都有那些锁。
先看TID=24的线程的栈顶，ActivityManagerService的broadcastIntent函数代码如下:
public final int broadcastIntent(IApplicationThread caller,
Intent intent, String resolvedType, IIntentReceiver resultTo,
int resultCode, String resultData, Bundle map,
String requiredPermission, boolean serialized, boolean sticky, int userId) {
enforceNotIsolatedCaller("broadcastIntent");
synchronized(this) {
intent = verifyBroadcastLocked(intent);
final ProcessRecord callerApp = getRecordForAppLocked(caller);
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
int res = broadcastIntentLocked(callerApp,
callerApp != null ? callerApp.info.packageName : null,
intent, resolvedType, resultTo,
resultCode, resultData, map, requiredPermission, serialized, sticky,
callingPid, callingUid, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
可以看到TID=24需要ActivityManagerService这个锁。再看TID=12线程的栈顶，PowerManagerService的isScreenOnInternal函数代码如下：

private boolean isScreenOnInternal() {
synchronized (mLock) {
return !mSystemReady
|| mDisplayPowerRequest.screenState != DisplayPowerRequest.SCREEN_STATE_OFF;
}
}
可以看到需要PowerManagerService的mlock这个锁。最后看TID=85线程的栈顶，同样在PowerManagerService里面，内部类DisplayBlankerImpl的toString函数：

public String toString() {
synchronized (this) {
return "blanked=" + mBlanked;
}
}
这是在内部类DisplayBlankerImpl里面实现的，所以需要DisplayBlankerImpl这个锁。
对应的表格如下：
表一 各线程等待的锁情况
从表一来看，没有出现死锁现象，似乎并不是我们所想的那样。难道不是死锁？开始有点小怀疑自己了，难道别的原因导致的。也许只看调用堆栈的顶端可能不行，栈顶只能看出各线程需要的锁，不能仅看自己要什么吧！一味索取可不好！人不是这样做的！看一下整个的堆栈调用流程，看看自己拥有了那些锁。
跟踪TID=24线程的堆栈，在PowerManagerService内部类DisplayBlankerImpl的unblankAllDisplays函数中持有锁：
public void unblankAllDisplays() {
synchronized (this) {
nativeSetAutoSuspend(false);
nativeSetInteractive(true);
mDisplayManagerService.();
mBlanked = false;
///M: add for tvout and hdmi
mTvOut.tvoutPowerEnable(true);
mHDMI.hdmiPowerEnable(true);
///@}
if (DEBUG) {
Slog.d(TAG_P, "unblankAllDisplays out ...");
}
if (mBootCompleted) {
Intent intent = new Intent(ACTION_LOCK_SCREEN_SHOW);
mContext.sendBroadcast(intent);
}
}
}
最后发送广播的代码，是我们自己添加的。根据unblankAllDisplays函数和broadcastIntent函数，可以看到TID=24的线程此时持有了DisplayBlankerImpl锁(unblankAllDisplays)，等待ActivityManagerService锁(broadcastIntent)释放。
同样，跟踪TID=12线程的堆栈，在ActivityManagerService的wake_up函数中持有锁：
public void wakingUp() {
if (checkCallingPermission(android.Manifest.permission.DEVICE_POWER)
!= PackageManager.PERMISSION_GRANTED) {
throw new SecurityException("Requires permission "
+ android.Manifest.permission.DEVICE_POWER);
}
synchronized(this) {
Slog.i(TAG, "wakingUp");
mWentToSleep = false;
updateEventDispatchingLocked();
comeOutOfSleepIfNeededLocked();
}
}
根据wakingUp函数和isScreenOnInternal函数，可以看到TID=12的线程持有ActivityManagerService锁(wakingUp)，等待PowerManagerService.mLock锁(isScreenOnInternal)。到这，似乎看到了希望，迷雾要拨开了，有点小自信是死锁导致的，但还不能最终下结论。
一鼓作气，跟踪TID=85线程的堆栈，在PowerManagerService的mp有持有锁的操作：
protected void mp(FileDescriptor fd, PrintWriter pw, String[] args) {
....
synchronized (mLock) {
...
}
根据toString函数和mp函数，可以看到TID=85线程此时持有PowerManagerService.mLock锁(mp)，需要DisplayBlankerImpl(toString)。

⑦ 安卓启动流程(一) - rc文件初步解析

init进程的一个核心部分，是通过解析rc文件，执行Action和启动Service。在分析init进程前，有必要先学习rc文件的配置和解析的原理。

/system/core/init/init.cpp

/system/core/init/init.cpp

通过 CreateParser , 创建了 Parser 解析器对象，其解析规则如下：

然后开始执行解析过程

最后调用 Parser 解析器的 ParseConfig 函数执行解析。

下一篇： 安卓启动流程(二) - Parser解析器

⑧ Android Studio 导入LeakCanary文件进行分析

Android Studio打开profile崩溃解决方案
Android Studio 使用Profile官方指南
LeakCanary检测内存泄露案例分析
前面我们说道使用LeakCanary进行了初步的内存分析。接下来我们说一下，如何通过Android Studio自带的Proflie进行深度分析
1.首先，需要把手机里面的leak收集到的hprof文件进行导入。
导入方式如下：
路径是：
Physical#手机#Actions#文件夹#storage#sdcard0#Download#leakcanary-xxx(包名)#选中需要导出的文件#Save as#对应保存的路径

2.从电脑导入对应需要分析的hprof文件
路径是：
Profiler#SESSIONS#+#load from file

3.如何分析，如图

主要看Depth深度，如果大于0。那么我们就需要谨慎分析处理可能存在的引用关系

⑨ 如何用android解析docx文档

android上查阅word类型文档的方式主要有几种，下载诸如wps，office等应用，用户可以直接打开需要查看的word文档，对于应用开发者来说，如何在自己的应用中集成word文档查阅功能，使自己的app不受限于第三方应用有没有安装，有时候还是需要考虑的。
集成app阅读word功能也可以通过几种方式实现，例如购买专门的sdk包，像Aspose等（money啊）或者服务器端处理成图片或者html，然后android端去请求访问等方式。对于大部分个人开发者而言，这两种方式就显得比较重量级了。
下面介绍两种专门解析docx文件的方式：docx4j 以及poi
Docx4j
github地址：https://github.com/plutext/AndroidDocxToHtml
这个是官网demo，基本可以直接使用，解析出来的格式比较全，样式也比较接近原文档，就是解析速度令人不敢恭维，手机上测试的话，一般一份儿docx文档都需要30s以上甚至更多，有时候测试文档明明就只有几十k大小而已，对于比较大，比较复杂的文档，时间就更是让人崩溃。解析速度不是令人满意。
解析测试中遇到的bug
1.表格丢失，内容丢失：内嵌表格（表格中还有表格的这种）的内容和样式会有部分丢失现象
2.表格（又是我？）样式：假如文档中的表格在word文档中排版时超出了该文档的边界线，你会发现超出边界的内容又不见了
3.目录乱码：如果文档中有目录，目录会被加上一些超链接，需要手工处理去掉
4.图片无法解析：有一些格式的图片无法解析，比如EMF，WMF这种类型的
5.批注无法显示：目前没有找到批注显示的地方，暂且算丢失吧，后面在试试
6.。。。其它暂时还没被发现的问题
POI
poi是apache的一个开源项目，不多说，直接上官网去下载就可以
官网地址：http://poi.apache.org/
如果你是android studio用户：那就很简单了
只需要引入依赖（版本号不一定哦，gradle会自己把相关依赖包下载到位）：
compile 'fr.opensagres.xdocreport:org.apache.poi.xwpf.converter.xhtml:1.0.5'

那如果你是eclipse用户（伙计，赶紧用studio吧）
需要手工引入以下jar包，包括：
poi , poi-ooxml , ooxml-schema,org.apache.poi.xwpf.converter.xhtml,org.apache.poi.xwpf.converter.core

实现代码如下
{
InputStream is = new FileInputStream(file);
XWPFDocument docx = new
XWPFDocument(is);
OutputStream os = new ByteArrayOutputStream();
String imgDesPath = "/sdcard/img";
File imgFile = new File("/sdcard/img");
this.baseUrl = this.getDir("image", Context.MODE_PRIVATE).toURL().toString();
if (!imgFile.exists()) {
file.mkdirs();
}

poi解析的问题
速度比docx4j要稍快一点，会有文档内容解析不全样式丢失的情况
流程
调用接口将docx转化为html，然后app中通过webview加载该html即可显示
转化代码如下（我就想问下，这代码格式到底该怎么调啊～好烦躁）：
try {
InputStream is = new FileInputStream(file);
XWPFDocument docx = new
XWPFDocument(is);
OutputStream os = new ByteArrayOutputStream();
String imgDesPath = "/sdcard/img";
File imgFile = new File("/sdcard/img");
this.baseUrl = this.getDir("image", Context.MODE_PRIVATE).toURL().toString();
if (!imgFile.exists()) {
file.mkdirs();
}
XHTMLOptions options = XHTMLOptions.create().URIResolver(new BasicURIResolver(imgDesPath));
options.setExtractor(new FileImageExtractor(imgFile));
options.setIgnoreStylesIfUnused(false);
options.setFragment(true);
XHTMLConverter.getInstance().convert(docx, os, options);
**os.write("/sdcard/xxx/html文件")**
} catch (Exception e) {
Log.d(TAG, "catch " + e.getMessage());
}

webview 里面直接load 上面生成的html文件就可以了

⑩ Android生成APK后目录中META-INF目录文件解析

Android开发环境对每一个需要Release的APK都会进行签名，在APK文件被安装时，Android系统会对APK的签名信息进行比对，以此来判断程序的完整性，最终确定APK是否可以正常安装使用，一定程度上达到安全的目的。

给一个APK文件的后缀名从.apk改为.zip或者.rar，然后利用解压工具进行解压，我们会在META-INF目录下看到四个文件： MANIFEST.MF、CERT.SF、INDEX.LIST、CERT.RSA

MANIFEST.MF（摘要文件）： 程序遍历APK包中的所有文件，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码。如果APK包的文件被修改，在APK安装校验时，被修改的文件与MANIFEST.MF的校验信息不同，程序将无法正常安装。

CERT.SF（对摘要文件的签名文件）： 对于生成的MANIFEST.MF文件利用SHA1-RSA算法对开发者的私钥进行签名。在安装时只有公共密钥才能对其解密。解密之后将其与未加密的摘要信息进行比对，如果相符则文件没有被修改。

INDEX.LIST APK索引文件目录

CERT.RSA   保存公钥、加密算法等信息。

在APK进行安装时，可以通过MANIFEST.MF文件开始的环环相扣来保证APK的安全性。但这些文件或者密钥如果被攻击者得到或者被攻击者通过某些技术手段攻破，则Android操作系统无法验证其安全性。