Android 5.0 是 Google 于 2014 年 10 月 15 日发布的全新 Android 操作系统
本次Android 5.0 Lollipop系统升级进行了十多项改动，对于移动APP主要有4个方面的影响：
1. 全新的Material Design设计风格，对移动应用的影响：
1) 测试时需检查各界面显示是否正常，重点关注刷新以及动画效果;
2) 为了保持与Android系统风格的一致性，建议各个产品线使用新的material design。
2. 全新风格的通知中心对移动应用的影响：
1) 测试了原有通知机制在5.0上的兼容性。
3. ART 模式大大提升了性能，对移动应用的影响：
1) 应用兼容性：如果应用本身对Dex文件做了处理，可能会出现兼容性问题;
2) 性能优化：可重点关注ART带来的性能优化数据，对于大量使用CPU的应用，性能提升比较明显。但如果应用程序的时间主要花在调用系统API，提升会小一些;
3) 应用安装包体积：因为安装时进行了预先编译，应用安装的时间会变长，安装后生成的文件也会变大;
4) 第一次启动时长：如果以DexClassLoader的形式加载代码，第一次启动时间也会变长。
4. 续航能力增强，对移动应用的影响：
1) 开启省电模式后，系统降低CPU的主频，要求产品在低性能的情况下可以正常运行;
2) 当应用在后台运行被停止后，系统再次进入非省电模式时，进入应用后，可以增加相关的用户提示，同时可以考虑自动重新开始之前的操作(如后台下载等)。
也可参考google 官方建议： http://developer.android.com/about/versions/android-5.0-changes.html
Android L版本变化
google的官方说明链接：http://developer.android.com/about/versions/android-5.0-changes.html
如下是开发工程师的部分总结：
1. ART相关
1.1 ART jni检查更为严格
java用的是byte[] arrary，而jni对应的参数为jboolarrary。 由于这个是art跟dalvik区别，现在要求涉及此问题应用自己修改参数适配
2. L版本Framework SDK相关
2.1 apk startservice/bindservice报错，本身google通过版本号进行了兼容，如果应用使用的sdk版本号低于L，则不会报异常
2.2 apk内部非正规lib使用方式导致32bit/64bit不兼容。 一些apk的lib没有打包到apk内部合适路径，正常apk使用的apk应该按照如下方式进行打包：
Apk lib名称 Lib模式 对应模式
lib/ armeabi 32bit arm
lib/ armeabi-v7a 32bit arm
lib/ arm64-v8a 64bit arm64
apk安装时候PMS模块会设置正确的abi属性，nativeLibraryPath，primaryCpuAbi和secondaryCpuAbi
而一些apk将自己使用的lib，通过自己私有方式处理lib，可能会出错。
2.3 Uniqueness Requirement for Custom Permissions特性，也就是控制开发者自定义权限的权限名唯一性。不同签名APK声明（定义）相同的Permission ，后面Apk将无法安装，错误码为-112（INSTALL_FAILED_DUPLICATE_PERMISSION ）。解决办法如下：
1) 尽量不要自定义权限，要想清楚自定义权限的必要性
2) 如果非要自定义权限，rename your custom permissions to be unique to your app, such as by appending them to the full package name of your app ，也就是在自定义权限名上加上包名的前缀，这样可以保持唯一性，避免相互冲突。
2.4shared user 多个apk在art编译的时候，如何选择生成的art arm模式？
共shared user 的apk，根据google选择是可以运行在同一个进程上的。但是生成oat是在apk扫描和安装的时候依次生成，很难知道找到一个最优模式。adjustCpuAbisForSharedUserLPw 函数有一定的随机性，尤其当apk里面本身没有abi的时候、
google答复：
under no circumstances can you have two apps under the same shared ID have different abis.
please keep in mind that shared user ID apps can potentially run in the same process and you cannot
load a 32 and 64 bit shared library into the same process.
as far as this case in concerned, this is WAI - except perhaps we could throw an error or not modify
any of the apps ABIs if we encounter an error.
如果自己生成odex，这个规则要注意。
兼容性解决方法：
1）.将shareuser apk使用到的lib都编译成两套
2）.尽量将apk私有lib，打包到自己的lib abi目录，通过PMS自己扫描正确的模式。
2.5 lang.System.arraycopy
java.lang.NoSuchMethodError: java.lang.System.arraycopy
at com.huawei.android.launcher.xxxx(PinyinMatcher.java:143)
L的工程下编出来的APK，在4.4的机器上运行时java.lang.System.arraycopy方法会报找不到。
兼容性方法：
应用代码可以使用下面逻辑进行适配：
/**
* in L System.arraycopy has been overloaded several methods by primary type but be set @hide. Apks compiled in L run in KK or below will
* throw method not found exception because they just have System.arraycopy(Object, int, Object, int, int).
*/
public static void arraycopy(Object src, int srcPos, Object dst, int dstPos, int length) {
if (Build.VERSION.SDK_INT >= VERSION_CODES_LOLLIPOP) {
System.arraycopy(src, srcPos, dst, dstPos, length);
} else {
Object srcObj = (Object)src;
Object dstObj = (Object)dst;
System.arraycopy(srcObj, srcPos, dstObj, dstPos, length);
}
3. Apk本身一些防护问题
需应用本身会读取手机的cpu abilist，发现不兼容，则直接报错。