android安装原理

A. Android 的提权 (Root) 原理是什么

android其实是基于linux的一个操作系统，只是被用到了移动设备上面了，如果你想在pc上面安装android系统，理论上是完全可行的。
现在其实才牵涉到了android root的原理，root其实就是获取android系统的root权限。至于原理：手机制造商原始出厂的手机并未开放root权限，获取root的方法都是不受官方支持的，因此，目前获取root的方法都是利用系统漏洞实现的。而不同手机厂商可能存在的漏洞不同，也就导致了不同手机root的原理可能不同。不过，不管采用什么原理实现root，最终都需要将su可执行文件复制到Android系统的/system分区下(例如：/system/xbin/su) 并用chmod命令为其设置可执行权限和setuid权限。为了让用户可以控制root权限的使用，防止其被未经授权的应用所调用，通常还有一个Android应用程序来管理su程序的行为。root的基本原理就是利用系统漏洞，将su和对应的Android管理应用复制到/system分区。（这个是我复制的维基网络的，如果你懂一点儿linux，那么这个过程就很好理解，如果不懂呢，那么你可以忽略掉。）

B. Android系统应用安装过程以及应用备份原理是怎样的

可以下载一个360手机助手，再用数据线连到电脑，就可以了，在电脑上选择游戏，就会自动下载安装了

C. Android V1及V2签名原理简析

Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：

签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：

再看下只有V2签名的APK包样式：

同时具有V1 V2签名：

可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内， 签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改 ，如下图：

而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：

V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在.rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，

如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFEST.MF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校验就可以绕过。

CERT.SF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFEST.MF一样，.SF校验也很容易被绕过。

CERT.RSA与CERT.SF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERT.RSA文件内容：

CERT.RSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERT.SF的摘要信息，其严格的格式如下：

从CERT.RSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：

除了CERT.RSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFEST.MF与CERT.SF都是一样的，不同的只有CERT.RSA签名文件。也就是说前两者主要保证各个文件的完整性，CERT.RSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？

前面说过V1签名中文件的完整性很容易被绕过，可以理解 单个文件完整性校验的意义并不是很大 ，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是 针对APK进行校验 ，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。

也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。

APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。

而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。

知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：

其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSigner.java的sign函数，函数比较长，分几步分析

先来看这一步，ApkUtils.findZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：

获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，

可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名

先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。

第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：

步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：

这里特殊提一下重复签名的问题： 对一个已经V1签名的APK再次V1签名不会有任何问题 ，原理就是：再次签名的时候，会排除之前的签名文件。

可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。

V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：

签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，7.0以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于7.0以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：

校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验

这里只关心证书部分：

Android V1及V2签名签名原理简析

仅供参考，欢迎指正

D. Android N 四大组件的工作原理

本文侧重讲解android N 系统中四大组件的工作原理，不同系统原理略有差别。通过分析四大组件的工作流程加深对Android Framework的理解，也为插件化开发打下基础。

Activity
展示一个界面并和用户交互，它扮演的是一个前台界面的角色。

Service
计算型组件，用于后台执行一系列计算任务，工作在主线程，耗时操作需要另起线程， 分为启动状态和绑定状态。

BroadcastReceiver
消息型组件，主要用于不同组件或者不同应用之间的消息传递，它工作在系统内部，不适合执行耗时操作，操作超过5s，会出现ANR。

ContentProvider
数据共享型组件，用于向其他组件或者应用共享数据，主要执行CURD操作。

我们启动一个activity有两种方法，
第一种（Activity直接启动方式）：
Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);

第二种（Context启动方式）
Intent intent = new Intent(this, MainActivity.class);
getApplicationContext().startActivity(intent);

不同的启动方式Activity的工作流程有点差别。

两种启动都会调用到Instrumentation类中的execStartActivity的方法，系统最终是通过ActivityThread中的performLaunchActivity完成Activity的创建和启动。
performLaunchActivity方法主要完成以下工作：
1、通过ActivityClientRecord对象获取启动activity的组件信息
2、通过mInstrumentation对象的newActivity方法调用classloader完成activity的创建
3、通过r.packageInfo(LoadedApk 对象)的makeApplication方法尝试创建Application对象
4、创建ContextImpl对象并调用Activity的attach方法完成一些数据的初始化
5、调用Activity的onCreate方法

在Activity启动的过程中，App进程会频繁地与AMS进程进行通信：

App进程会委托AMS进程完成Activity生命周期的管理以及任务栈的管理；这个通信过程AMS是Server端，App进程通过持有AMS的client代理IActivityManager完成通信过程；
AMS进程完成生命周期管理以及任务栈管理后，会把控制权交给App进程，让App进程完成Activity类对象的创建，以及生命周期回调；这个通信过程也是通过Binder完成的，App所在server端的Binder对象存在于ActivityThread的内部类ApplicationThread；AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信。

Service有两种启动方式，startService()和bindService()，两种状态可以并存:
startService流程

bindService流程

BroadcastReceiver的工作过程主要包括广播的注册、发送和接收:

动态注册过程：

发送过程

静态注册是由PackageManagerService（PMS）在应用安装的时候完成整个注册过程的，除广播以外，其他三大组件也都是在应用安装时由PMS解析并注册的。

每个进程的入口都是ActivityThead.main()，App的启动流程如下：

从源码中可以看出：
应用启动的入口为ActivityThread的main方法，main方法会创建ActivityThread实例并创建主线程消息队列。
attach方法中远程调用AMS的attachApplication方法，并提供ApplicationThread用于和AMS的通信。
attachApplication方法会通过bindApplication方法和H来调回ActivityThread的handleBindApplication，这个方法会先创建Application，再加载ContentProvider，然后才会回调Application的onCreate方法。

由上图可以看出，在ContentProvider的启动过程中伴随着app进程的启动。

ContentProvider的其他CURD操作如insert，delete，update跟query的流程类似。

E. 如何实现android静默安装

原理：
使用隐藏的系统API——installPackage。该方法在1.5版之后的android SDK中是看不见的，查看源码可以看到它设置了@hide属性，但在实际的运行包framework.jar中是存在的，因此只要能编译通过，安装到系统后是可以正常运行的。
步骤：
1. 从模拟器System\framework目录下提取framework.jar
2. 将framework.jar后缀名改为zip，解压后提取其中的classes.dex文件
3. 用dex2jar工具将classes.dex转成classes.dex.dex2jar.jar(注意新版本的dex2jar工具无法转换Android2.2的framework，建议使用dex2jar-0.0.7.8-SNAPSHOT，该工具可以从google官方站上下载到)
4. 将classes.dex.dex2jar.jar改名为classes.dex.dex2jar.zip解压取出android/content/pm/目录下的PackageManager.class，IPackageInstallObserver.class，IPackageDeleteObserver.class及相关的几个class文件备用
5. 找到android-sdk目录下的android.jar,改名为android.zip（注意改名前先备份一下）,解压后将步骤4中取得的class文件覆盖到android对应的目录下，重新压缩成android.zip，并改名为android.jar
6. 这个时候android.jar已经是一个更新过的SDK了，重新打开eclipse工程，已经可以实现。
调用方法：
void android.content.pm.PackageManager.installPackage(Uri packageURI, IPackageInstallObserver observer, int flags, String installerPackageName)

说明：
1. 由于更改android.jar可能导致重新加载SDK失败，覆盖之前切记备份一下
2. 实际上该过程可以调用到任何hide属性的API，本文为了影响最小，只覆盖了installPackage相关的class
3. 下载android源码重新编译SDK也可以实现调用隐藏API，不过比较麻烦

F. 如何搭建android运行环境

1.Android运行环境的搭建

进行安卓系统的软件设计，那么JDK的开发环境搭建必须是首要的。我们选择Windows10 64位操作系统。同时在JDK版本的选择中选用Windows x64版本的Java SE Development Kit 8u5，该版本稳定，应用广泛而且开源免费，获取方便。在安装的过程中要注意不要重复安装，应安装完毕后立即删除安装包，否则如果不小心再次点到安装包，该安装包会立刻删除所安装的程序并询问是否重新安装。在JDK的安装过程中，要注意开发工具，源代码，公共JRE三项都要选中，而且要安装到C盘默认目录下，同时将其附带的JRE同样安装到相同目录下，同时硬盘至少应该留有2G的空间。

选择好JDK的版本并进行安装后，我们的JAVA环境就安装好了，众所周知，安卓系统是由JAVA语言架构的，所以在搭建安卓运行环境之前必须要先安装JAVA环境。安装完JAVA环境之后，我们进行安卓开发环境的搭建。我们就要进行Android SDK版本的选择。我们这里选择android-sdk_r24.4.1-windows版本。这个版本是与安卓8.0同时发布的，同时它的发布时间也在我们的安卓测试机红米NOTE5A型号之后，可以完美兼容我们的安卓测试机所运行的安卓7.1.2版本。

5. 总结

本次主要介绍了系统软件环境的搭建与生成,从Android运行环境的搭建，Windows系统环境变量设置，Android SDK的配置， SDK接口和APK生成几个方面分别介绍了具体步骤,让我们了解了本文安卓系统软件开发的环境配置。

以上就是安卓环境和下载和安装啦，按步骤来操作对小白来说也是相对简单的，只要注意一些文中说明的细节，现在就开始行动起来一起学unity吧。

G. android系统原理

Android系统原理及开发要点详解

给您看看

H. android如何实现静默安装哦

原理

• 静默安装、卸载的原理就是利用pm install命令来安装apk，pm uninstall 来卸载apk.

• 智能安装是利用android系统提供的无障碍服务AccessibilityService，来模拟用户点击，从而自动安装.

//静默安装
privatevoidinstallSlient(){
Stringcmd="pminstall-r/mnt/sdcard/test.apk";
Processprocess=null;
DataOutputStreamos=null;
BufferedReadersuccessResult=null;
BufferedReadererrorResult=null;
StringBuildersuccessMsg=null;
StringBuildererrorMsg=null;
try{
//静默安装需要root权限
process=Runtime.getRuntime().exec("su");
os=newDataOutputStream(process.getOutputStream());
os.write(cmd.getBytes());
os.writeBytes("
");
os.writeBytes("exit
");
os.flush();
//执行命令
process.waitFor();
//获取返回结果
successMsg=newStringBuilder();
errorMsg=newStringBuilder();
successResult=newBufferedReader(newInputStreamReader(process.getInputStream()));
errorResult=newBufferedReader(newInputStreamReader(process.getErrorStream()));
Strings;
while((s=successResult.readLine())!=null){
successMsg.append(s);
}
while((s=errorResult.readLine())!=null){
errorMsg.append(s);
}
}catch(Exceptione){
e.printStackTrace();
}finally{
try{
if(os!=null){
os.close();
}
if(process!=null){
process.destroy();
}
if(successResult!=null){
successResult.close();
}
if(errorResult!=null){
errorResult.close();
}
}catch(Exceptione){
e.printStackTrace();
}
}
//显示结果
tvTest.setText("成功消息："+successMsg.toString()+"
"+"错误消息:"+errorMsg.toString());
}

I. 安卓系统是否可以刷到任何硬件设备上

楼主你好！

如果有Android系统的源代码，然后又有 硬件设备的原理图。理论上就可以做到将Android系统安装到所有硬件上。不过用程序员严谨的话讲，这句话成立还有个前提，那就是Android 源码中所包含的Linux 源码中，支持你硬件中CPU执行的指令集。如果CPU都不认识你编译出来的程序指令，你有如何期望他能够正确跑的写的Driver呢？

J. 安卓手机软件无法安装，提示安装未完成。

1、可能你的手机里面，软件残留的东西太多了，建议先用360手机卫士之类的管理软件清理一下。
2、之前安装过同类的软件，但是出现过问题，导致安装发生问题。
3、安装包下载的不完全或者有损坏，导致安装过程无法完成，可以换一个版本的安装包试试。
下面引用一套解决方案：
（其实解决的方法理论上不受机型和系统限制，原理应该都是一样的，跟SD卡也没关系~）
系统环境：已Root，已做APP2SD+，SD卡分为两个区：一个512M的Ext分区（安装软件的地方），一个剩余空间的Fat32分区
首先说一下问题发生时的症状：最近一段时间连续发生了三个应用程序未安装的情况，无论是从市场里安装还是用豌豆荚的各种安装方法均显示“应用程 序未安装”，并且用各种卸载工具、软件管理工具以及系统内置的程序管理均无法找到相关应用程序，连无图标那种都没有，属于彻彻底底的找不着，就连用RE浏 览器也搜索不到，而除此之外的其他应用程序都可以正常安装~
之前尝试解决的过程（均无效，懒得看的朋友可以直接跳过）：
1、第一个想法就是系统内有程序残留，可能是未删除干净导致无法安装，因此用RE浏览器搜索程序相关关键字，把找到的相关文件和目录全部删除，然后重启再安装程序，结果无效；
2、想到之前有过备份，于是打开钛备份，找到相关软件，还原：最开始选择的是程序+数据，显示还原失败，然后单独选择还原程序，提示还原成功， 但是在系统内并没有看到还原成功的程序，所以被忽悠了（这里我没有做重启系统的尝试，不知道如果还原之后重启系统会不会有效，有兴趣的朋友可以试试 哈~）；
3、没办法，只能Google了，首先找到的是成功最多的一种方法：【储存模式连接电脑或者用Root Explorer找到SD卡目录下的.android_secure文件夹，里面应该会有一个smdl2tmp1.asec，也可能是其他名称，总之与正 常程序命名格式明显不一样的文件，删除，再次安装软件试试】，但是我无论是系统还是SD卡均找不到相关目录及文件，所以这种方法对我完全没用；
4、第二种方法：【如果是PC端上安装应用提示失败，请先检查有没有安装Android手机对应的的USB驱动,一般使用91手机助手或豌豆夹都会自动帮你装上手机驱动】，我是手机端提示失败，并且我的驱动正确安装，豌豆荚也使用正常，所以这个跟我无关；
5、第三种方法：【查看手机设置-应用程序-未知来源 是否勾选，否则就会导致有些非电子市场提供的应用程序无法安装】，我勾选的，所以这个也跟我无关；
6、第四种方法：【用系统自带的程序管理查看SD卡上的程序，有的程序竟然是没有彩色图标的，原来就是这些 没有图标的软件在作怪，这些没有图标的软件就是以前一些没有正确安装或者卸载不完全软件数据，如果你再次安装就会报错，现在我们用系统自带的软件管理把它 们卸载干净，再次安装软件时就不会出错了】，可是我用系统自带的程序管理连任何图标都看不到，所以这种方法对我没用；
7、第五种方法：【只需删除/mnt/secure/asec/smdl2tmp1.asec (驱动器模式下是：可移动磁盘/.android_secure/smdl2tmp1.asec)，再安装即可】，这种方法是第一种方法的补充，可惜的是 我系统和卡里也根本没有mnt目录，所以没用；
8、第六种方法：【升级已安装的程序时提示“应用程序未安装” 少部分软件升级时会出现，只能卸载掉旧版本，再安装新版本】，我根本找不到卸载，所以也没用；
9、第七种方法：【在设置-开发-允许模拟地点上打钩，就OK乐】，这个我勾上了还是没用；
10、第八种方法：【手机连接电脑然后打开91手机助手，随便安装一个应用程序，选择安装路径为手机内存】，我是2.1系统，本来软件就都是装在“内存”中的，所以这个也没用；
11、第九种方法：【还有一部分因为软件签名更改了，所以不能覆盖安装，直接删除重新安装新的版本即可】，这个原理同方法六一样，所以对我无效；
12、第十种方法：【直接恢复出厂设置】，这是我不愿意做的一种方法，理论上应该有效吧。
经过了以上各种尝试后，问题仍旧无法解决，那个郁闷啊，难道我就必须恢复出厂么？犹豫再三，都已经开始准备重装了，结果在搜索安卓系统安装原理的时候居然被我找到一种方法，解决了这个困扰我多时的未安装问题，下面我们一起来看下解决方案：
其实安卓系统的程序安装就是把APK文件复制到APP目录下并赋予权限，备份也是把APK文件以及相关的数据文件复制出来，依照此原理，我做了如下操作：
1、首先下载应用程序的APK安装包放到SD卡里；
2、将APK文件改名为com.xxx.xxx.apk的形式（对比系统APP目录下的文件名做的改动，纯中文或者其他任意文件名能否成功我没有做过测试~）；
3、用有Root权限的RE浏览器将卡内的APK文件移动或复制到系统目录内的APP目录下（就是你能看到其他应用程序图标的那个目录）；
4、找到你复制过来的APK文件，长按调出菜单选“权限”，对照下图勾选相应的权限并确定；
读写执行
用户√√○
分组√○○
其他√○○
5、重启手机（这一步很重要，重启之后系统才会重新搜索应用程序）；
6、怎么样？重启之后是不是又看见可爱的程序图标了？打开试试，都能正常使用~（不要以为到这里就结束了）；
7、虽然程序正常了，但是如果再次安装或者升级，之前的一切就白做了，就会再次变成最初的“应用程序未安装”状态；
8、因此在程序能正常使用的时候，打开任何一款程序卸载软件，我用的是深度卸载，找到并卸载之；
9、正常卸载之后，这次你可以放心的重新安装了，升级什么的也不会出现“应用程序未安装”了。
至此，这个问题就算是完美解决了，希望对深受“应用程序未安装”困扰的机友们能有所帮助