androidlunch
重新 repo sync
⑵ android编译源码后怎样运行
编译：
1. 初始化：
source build/envsetup.sh
2. 选择target
lunch
然后选择aosp_arm
3.
make -j4
等待大概2个小时，就可以顺利编译完成。
模拟器运行
直接运行emulator，会出现如下错误：
emulator: ERROR: You did not specify a virtual device name, and the system
directory could not be found.
原因是文件路径没有设置，解决办法添加绝对路径：
out/host/linux-x86/bin/emulator -kernel prebuilts/qemu-kernel/arm/kernel-qemu -sysdir out/target/proct/generic/ -system out/target/proct/generic/system.img -ramdisk out/target/proct/generic/ramdisk.img -data out/target/proct/generic/userdata.img -sdcard sdcard.img -scale 0.7 -memory 512 -partition-size 1024
然后运行模拟器
⑶ 编译a20 lunch后面应该选择哪个
Android的优势就在于其开源，手机和平板生产商可以根据自己的硬件进行个性定制自己的手机产品，
如小米，LePhone，M9等，因此，在我们在对Android的源码进行定制的时候，很有必要了解下，Android的编译过程。
如果你从来没有做过Android代码的编译，那么最官方的编译过程就是查看Android的官方网站：
http://source.android.com/source/building.html
但是，这儿只是告诉你了如何去编译一个通用的系统，并没有详细告诉你细节，我们跟着编译过程来了解下
+-------------------------------------------------------------------------------------------------------------+
本文使用Android版本为2.1，采用开发板为华清远见研发的FS_S5PC100 A8开发板。
+-------------------------------------------------------------------------------------------------------------+
按照google给出的编译步骤如下：
1> source build/envsetup.sh:加载命令
2> lunch：选择平台编译选项
3> make：执行编译
我们按照编译步骤来分析编译过程的细节，最终添加自己的平台编译选项。
1. source build/envsetup.sh
这个命令是用来将envsetup.sh里的所有用到的命令加载到环境变量里去，我们来分析下它。
envsetup.sh里的主要命令如下：
function help() # 显示帮助信息
function get_abs_build_var()# 获取绝对变量
function get_build_var()# 获取绝对变量
function check_proct()# 检查proct
function check_variant()# 检查变量
function setpaths() # 设置文件路径
function printconfig()# 打印配置
function set_stuff_for_environment() # 设置环境变量
function set_sequence_number() # 设置序号
function settitle() # 设置标题
function choosetype() # 设置type
function chooseproct() # 设置proct
function choosevariant() # 设置variant
function tapas() # 功能同choosecombo
function choosecombo() # 设置编译参数
function add_lunch_combo() # 添加lunch项目
function print_lunch_menu() # 打印lunch列表
function lunch()# 配置lunch
function m()# make from top
function findmakefile() # 查找makefile
function mm() # make from current directory
function mmm() # make the supplied directories
function croot()# 回到根目录
function cproj()
function pid()
function systemstack()
function gdbclient()
function jgrep()# 查找java文件
function cgrep() # 查找c/cpp文件
function resgrep()
function tracedmmp()
function runhat()
function getbugreports()
function startviewserver()
function stopviewserver()
function isviewserverstarted()
function smoketest()
function runtest()
function godir () # 跳到指定目录 405
# add_lunch_combo函数被多次调用，就是它来添加Android编译选项
# Clear this variable. It will be built up again when the vendorsetup.sh
406 # files are included at the end of this file.
# 清空LUNCH_MENU_CHOICES变量，用来存在编译选项
407 unset LUNCH_MENU_CHOICES
408 function add_lunch_combo()
409 {
410 local new_combo=$1 # 获得add_lunch_combo被调用时的参数
411 local c # 依次遍历LUNCH_MENU_CHOICES里的值，其实该函数第一次调用时，该值为空
412 for c in ${LUNCH_MENU_CHOICES[@]} ; do
413 if [ "$new_combo" = "$c" ] ; then # 如果参数里的值已经存在于LUNCH_MENU_CHOICES变量里，则返回
414 return
415 fi
416 done # 如果参数的值不存在，则添加到LUNCH_MENU_CHOICES变量里
417 LUNCH_MENU_CHOICES=(${LUNCH_MENU_CHOICES[@]} $new_combo)
418 }
# 这是系统自动增加了一个默认的编译项 generic-eng
420 # add the default one here
421 add_lunch_combo generic-eng # 调用上面的add_lunch_combo函数，将generic-eng作为参数传递过去
422
423 # if we're on linux, add the simulator. There is a special case
424 # in lunch to deal with the simulator
425 if [ "$(uname)" = "Linux" ] ; then
426 add_lunch_combo simulator
427 fi
# 下面的代码很重要，它要从vendor目录下查找vendorsetup.sh文件，如果查到了，就加载它
1037 # Execute the contents of any vendorsetup.sh files we can find.
1038 for f in `/bin/ls vendorbuild/vendorsetup.sh 2> /dev/null`
1039 do
1040 echo "including $f"
1041 . $f # 执行找到的脚本，其实里面就是厂商自己定义的编译选项
1042 done
1043 unset f
envsetup.sh其主要作用如下：
1. 加载了编译时使用到的函数命令，如：help，lunch，m，mm，mmm等
2. 添加了两个编译选项：generic-eng和simulator，这两个选项是系统默认选项
3. 查找vendor/<-厂商目录>/和vendor/<厂商目录>/build/目录下的vendorsetup.sh，如果存在的话，加载执行它，添加厂商自己定义产品的编译选项
其实，上述第3条是向编译系统添加了厂商自己定义产品的编译选项，里面的代码就是：add_lunch_combo xxx-xxx。
根据上面的内容，可以推测出，如果要想定义自己的产品编译项，简单的办法是直接在envsetup.sh最后，
添加上add_lunch_combo myProct-eng，当然这么做，不太符合上面代码最后的本意，
我们还是老实的在vendor目录下创建自己公司名字，然后在公司目录下创建一个新的vendorsetup.sh，在里面添加上自己的产品编译项
#mkdir vendor/farsight/
#touch vendor/farsight/vendorsetup.sh
#echo "add_lunch_combo fs100-eng" > vendor/farsight/vendorsetup.sh
这样，当我们在执行source build/envsetup.sh命令的时候，可以在shell上看到下面的信息：
including vendor/farsight/vendorsetup.sh
2. 按照android官网的步骤，开始执行lunch full-eng
当然如果你按上述命令执行，它编译的还是通用的eng版本系统，不是我们个性系统，我们可以执行lunch命令，它会打印出一个选择菜单，列出可用的编译选项
如果你按照第一步中添加了vendorsetup.sh那么，你的选项中会出现：
You're building on Linux
generic-eng simulator fs100-eng
Lunch menu... pick a combo:
1. generic-eng
2. simulator
3. fs100-eng
其中第3项是我们自己添加的编译项。
lunch命令是envsetup.sh里定义的一个命令，用来让用户选择编译项，来定义Proct和编译过程中用到的全局变量。
我们一直没有说明前面的fs100-eng是什么意思，现在来说明下，fs100是我定义的产品的名字，eng是产品的编译类型，除了eng外，还有user, userdebug，分别表示：
eng: 工程机，
user:最终用户机
userdebug:调试测试机
tests:测试机
由此可见，除了eng和user外，另外两个一般不能交给最终用户的，记得m8出来的时候，先放出了一部分eng工程机，然后出来了user机之后，可以用工程机换。
那么这四个类型是干什么用的呢？其实，在main.mk里有说明，在Android的源码里，每一个目标（也可以看成工程）目录都有一个Android.mk的makefile，每个目标的Android.mk中有一个类型声明：
LOCAL_MODULE_TAGS，这个TAGS就是用来指定，当前的目标编译完了属于哪个分类里。
PS:Android.mk和Linux里的makefile不太一样，它是Android编译系统自己定义的一个makefile来方便编译成：c,c++的动态、静态库或可执行程序，或java库或android的程序，好了，我们来分析下lunch命令干了什么？
function lunch()
{
local answer
if [ "$1" ] ; then
# lunch后面直接带参数
answer=$1
else
# lunch后面不带参数，则打印处所有的target proct和variant菜单提供用户选择
print_lunch_menu
echo -n "Which would you like? [generic-eng] "
read answer
fi
local selection=
if [ -z "$answer" ]
then
# 如果用户在菜单中没有选择，直接回车，则为系统缺省的generic-eng
selection=generic-eng
elif [ "$answer" = "simulator" ]
then
# 如果是模拟器
selection=simulator
elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$")
then
# 如果answer是选择菜单的数字，则获取该数字对应的字符串
if [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ]
then
selection=${LUNCH_MENU_CHOICES[$(($answer-$_arrayoffset))]}
fi
# 如果 answer字符串匹配 *-*模式(*的开头不能为-)
elif (echo -n $answer | grep -q -e "^[^\-][^\-]*-[^\-][^\-]*$")
then
selection=$answer
fi
if [ -z "$selection" ]
then
echo
echo "Invalid lunch combo: $answer"
return 1
fi
# special case the simulator
if [ "$selection" = "simulator" ]
then
# 模拟器模式
export TARGET_PRODUCT=sim
export TARGET_BUILD_VARIANT=eng
export TARGET_SIMULATOR=true
export TARGET_BUILD_TYPE=debug
else
# 将 proct-variant模式中的proct分离出来
local proct=$(echo -n $selection | sed -e "s/-.*$//")
# 检查之，调用关系 check_proct()->get_build_var()->build/core/config.mk比较罗嗦，不展开了
check_proct $proct
if [ $? -ne 0 ]
then
echo
echo "** Don't have a proct spec for: '$proct'"
echo "** Do you have the right repo manifest?"
proct=
fi
# 将 proct-variant模式中的variant分离出来
local variant=$(echo -n $selection | sed -e "s/^[^\-]*-//")
# 检查之，看看是否在 (user userdebug eng) 范围内
check_variant $variant
if [ $? -ne 0 ]
then
echo
echo "** Invalid variant: '$variant'"
echo "** Must be one of ${VARIANT_CHOICES[@]}"
variant=
fi
if [ -z "$proct" -o -z "$variant" ]
then
echo
return 1
fi
# 导出环境变量，这里很重要，因为后面的编译系统都是依赖于这里定义的几个变量的
export TARGET_PRODUCT=$proct
export TARGET_BUILD_VARIANT=$variant
export TARGET_SIMULATOR=false
export TARGET_BUILD_TYPE=release
fi # !simulator
echo
# 设置到环境变量，比较多，不再一一列出，最简单的方法 set >env.txt 可获得
set_stuff_for_environment
# 打印一些主要的变量, 调用关系 printconfig()->get_build_var()->build/core/config.mk-
>build/core/envsetup.mk 比较罗嗦，不展开了
printconfig
}
由上面分析可知，lunch命令可以带参数和不带参数，最终导出一些重要的环境变量，从而影响编译系统的编译结果。导出的变量如下（以实际运行情况为例）
TARGET_PRODUCT=fs100
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
执行完上述两个步骤，就该执行：make命令了
⑷ Android中的Activity详解--启动模式与任务栈
目录
activity的简单介绍就不写了，作为最常用的四大组件之一，肯定都很熟悉其基本用法了。
首先，是都很熟悉的一张图，即官方介绍的Activity生命周期图.
情景：打开某个应用的的FirstActivity调用方法如下：
由于之前已经很熟悉了，这里就简单贴一些图。
按下返回键：
重新打开并按下home键：
再重新打开：
在其中打开一个DialogActivity(SecondActivity)
按下返回：
修改SecondAcitvity为普通Activity,依旧是上述操作:
这里强调一下 onSaveInstanceState(Bundle outState) 方法的调用时机：
当Activity有可能被系统杀掉时调用，注意，一定是被系统杀掉，自己调用finish是不行的。
测试如下：FirstActivity启动SecondActivity：
一个App会包含很多个Activity，多个Activity之间通过intent进行跳转，那么原始的Activity就是使用栈这个数据结构来保存的。
Task
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the back stack ), in the order in which each activity is opened.
即若干个Activity的集合的栈表示一个Task。
当App启动时如果不存在当前App的任务栈就会自动创建一个，默认情况下一个App中的所有Activity都是放在一个Task中的，但是如果指定了特殊的启动模式，那么就会出现同一个App的Activity出现在不同的任务栈中的情况，即会有任务栈中包含来自于不同App的Activity。
标准模式，在不指定启动模式的情况下都是以此种方式启动的。每次启动都会创建一个新的Activity实例，覆盖在原有的Activity上，原有的Activity入栈。
测试如下：在FirstActivity中启动FirstActivity:
当只有一个FirstActivity时堆栈情况：
此种模式下，Activity在启动时会进行判断，如果当前的App的栈顶的Activity即正在活动的Activity就是将要启动的Activity，那么就不会创建新的实例，直接使用栈顶的实例。
测试，设置FirstActivity为此启动模式，多次点击FirstActivity中的启动FirstActivity的按钮查看堆栈情况：
（其实点击按钮没有启动新Activity的动画就可以看出并没有启动新Activity）
大意就是：
对于使用singleTop启动或Intent.FLAG_ACTIVITY_SINGLE_TOP启动的Activity，当该Activity被重复启动（注意一定是re-launched，第一次启动时不会调用）时就会调用此方法。
且调用此方法之前会先暂停Activity也就是先调用onPause方法。
而且，即使是在新的调用产生后此方法被调用，但是通过getIntent方法获取到的依旧是以前的Intent，可以通过setIntent方法设置新的Intent。
方法参数就是新传递的Intent.
1.如果是同一个App中启动某个设置了此模式的Activity的话，如果栈中已经存在该Activity的实例，那么就会将该Activity上面的Activity清空，并将此实例放在栈顶。
测试：SecondActivity启动模式设为singleTask，启动三个Activity：
这个模式就很好记，以此模式启动的Activity会存放在一个单独的任务栈中，且只会有一个实例。
测试：SecondActivity启动模式设为singleInstance
结果：
显然，启动了两次ThirdActivity任务栈中就有两个实例，而SecondActivity在另外一个任务栈中，且只有一个。
在使用Intent启动一个Activity时可以设置启动该Activity的启动模式：
这个属性有很多，大致列出几个：
每个启动的Activity都在一个新的任务栈中
singleTop
singleTask
用此种方式启动的Activity，在它启动了其他Activity后，会自动finish.
官方文档介绍如下：
这样看来的话，通俗易懂的讲，就是给每一个任务栈起个名，给每个Activity也起个名，在Activity以singleTask模式启动时，就检查有没有跟此Activity的名相同的任务栈，有的话就将其加入其中。没有的话就按照这个Activity的名创建一个任务栈。
测试：在App1中设置SecondActivity的taskAffinity为“gsq.test”，App2中的ActivityX的taskAffinity也设为“gsq.test”
任务栈信息如下：
结果很显然了。
测试：在上述基础上，在ActivityX中进行跳转到ActivityY,ActivityY不指定启动模式和taskAffinity。结果如下：
这样就没问题了，ActivityY在一个新的任务栈中，名称为包名。
这时从ActivityY跳转到SecondActivity，那应该是gsq.test任务栈只有SecondActivity，ActivityX已经没有了。因为其启动模式是singleTask，在启动它时发现已经有一个实例存在，就把它所在的任务栈上面的Activity都清空了并将其置于栈顶。
还有一点需要提一下，在上面，FirstActivity是App1的lunch Activity，但是由于SecondActivity并没有指定MAIN和LAUNCHER过滤器，故在FirstActivity跳转到SecondActivity时，按下home键，再点开App1，回到的是FirstActivity。
大致就先写这么多吧，好像有点长，废话有点多，估计也有错别字，不要太在意~~~
⑸ 如何通过lunch选择驱动编译
先把的打印机的所有连线都练接到电脑上，然后开启驱动精灵，他会自动搜索哪些硬件没有驱动，让后辨别，下载，安装！ 很简单的
⑹ 自己可以编译安卓源码吗
用最新的Ubuntu 16.04,请首先确保自己已经安装了Git.没安装的同学可以通过以下命令进行安装:
sudo apt-get install git git config –global user.email “[email protected]” git config –global user.name “test”
其中[email protected]为你自己的邮箱.
简要说明
android源码编译的四个流程:1.源码下载;2.构建编译环境;3.编译源码;4运行.下文也将按照该流程讲述.
源码下载
由于某墙的原因,这里我们采用国内的镜像源进行下载.
目前,可用的镜像源一般是科大和清华的,具体使用差不多,这里我选择清华大学镜像进行说明.(参考:科大源,清华源)
repo工具下载及安装
通过执行以下命令实现repo工具的下载和安装
mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo
补充说明
这里,我来简单的介绍下repo工具,我们知道AOSP项目由不同的子项目组成,为了方便进行管理,Google采用Git对AOSP项目进行多仓库管理.在聊repo工具之前,我先带你来聊聊多仓库项目:
我们有个非常庞大的项目Pre,该项目由很多个子项目R1,R2,...Rn等组成,为了方便管理和协同开发,我们为每个子项目创立自己的仓库,整个项目的结构如下:
这里写图片描述
执行完该命令后,再使用make命令继续编译.某些情况下,当你执行jack-admin kill-server时可能提示你命令不存在,此时去你去out/host/linux-x86/bin/目录下会发现不存在jack-admin文件.如果我是你,我就会重新repo sync下,然后从头来过.
错误三:使用emulator时,虚拟机停在黑屏界面,点击无任何响应.此时,可能是kerner内核问题,解决方法如下:
执行如下命令:
通过使用kernel-qemu-armv7内核 解决模拟器等待黑屏问题.而-partition-size 1024 则是解决警告: system partion siez adjusted to match image file (163 MB >66 MB)
如果你一开始编译的版本是aosp_arm-eng,使用上述命令仍然不能解决等待黑屏问题时,不妨编译aosp_arm64-eng试试.
结束吧
到现在为止,你已经了解了整个android编译的流程.除此之外,我也简单的说明android源码的多仓库管理机制.下面,不妨自己动手尝试一下.
⑺ android中如何编译出64位so文件
如果是在Linux下编译Android源码，有可能是两个原因：
1. lunch命令有32位和64位的区别，注意选能够编译64位so的命令
2. mk文件中有LOCAL_MODULE_PATH的值比如为$(TARGET_OUT_SHARED_LIBRARIES)/hw的改为LOCAL_MODULE_RELATIVE_PATH := hw，后一种可以分别在lib和lib64下分别生成32位和64位的so文件，这个看看编译后的信息就知道了．
⑻ 泰克思达平板电脑10.1寸四核心16gb开机后只显示安卓启动什么原因
我的也是，昂达的普遍问题
⑼ Android源码编译是干什么
编译Android系统。
⑽ android怎么在launcher前启动一个应用程序
如果你要定制一个Android系统，你想用你自己的Launcher(Home)作主界面来替换Android自带的Home，而且不希望用户安装的Launcher来替换掉你的Launcher，应该如何来实现呢？
我们可以通过修改Framework层来实现这样的功能。
1) 首先了解一下Android的启动过程。
Android系统的启动先从Zygote开始启动，然后......(中间的过程就不说了).....一直到了SystemServer(framework)这个地方，看到这段代码：
/**
* This method is called from Zygote to initialize the system. This willcause the native
* services (SurfaceFlinger, AudioFlinger, etc..) to be started. Afterthat it will call back
* up into init2() to start the Android services.
*/
native public static void init1(String[] args);
public static void main(String[] args) {
if (SamplingProfilerIntegration.isEnabled()) {
SamplingProfilerIntegration.start();
timer = new Timer();
timer.schele(new TimerTask() {
@Override
public void run() {
SamplingProfilerIntegration.writeSnapshot("system_server");
}
}, SNAPSHOT_INTERVAL, SNAPSHOT_INTERVAL);
}
// The system server has to run all of the time, so it needs to be
// as efficient as possible with its memory usage.
VMRuntime.getRuntime().setTargetHeapUtilization(0.8f);
System.loadLibrary("android_servers");
init1(args);
}
public static final void init2() {
Log.i(TAG, "Entered the Android system server!");
Thread thr = new ServerThread();
thr.setName("android.server.ServerThread");
thr.start();
}
}
从SystemServer的main函数开始启动各种服务：
首先启动init1,然后启动init2.从上面的注释可以看到：init1这个方法时被Zygote调用来初始化系统的，init1会启动native的服务如SurfaceFlinger,AudioFlinger等等，这些工作做完以后会回调init2来启动Android的service。
这里我们主要来关注init2的过程。init2中启动ServerThread线程，ServerThread中启动了一系列的服务，比如这些：
ActivityManagerService
EntropyService
PowerManagerService
TelephonyRegistry
PackageManagerService
AccountManagerService
BatteryService
HardwareService
Watchdog
SensorService
BluetoothService
StatusBarService
ClipboardService
InputMethodManagerService
NetStatService
ConnectivityService
AccessibilityManagerService
NotificationManagerService
MountService
DeviceStorageMonitorService
LocationManagerService
SearchManagerService
FallbackCheckinService
WallpaperManagerService
AudioService
BackupManagerService
AppWidgetService
这些大大小小的服务起来以后，开始
((ActivityManagerService)ActivityManagerNative.getDefault()).systemReady()
在systemReady后开始开始启动Launcher。在寻找Launcher的时候是根据HOME的filter（在Manifest中定义的<categoryandroid:name="android.intent.category.HOME" />）来过滤。
然后根据filter出来的HOME来启动，如果只有一个HOME，则启动这个HOME，如果用户自己装了HOME，那就会弹出来一个列表供用户选择。
我们现在希望从这里弹出我们自己定制的Launcher,同时也不希望弹出选择HOME的界面，我们不希望用户修改我们的home，比如我们的home上放了好多广告，以及强制安装的程序，不希望用户把它干掉。
我们可以通过这样来实现：
2) 定义一个私有的filter选项，然后用这个选项来过滤HOME.
一般情况下我们使用Manifest中定义的<categoryandroid:name="android.intent.category.HOME"来过滤的，我们现在增加一个私有的HOME_FIRST过滤。
在Intent.java(frameworks/base/core/java/android/content/Intent.java)中添加两行代码
//lixinso:添加CATEGORY_FS_HOME
@SdkConstant(SdkConstantType.INTENT_CATEGORY)
public static final String CATEGORY_FS_HOME= "android.intent.category.FS_HOME";
3）修改和CATEGORY_HOME相关的所有的地方，都改成CATEGORY_FS_HOME，主要是framework中的这几个地方：使用grep命令查找要修改的地方：
grep CATEGORY_HOME -l * -R
将上述文件中和CATEGORY_HOME相关的所有的地方，都改成CATEGORY_FS_HOME。
4) 写一个自己的Launcher.
可以参考android sample中的Launcher，或者android源代码中的 /packages/apps/Launcher 来写。
在Launcher中标记其是不是Launcher的最关键的代码时Manifest中的filter:android:name="android.intent.category.HOME"
现在我们定义了自己的filter,那么，我们在我们自己写的Launcher中将Manifest改为：
<application android:process="android.process.acore3"android:icon="@drawable/icon"android:label="@string/app_name">
<activity android:name=".FirstAppActivity"
android:label="@string/app_name">
<intent-filter>
<actionandroid:name="android.intent.action.MAIN" />
<categoryandroid:name="android.intent.category. FS_HOME" />
<categoryandroid:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.MONKEY"/>
</intent-filter>
</activity>
</application>
然后将编译好的apk放到方式fs100_root/system/app目录下。
5)将Android自带的Launcher删除掉
包括源代码(packages/apps/Launcher)和apk(/out/target/proct/generic/system/app/Launcher.apk)。
6) 重新编译Android
做完这些工作，就可以重新编译Android了，我们可以编译修改过的几个相关的包，可以用mmm命令来编译部分的改动。这里需要这样编译：
$ source build/envsetup.sh
$ lunch
$ mmm frameworks/base
$ mmm frameworks/base/services/java
$ mmm frameworks/policies/base/mid
$ mmm frameworks/policies/base/phone
重新启动开发板，从开发板上就可以看到启动的Launcher是我们自己的Launcher，不会出现默认的Launcher了，也不会出现选择界面。
9)我们再验证一下，如果用户装上了一个其他的Launcher(Home)会怎么样。
从网上找一个一般的Launcher或者自己写一个一般的Launcher装上去，重新启动，不会出现选择界面。
按HOME键也不会出来两个HOME来选择。
这样我们就牢牢控制了用户的桌面。
只有我们自己定制的HOME才能装上。这对于定制Android设备的厂商很有用处。