如何定制android源码的编译选项后期安装.docx
《如何定制android源码的编译选项后期安装.docx》由会员分享,可在线阅读,更多相关《如何定制android源码的编译选项后期安装.docx(12页珍藏版)》请在冰豆网上搜索。
![如何定制android源码的编译选项后期安装.docx](https://file1.bdocx.com/fileroot1/2023-1/24/533f99ba-2ba1-4e90-ba45-cb24b229ca12/533f99ba-2ba1-4e90-ba45-cb24b229ca121.gif)
如何定制android源码的编译选项后期安装
如何定制android源码的编译选项&后期安装?
Android编译过程比较长,配置起来也很麻烦。
现仅就工作遇到的问题做个总结。
所用硬件平台为amlogicstvm3。
---------------------------------------------------------------------------
关于版本号:
文件build/core/version_defaults.mk用来检查一些跟版本相关的变量是否定义;如果未定义,则使用默认值。
这些变量包括
PLATFORM_VERSION #如2.2.5
PLATFORM_SDK_VERSION # 8,对应2.2.5
PLATFORM_VERSION_CODENAME #REL,即发行版
DEFAULT_APP_TARGET_SDK #同SDK_VERSION或VERSION_CODENAME
BUILD_ID #默认为UNKNOWN
BUILD_NUMBER #默认eng.$(USER).$(shelldate+%Y%m%d.%H%M%S)的形式。
version_defaults.mk首先包含进build_id.mk。
用户应当配置build_id.mk,而不应该改动version_defaults.mk文件。
然后检查上述变量,如未定义则赋值默认值。
---------------------------------------------------------------------------
关于调试功能(adb)的开启
编译android源码之前总是要先运行build/envsetup.sh,以初始化一些常用命令(实际上是bash的函数,如add_lunch_combo)。
其中也从以下文件中引入了一些编译设置:
device/${CHIPSET_VENDOR}/vendorsetup.sh
我们这里使用的CHIPSET_VENDOR为amlogic。
比如我们有文件device/amlogic/vendorsetup.sh,内容为"产品名-编译类型(flavor)"列表(称为combo),如下:
add_lunch_combo m1ref-eng
add_lunch_combo m1ref-user
add_lunch_combo m2ref-eng
add_lunch_combo m2ref-user
add_lunch_combo stvm3-eng
add_lunch_combo stvm3-user
其中,m1ref和stvm3是产品名(作前缀),后面为编译类型。
除此前缀外可选的combo值有:
eng,user,userdebug,tests。
(参考文件build/core/main.mk中对于变量TARGET_BUILD_VARIANT的筛查条件)
我们可以修改vendorsetup.sh文件,来改变为特定设备编译的结果。
以下是各个编译类型的特点:
eng:
工程模式,用于平台级的调试,是默认的编译类型。
待安装的模块tag有:
eng,debug,user,development.
安装不带tag的非APK模块;
所安装应用由产品定义文件给出;
默认属性:
ro.secure=0,ro.deuggable=1,ro.kernel.android.checkjni=1
adbd默认开启,adb以root身份运行。
user:
即最终用户版;
待安装的应用tag有:
user
安装不带tag的非APK模块;
所安装应用由产品定义文件给出;
默认属性有ro.secure=1,ro.debuggable=0;
默认关闭adbd服务(但可通过应用settings来打开,且adb以shell身份运行);
userdebug:
与user类似,除了:
支持有限的调试功能;
待安装的应用tag有:
debug;
默认属性有ro.secure=1,ro.debuggable=1;
默认打开adbd服务,adb以shell身份运行;
例如,由文件build/core/main.mk可以看出,当使用含有userdebug的combo值时,此文件中的临时变量enable_target_debugging会保持为true,相应地,编译过程会执行:
ADDITIONAL_DEFAULT_PROPERTIES+=ro.debuggable=1persist.service.adb.enable=1
这意味着目标系统中根目录下的文件/default.prop文件(对应变量INSTALLED_DEFAULT_PROP_TARGET)会含有以下行(参考文件build/core/Makefile):
persist.service.adb.enable=1
由此,目标系统会默认开启adbd服务,你就可以通过其它PC来连接目标系统了。
所以,如要默认开启adbd服务,可在设备(如stvm3)定制文件device/amlogic/vendorsetup.sh中增加以下行:
add_lunch_combo stvm3-userdebug
这样在执行bash的lunch函数时,选择此combo就可以默认打开adbd服务(adb以shell身份运行)。
但是,即使adbd已经开启,你仍可能无法通过网络连接到Android进行调试,这涉及到Android的二个属性:
service.adb.tcp.port (优先级高)
persist.adb.tcp.port (优先级低)
注:
可查看源码文件system/core/adb/adb.c。
默认地,这两个属性值是5555。
有两种方法来设置此变量:
1)(永久性改变)在Android配置文件/init.rc或/init.$MANUFACTUROR.rc中添加一行:
setprop service.adb.tcp.port 5555
2)(临时性改变)在命令行上(你可能需要先通过串口开一个终端)执行如下命令:
setprop service.adb.tcp.port 5555
检查adbd是否支持通过网络链接Android:
执行命令
netstat-l-n | grep":
5555"
如果有LISTEN状态的输出,则表示adbd支持网络模式 :
) 。
---------------------------------------------------------------------------
具体地说,TARGET_PRODUCT是怎么定义的?
在针对一个板子编译Android前总要先执行build/envsetup.sh(它会包含设备相关的环境设置,如device/amlogic/vendorsetup.sh),然后运行新获得的lunch函数来选择编译目标类型(即combo),如'stvm3-userdebug'。
查看文件build/envsetup.sh可知(line519~549),TARGET_PRODUCT就是combo在‘-’前的部分(如'stvm3'),TARGET_BUILD_VARIANT为combo在‘-’后的部分(如'userdebug')。
根据build/core/main.mk文件,tags_to_install会包含‘debug',所以firmware会默认打开'adbd'(见上一小节)。
[用于代替lunch进行类似定义的还有build/buildspec.mk或函数choosecombo()].
根据以下的包含或调用关系:
build/envsetup.sh(inget_build_var():
make--no-print-directory-C"$T"-fbuild/core/config.mkdumpvar-$1)
->build/core/config.mk(include$(BUILD_SYSTEM)/envsetup.mk)
->build/core/envsetup.mk(include$(BUILD_SYSTEM)/product_config.mk)
->build/core/product_config.mk(invokeget-all-product-makefiles())
->build/core/product.mk(defineget-all-product-makefiles())
->stvm3/AndroidProducts.mk
->device/amlogic/stvm3/stvm3.mk
可知,板子的编译过程会在device/amlogic/stvm3/stvm3.mk中重新定义以下变量:
PRODUCT_NAME:
=stvm3
PRODUCT_MANUFACTURER:
=my_manufacturer_name
PRODUCT_DEVICE:
=stvm3
PRODUCT_MODEL:
=M3mediaboxboard
PRODUCT_LOCALES:
=en_USen_GBfr_FRzh_TWzh_CN
另,device/amlogic/stvm3/stvm3.mk还会包含device/amlogic/common/mbx_amlogic.mk,后者也定义了PRODUCT_NAME、PRODUCT_BRAND等变量(但随后部分变量被stvm3.mk覆盖),并且覆盖了所包含的device/amlogic/common/core_amlogic.mk文件的同名定义。
由此可见,core_amlogic.mk优先级低于具体设备(如mbx_amlogic.mk)的配置文件。
---------------------------------------------------------------------------
product的基本描述(或定义):
涉及以下几个变量:
PRODUCT_NAME (预定以的值有:
core,sim,sdk,generic_x86,full,generic)
PRODUCT_BRAND (貌似与PRODUCT_NAME区别不大)
PRODUCT_DEVICE
PRODUCT_CHARACTERISTICS
这些变量首先在文件build/target/product/core.mk初始化,而后在build/target/product/{sim,sdk,generic,full}.mk中被覆盖。
对于stvm3板子来说,它们在device/amlogic/common/core_amlogic.mk中预初始化,在文件device/amlogic/common/{mid,tv,mbx}_amlogic.mk的末尾它们的值被覆盖。
---------------------------------------------------------------------------
另:
/default.prop是如何生效的?
文件system/core/init/init.c:
main(argc,argv):
snprintf(tmp,sizeof(tmp),"/init.%s.rc",hardware);
parse_config_file(tmp);
action_for_each_trigger("early-init",action_add_queue_tail);
queue_builtin_action(wait_for_coldboot_done_action,"wait_for_coldboot_done");
queue_builtin_action(property_init_action,"property_init");
queue_builtin_action(keychord_init_action,"keychord_init");
queue_builtin_action(logo_init_action,"logo_init");
queue_builtin_action(console_init_action,"console_init");
queue_builtin_action(set_init_properties_action,"set_init_properties");
...
queue_builtin_action(property_service_init_action,"property_service_init");
queue_builtin_action(signal_init_action,"signal_init");
queue_builtin_action(check_startup_action,"check_startup");
...
queue_builtin_action(queue_property_triggers_action,"queue_propety_triggers");
device_fd=device_init();
property_init(); //<--------在这里初始化各种属性。
...
for(;;){
execute_one_command();
...
//通过poll处理各种事件,包括基于通道/dev/socket/property_service的属性设置
// 事件:
handle_property_set_fd();
//由system/core/init/property_service.c:
property_set()看出,无论属性的prefix是什么,
// 如果它是个新属性(即代码中的pi==0),总是可以把它加到属性集中去的,不管是不是"ro."属性。
//比如frameworks/base/services/java/com/android/server/BootReceiver.java中对属性"ro.runtime.firstboot"
// 的读取和设置。
}
文件system/core/init/property_service.c:
voidproperty_init(void){
...
load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT); //<--------读取属性文件。
}
这里,PROP_PATH_RAMDISK_DEFAULT就是文件“/default.prop”,参见bionic/libc/include/sys/_system_properties.h :
#define PROP_SERVICE_NAME "property_service"
#define PROP_PATH_RAMDISK_DEFAULT "/default.prop"
#define PROP_PATH_SYSTEM_BUILD "/system/build.prop"
#define PROP_PATH_SYSTEM_DEFAULT "/system/default.prop"
#define PROP_PATH_LOCAL_OVERRIDE "/data/local.prop"
---------------------------------------------------------------------------
StatusBar的默认隐藏
默认地,Android会显示statusbar。
应用程序要想隐藏StatusBar,需要在Activityde的onCreate()里写如下代码:
//toremovetitlebarinJavacode:
MyActivity.requestWindowFeature(Window.FEATURE_NO_TITLE);
setContentView(R.layout.myWind);
//toremovestatusbarinJavacode:
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, \
WindowManager.LayoutParams.FLAG_FULLSCREEN);
setContentView(R.layout.myWind);
或者在AndroidManifest.xml文件添加以下属性到相关Activity:
//toremovetitlebarinManifest.xml:
android:
theme="@android:
style/Theme.NoTitleBar"
//toremovetitlebar&statusbarinManifest.xml:
android:
theme="@android:
style/Theme.NoTitleBar.Fullscreen"
有些清况下,我们需要在系统级别默认隐藏StatusBar。
做法如下:
1)建立一个属性,如“persist.service.statusbar”,用来表示StatusBar当前是否显示;在frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/StatusBarService.java文件的makeStatusBarView()和mBroadcastReceiver(例如针对事件android.statusbar.visibility.changed)里,根据此属性值来显示或隐藏StatusBar.
2)在Settings应用里,增加切换显示/隐藏StatusBar的控制UI(如在文件packages/apps/Settings/src/com/android/settings/DisplaySettings.java中),当有变化发生时,先设置属性值“persist.service.statusbar”,然后发出广播"android.statusbar.visibility.changed"。
注:
属性名的选择:
以“persistent.”开头的属性值在发生改变时会被自动保存在目标系统的/data/property/目录下,每一个属性有一个文件来记录器内容。
注:
文件system/core/include/arch/linux-arm/AndroidConfig.h含有很多预定义来控制编译过程,如HAVE_LIBC_SYSTEM_PROPERTIES,HAVE_SYS_SOCKET_H。
---------------------------------------------------------------------------
.apk包列表的定制:
设备无关的公共的包的定制可以在以下文件中执行:
build/target/product/core.mk或
build/target/product/generic.mk或
build/target/product/full.mk等。
对于特定product的包的定制,可以通过以下文件(product名为stvm3):
device/amlogic/stvm3/stvm3.mk
涉及到的makefile变量为'PRODUCT_PACKAGES'.
另外,对于一个具体设备来说,有一些默认安装的包在其它的文件里设定,如
‘Home‘ 在文件device/amlogic/common/core_amlogic.mk中;
‘Launcher2’在文件device/amlogic/common/mbx_amlogic.mk中;
---------------------------------------------------------------------------
后期prebuild文件的安装:
Androidbuildsystem主要有两大部分构成:
1)配置部分;
2)目标构建部分。
Buildsystem的主流程文件为build/core/main