本文详细介绍了Chrome OS Factory SDK的组成部分，包括Factory Server、Shopfloor Service API、Device Data和测试列表。Factory Server是生产线上的核心，Shopfloor Service API用于与ODM或CM的后台系统交互，Device Data存储设备信息，测试列表则定义了生产线上的测试流程。此外，文章还探讨了编码规范、区域配置和设备数据的管理。
Factory SDK完全解读
方向分解：
factoryserver:
setup/FACTORY_SERVER.md
shopfloor:车间api，包含连接工厂服务器和工厂终端软件的接口
py/shopfloor/README.md
TestList:测试项列表
py/test/test_lists/README.md
一、Factory SDK介绍
1.1 SDK目录结构：
-
bin : factory源码中工具的symlink文件，基本上为sh脚本或py脚本。
-
build :用于构建Factory SDK的临时目录。
-
Makefile : 用于构建factory 源码和文档的make文件。
-
py : Python 源码. 该目录即 cros.factory 模块, cros.factory.system.board 模块 py/system/board 目录下.
-
py_pkg : 该目录作为 PYTHONPATH 入口，包含了factory source. py_pkg/cros/factory 只是 py 的一个symlink。 比如如果查找 cros.factory.system.board 模块 py_pkg/cros/factory/system/board.py 实际是指向了 py/system/board.py。
-
sh : shell脚本
1.2 Makefile
make目标包含以下内容：
-
default : 构建工厂测试工具.
-
par : 构建Python archive，par包含了所有源码和依赖的库文件，可以用来运行各种各样的工具。
-
lint : 检查源码是否不规范。
-
test : 单元测试
-
overlay- board : 创建以overlay-{board} 未命名规范的目录，对应的目录包含了对板的factory源码 (e.g., in third_party/private-overlays/overlay- board -private/chromeos-board/factory-board/files ). 对于特定板子的测试列表是非常有用的。
-
overlay- board -lint : 运行 overlay- board -lint ,即在对应的overlay目录下执行 make lint。
-
overlay- board -test : 运行 overlay- board -test ,即在对应的目录下执行 make test。
注！一般情况下，我们可以在提交代码前执行make lint和make test来检查代码是否规范，测试功能是否ok。
1.3 编码规范和单元测试
编码规范需要遵循
Chromium Python Style Guide
.
源码中以_unittest.py结尾的文件被认为是单元测试模块
。
二、国家区域配置
像所的操作系统一样，CrOS支持用户可选的区域配置，包含键盘样式、语言、时区等。为了更好的体验，每个设备在发货的时候需要根据发货国家或区域进行相适应的配置。这些设置是通过RO VPD（read-only vital product data）的区域字段和cros-regions.json数据文件来管理的，下面我们来了解下Factory SDK如何管理这些区域配置的。
2.1区域和区域码（国家和国家码）
区域即设备发货的目标市场，同一个区域使用一个特定的keyboard布局、语言和时区。
每个区域是通过区域码（或国家吗）来定义的，如美国-us。
-
一个国家，如美国，对应的国家码参考 ISO 3166-1 alpha-2 code为两个字母，us；这里要说下UK的国家码是gb不是uk。
-
一个非国家的实体，如香港Hong Kong对应的是hk。
-
一个多国或国实体组织的联合体可以共享一个区域配置，如Hispanophone Latin American 拉美(包含墨西哥、哥伦比亚、秘鲁、阿根廷等），即为nordic。
-
一个国家或实体组织的部分也可具有特有的区域配置，如Francophone Canada即为ca.fr
当前CrOS通过region code来获取区域数据，如locales或Wi-Fi管理域。区域数据可以更新，但区域码本身是锁定在VPD RO中了。
2.2可用的区域
已定义已确定的：
已定义未确认的：
2.3键盘布局（输入法）
keyboards域是指输入法ID的列表。第一个是默认的。一般情况下，是与语言相匹配的。当指定了语言之后，只有该语言下可用的键盘才可以被设置。
每个keyboard的定义必须以xkb:、m17n:、ime:开头。截止到M38，可用的键盘布局包括如下：
-
xkb:... : XKB input methods listed in any file in JSON files in the Chromium src/chrome/browser/resources/chromeos/input_method directory. (Look for the id attributes of each input_components list entry.) For example, you will find xkb:us::eng in google_xkb_manifest.json .
-
ime:... : (M38+ only) Any hard-coded strings listed in kEngineIdMigrationMap in Chromium’s input_method_util.cc . Currently this is:
-
ime:zh-t:quick
-
ime:zh-t:pinyin (not yet supported as of this writing, but should be added in M38)
-
ime:ko:hangul
-
ime:ko:hangul_2set
-
-
m17n:... : (M38+ only) Strings with a prefix in kEngineIdMigrationMap . The prefix is rewritten according to the map, and there must be a corresponding input method ID in some file in the input_method directory. For instance, m17n:ar will be rewritten to vkd_ar according to the map. vkd_ar is present in google_input_tools_manifest.js .
2.4 时区
time_zone字段被用作默认时区。M35+以后的版本支持自动检测时区。
2.5 语言代码
2.6测试区域配置
当添加一个新的区域，我们需要进行测试来验证有效性，以确保用户的开箱体验（OOBE）。
那么我们需要运行py/110/regions_unittests.py文件或者在对应主板的目录下执行
overlay-
board
&&
overlay-
board
/py/l10/regions_unittest.py。
为了提高开箱体验，我们可以运行
py/experimental/oobe/region/run_region_oobe.py 脚本。该脚本会通过ssh工具到CrOS上，并根据command line来设置设备的VPD字段，然后运行OOBE流程。设备上需要load测试镜像，且factory 工具套件需要是disable状态。
举例：ssh到一个corsdev设备，然后测试公共层一个命名为xx的区域：
cd ~/trunk/src/platform/factory
py/experimental/oobe/region/run_region_oobe.py crosdev xx
或者私有层的区域：
cd ~/trunk/src/platform/factory
make overlay-private
overlay-private/py/experimental/oobe/region/run_region_oobe.py crosdev xx
2.7 Region API
class cros.factory.test.l10n.regions.Region(region_code, keyboards, time_zone, language_codes, keyboard_mechanical_layout, description=None, notes=None)
FIELDS = ['
region_code', '
keyboards', '
time_zone', '
language_codes', '
keyboard_mechanical_layout']，Region有这些字段来定义。
region_code = None//区域码或国家码
keyboards = None//输入法
time_zone = None//时区
language_codes = None//语言码
description = None//对应Region的描述性介绍
notes = None//对应Region的说明性介绍
GetFieldsDict()//返回实际字段对应的数据字典
cros.factory.test.l10n.regions.BuildRegionsDict() //该函数会返回所有定义好的区域数据字典，除了调用cros.factory.test.l10n.regions.REGIONS获取区域数据，一般情况下我们不直接调用
BuildRegionsDict函数。因为cros.factory.test.l10n.regions.BuildRegionsDict(include_all=False)会构建一个数据字典映射到py.l10n.regions.Region对象中。这些对象包含在cros.factory.l10n.regions.REGIONS_LIST中，如果include_all=True，则会包含cros.factory.l10n.regions.UNCONFIRMED_REGIONS_LIST，这些事已定义但未确认使用的区域。
A region may only appear in one of the above lists, or this function will (deliberately) fail.
二、Device Data设备数据
Device Data是一个数据集，用来封装DUT的生产信息。包含很多外设，如触摸屏；也包含很多预设信息，也就是所谓的VPD（Vital Product Data），如序列号，发货区域；同样包含测试状态如SMT是否pass，FATP是否pass还有其他站位状态。
Device Data在测试过程中是共享的，如Chrome OS Factory Software、Goofy、Shopfloor Service API。所有的这些数据都是来自预先定义的值、或Shopfloor backend还有测试过程中人工选择的或者从条码扫描器得来的。
我们可以把Device Data看做一个数据字典或者映射。如下主要字段包含：
-
serials : A dictionary for serial numbers of device, components, and mainboard. All serial numbers here will be logged by testlog, including:
-
serial_number : The serial number of “device” itself (printed on device panel).
-
mlb_serial_number : The serial number of main logic board (mainboard).
-
-
component : A dictionary to indicate what peripherals should exist, for example:
-
has_touchscreen=True : A touch screen should be available.
-
has_dram=2 : Two DRAM components should be available.
-
-
vpd : A dict for what VPD values need to be set, including:
-
ro : VPD values in RO section (RO_VPD), usually including:
-
rw : VPD values in RW section (RW_VPD), usually including:
-
ubind_attribute : User registration code.
-
gbind_attribute : Group registration code.
-
-
-
hwid : A value of probed Hardware ID.
-
factory : A dict for manufacturing flow control, used by shopfloor backends. See Shopfloor Service API for more details.
举例说明：
{
'serials'
: {
'serial_number'
:
'SN1234567890'
,
'mlb_serial_number'
:
'MLB1234567890'
},
'vpd'
: {
'ro'
: {
'region'
:
'us'
},
'rw'
: {
'ubind_attribute'
:
'12345'
,
'gbind_attribute'
:
'54321'
,
}
}}
使用Device Data的函数调用如下：
GetDeviceData
(
'vpd.ro'
)
GetDeviceData
(
'vpd.ro.region'
)
GetDeviceData
(
'vpd'
)
.
get
(
'ro'
)
.
get
(
'region'
)
GetDeviceData
(
KEY_VPD
)
.
get
(
NAME_RO
)
.
get
(
NAME_REGION
)
etDeviceData
(
KEY_VPD_RO
)
.
get
(
NAME_REGION
)
GetDeviceData
(
KEY_VPD_REGION
)
适应Serial Number（序列号）的函数调用
GetSerialNumber
(
'serial_number'
)
GetSerialNumber
(
NAME_SERIAL_NUMBER
)
GetSerialNumber
(
KEY_SERIAL_NUMBER
)
GetDeviceData
(
KEY_SERIAL_NUMBER
)
AIP定义：
cros.factory.test.device_data.CheckValidDeviceDataKey(key, key_prefix=None)
Checks if given key is a valid device data key.
Parameters:
key – A string of key for device data.
key_prefix – Key must start with this token.
Raises:
KeyError if the key is not valid.
cros.factory.test.device_data.GetDeviceData(key, default=None)
Returns the device data associated by key.
Parameters:
key – A string of key to access device data.
default – The default value if key does not exist.
Returns:
Associated value if key exists in device data, otherwise the value specified by default. Defaults to None.
cros.factory.test.device_data.GetAllDeviceData()
Returns all device data in a single dict.
cros.factory.test.device_data.GetDeviceDataSelector()
Returns the data shelf selector rooted at device data.
This is primarily used by invocation module to resolve TestListArgs.
cros.factory.test.device_data.DeleteDeviceData(delete_keys, optional=False)
Deletes given keys from device data.
Parameters:
delete_keys – A list of keys (or a single string) to be deleted.
optional – False to raise a KeyError if not found.
Returns:
The updated dictionary.
cros.factory.test.device_data.VerifyDeviceData(device_data)
Verifies whether all fields in the device data dictionary are valid.
Parameters: device_data – A dict with key/value pairs to verify.
Raises:
ValueError if the device data is invalid.
cros.factory.test.device_data.UpdateDeviceData(new_device_data)
Updates existing device data with given new dict data.
Parameters: new_device_data – A dict with key/value pairs to update. Old values are overwritten.
Returns: The updated dictionary.
cros.factory.test.device_data.GetAllSerialNumbers()
Returns all serial numbers available in device data as dict.
cros.factory.test.device_data.ClearAllSerialNumbers()
Clears all serial numbers stored in device data.
cros.factory.test.device_data.GetSerialNumber(name='serial_number')
Returns a serial number (default to device serial number).
cros.factory.test.device_data.SetSerialNumber(name, value)
Sets a serial number to give nvalue.
Parameters:
name – A string to indicate serial number name.
value – A string representing the serial number, or anything evaluated as False to delete the serial number.
cros.factory.test.device_data.UpdateSerialNumbers(dict_)
Updates stored serial numbers by given dict.
Parameters: dict – A mapping of serial number names and values to change. A value evaluated as False will delete the serial number from device data.
cros.factory.test.device_data.FlattenData(data, parent='')
An helper utility to flatten multiple layers of dict into one dict.
For example, {‘a’: {‘b’: ‘c’}} => {‘a.b’: ‘c’}
Parameters:
data – The dict type data to be flattened.
parent – A string to encode as key prefix for recursion.
Returns:
A flattened dict.
cros.factory.test.device_data.LoadConfig(config_name=None)
Helper utility to load a JSON config that represents device data.
Parameters: config_name – A string for name to be passed to config_utils.LoadConfig.
Returns: A dictionary as device data (already flattened).
cros.factory.test.device_data.UpdateDeviceDataFromVPD(key_map, vpd_data)
Update device data from VPD data.
Please see pytest read_device_data_from_vpd for more details. For both key_map and vpd_data, they should be a dictionary, with at most two keys: ‘ro’ and ‘rw’ (NAME_RO and NAME_RW). key_map[‘ro’] and key_map[‘rw’] should follow the format of ro_key_map and rw_key_map in read_device_data_from_vpd. If key_map is None, a default key_map will be used.
三、Factory Server
3.1Factory Server简介
Chrome OS Factory Server是一组运行在服务器上的软件的集合，该服务器被部署在工厂的生产线上。是DUT的唯一入口，Factory Server可以访问shopfloor backend，存储日志，同步系统时间还有其他相关的服务。
目前，server是一个Docker镜像(
https://www.docker.com/)，包含以下组件：
- [Dome](../py/dome/README.md), 可以用于访问服务器web前端
- [Umpire](../py/umpire/README.md), 提供镜像功能和局部升级功能，同时管理其他服务。
- [Overlord](../go/src/overlord/README.md), 远程镜像服务
- [Instalog](../py/instalog), 日志系统
- [DKPS](../py/dkps), 用管理秘钥配置的服务
3.2先决条件
通常情况下我们可以通过浏览器下http://locallost:8000地址访问服务器，我们可以通过在该地址下进行其他组件的配置。
工厂服务器可以运行在所有支持Docker（http://docker.io）的机器上，推荐配置如下：
最低配置：
- CPU: x86-64 CPU
- Memory: 2G
- Storage: 256G
建议配置：
- Memory: 16G
- Storage: 4T
- CPU: Intel Core i7 or Xeon E5 series or an faster x86-64 CPU
安装Docker
工厂服务器支持Windows、Linux、MacOS，推荐如下：
#### Linux Server
1. Ubuntu Linux 16.04.1 server](
http://releases.ubuntu.com/16.04/ubuntu-16.04.1-server-amd64.iso) (xenial).
2. 安装过程中，我们需要系统格式化磁盘为GPT，而不是MRB以求获得更大磁盘空间。
3. Docker 保存所有内容在`/var/lib`目录下，Chrome OS Factory Server服务器保存其数据在 `/cros_docker`目录下，所以我们要保证所在磁盘有足够的空间。最好的办法不要创建更多的分区，仅适用一个分区即可。
#### Mac OSX
1. 如果运行 factory sever 在Mac OSX, 则共享目录在`${HOME}/cros_docker` 下，而不是 `/cros_docker`, 如 `/Users/admin/cros_docker`.
#### Docker
1.在Linxu下运行sudo apt-get update && sudo apt-get install docker.io进行安装；并且可以通过访问(
https://docs.docker.com/engine/installation/)来获取帮助。
2.键入"docker version“可以查看当前Docker版本，确保版本不低于"1.10.3“
3.3安装配置Factory Server
###获取部署脚本
ChromeOS Factory Server组件是通过“cros_docker.sh”（./cros_docker.sh）来管理的，我们有三种选择来获取此脚本：
1.确保系统中已安装“crul”和“base64”
然后执行：
curl -L
http://goo.gl/gKCyo1 | base64 --decode >cros_docker.sh
sh ./cros_docker.sh update #修改脚本的执行权限，运行更新.
2.访问Factory 软件仓库
cd factory/setup#./cros_docker.sh位于此目录下
3.从CPFE中获取，如下；
脚本位于setup目录下
###下载安装Factory Server
1.运行./cros_docker.sh pull #如果服务器设备无法联网，拷贝cros_docker.sh和屏幕上显示的文件信息到目标机器上。
2../cros_docker.sh install
3../cros_docker.sh run
###更新配置脚本和服务器镜像
./cros_docker.sh update
四、Shopfloor 生产制造
4.1介绍
ChromeOS工厂软件平台未生产流程提供了完整的解决方案，但是有一些数据是需要ODM等生产厂商来提供的，如序列号、MAC地址、KSU信息等，包括追踪一台设备是否可以发布（发货）。那么这部分我们通常称之为Shopfloor System（制造信息系统），该系统有ODM厂商开发并安装在产线。那么该Shopfloor System必须包含ChromeOS Factory 软件平台。
不同ODM厂商可能实现Shopfloor所使用的技术不尽相同，如SQL database、web service、和通过CIFS进行数据交换。为了缩小集成成本和shopfloor实现的灵活性，Chrome OS Factory软件平台定义了一个shopfloor 抽象层，类似于anroid 的HAL层。我们称之为“Chrome OS Factory Shopfloor Service”简称为“shopfloor service”。
ODM和CM厂商通过实现和维护Shopfloor Service对应的接口，该接口会在后面详细介绍。且此部分的实现无需开源或提供给Chrome OS。该服务支持运行在所有操作系统(windows/linux/macos)的Chrome OS Factory Server上。DUT可以通过Chrome OS Factory Server内置的某些功能访问Shopfloor服务。
4.2网络技术
基本组件包含4个部分：
1.DUT即Chrome OS设备
2.Google Chrome OS Factory Server
3.Chrome OS Factory Shopfloor Service
4.ODM或者CM的Shopfloor Backend（真正意义上的有ODM或者CM开发实现的shopfloor system）
DUT和Google Chrome OS Factory Server相关联的代码的运行和维护是由Google Chrome OS来处理，而Factory Shopfloor Service和Shopfloor Backend相关代码的运行维护则是由ODM和CM来完成的。
为了方便开发，合作方会选择Google Chrome OS Factory Server同一服务器来运行Shopfloor Service。对于Google ChromOS Factory Server来说，只需要知道Shopfloor Service的URL地址即可。
4.3为Factory Server设置Shopfloor Service URL地址
Factory Server安装完成后，打开Dome web接口为Umpire设置shopfloor service url地址。
-
打开Dome UI（浏览器键入http://<dom_host>:8000）
-
登入并选择你的项目
-
在仪表盘的Services列表中找到shopfloor。
-
配置serviceUrl
-
点击DEPLOY进行部署
随后Umpire会自动把localhost翻译成“Docker host IP”。
4.4 Shopfloor Service API
Chrome OS Factory Shopfloor Service必须被实现为webservice。
Webservice可以支持XML-RPC(
http://xmlrpc.scripting.com/spec.html)和Nil Extension(
https://web.archive.org/web/20050911054235/http://ontosys.com/xml-rpc/extensions.php)的web service形式。默认端口是8090；
下面给出一段python实现的例子：
|
shopfloor_service.py
py:
import xmlrpclib
service = xmlrpclib.ServerProxy('
http://localhost:8090', allow_none=True)
print('Service Version: %s' % service.GetVersion())
service.NotifyStart({'serials.mlb_serial_number': '123'}, 'SMT')
|
Webservice也可以支持JSON-RPC(
http://www.jsonrpc.org/)或通过WSDL(
https://www.w3.org/TR/wsdl)实现的SOAP(
https://www.w3.org/TR/soap/)。使用JSON-RPC服务，当我们在Chrome OS Factory Software配置URL的时候需要添加一个前缀--'jsonrpc:"，形如"json:http://192.168.0.1:8090"。使用WSDL时，我们在Chrome OS Factory Software配置URL需要添加一个前缀--'wsdl:"，形如"wsdl:
http://192.168.0.1:8090"。
|
py:
from cros.factory.utils import webservice_utils
url = 'jsonrpc:
http://192.168.0.1:8090'
service = webservice_utils.CreateWebServiceProxy(url)
print(service.GetDeviceInfo({}))
|
如果通过WSDL+SOAP来实现Shopfloor Service，则会发现描述数据结构相当复杂，这是因为实际上他们是Generic Compound Types类型的。这里有一个特殊的方式可以帮助将输入参数和返回值进行JSON实例化，
|
py:
import xmlrpclib
from cros.factory.utils import webservice_utils
# Assume your real shopfloor service is here, and all its input and output
# must be JSON strings:
real_url = '
http://192.168.0.1:8090'
proxy = xmlrpclib.ServerProxy(real_url)
# The input is a JSON string. The output is also JSON, for example
# '{"vpd.ro.region": "us"}'
print(proxy.GetDeviceInfo('{}'))
# The webservice_utils provides 'json:' prefix to filter that.
url = 'json:
http://192.168.0.1:8090'
service = webservice_utils.CreateWebServiceProxy(url)
# Input is real variable, and output is real dict, for example
# {'vpd.ro.region': 'us'}
print(service.GetDeviceInfo({}))
|
4.4.1 Data Format数据格式：设备数据
设备数据是值Shopfloor Service功能调用返回的数据结构；DUT软件版本通过调用"GetDeviceData"和"UpdateDeviceData“来更新设备数据(../test/device_data.py)；
DeviceData基于FactoryDeviceData，出于隐私和性能上的考虑，额外包含一些不会回传给Shopfloor Service的域。
-
vpd: vpd域用于配置Vital Product Data，包含ro或rw两个子域；如vpd.ro.region用于配置发货国家所对应的国家码或地区码；Chrome OS设备需要遵循VPD Field Requirements( https://www.google.com/chromeos/partner/fe/docs/factory/vpd.html)来配置必须的VPD信息，如：
-
vpd.ro.region 国家码（组合了地区、时区、键盘配置和WIFI管理等信息）
-
vpd.rw.ubind_attribute "User"注册码
-
vpd.rw.gbind_attribute "Group"注册码
-
-
component: 一个用于定义SKU信息的可选域，用于标识一些特定的已安装的外围设备数量，使用下面格式的字段进行定义：
component.has_<peripheral_name> = True | # The DUT has exactly one that peripheral.
False | # The DUT doesn't have that peripheral.
<number>
举例如：component.has_camera = 2 #DUT有2颗camera。如果有一颗camer可以用component.has_camera = 1 或 component.has_camera = True;
提示：
没有必要在vpd域中定义device serial number(ro.vpd.serial_number)，因为该域会自动从serials.serial_number获取。
4.4.2 GetVersion（）函数
返回当前支持的协议版本号。
参数:
None
返回值:
A string for protocol version. "1.0" for current specification.
举例:
GetVersion() # Returns "1.0"
所有实现了这个定义的Shopfloor Service应返回字符串“1.0”
4.4.3 NotifyStart()函数
通知shopfloor backend，DUT当前已经进入生产站位（工位）；
参数:
- data: A struct FactoryDeviceData representing DUT information.
- station: A string (case-sensitive) as name of station.
返回值:
A struct DeviceData for values to update in the device_data.GetDeviceData.
举例:
NotifyStart({'serials.mlb_serial_number': 'C123'}, 'SMT')
# Returns {} and device_data.GetDeviceData('factory.start_SMT') is True.
典型的Chromebook 的 Shopfloor Service需要支持下面的站位（工位）：
-
SMT：Surface Mount Technology；表面铁桩技术工位测试，即贴片，用于验证主板。
-
FAT：Final Assembly Test；最终组装测试，即封板测试
-
RUNIN：Run-In；试运行测试；
-
FFT：Final Functional Test；包装之前的最终功能测试
-
GRT：Google Required Test；google 认证测试
对于有些项目不需要上面的测试工位的，可以直接pass或者返回空数据。还有一些项目需要选择性的添加额外的工位，那么他们就需要修改和维护这些自定义的测试列表。
当某个站位测试成功后，DUT会调用改API来自动设置DeviceData中的factory.start_<station>值为true。如"factory.start_smt = True";
4.4.4 NotifyEvent()函数
通知Shopfloor Backend，DUT执行了一个事件，该事件通常是指一个特定的检查点。
参数:
- data: struct FactoryDeviceData
- event: string (case-sensitive)
返回值:
A struct DeviceData for values to update in the device_data.GetDeviceData.
举例:
NotifyEvent({'serials.serial_number': 'A123'}, 'Finalize')
Returns {} and device_data.GetDeviceData('factory.event_Finalize') is
True.
当事件执行成功，DUT会调用改函数来自动设置对应事件的值为true（形如：factory.event_<event> = True），同样，该对应事件的key是factory.event_<event> 定义在DeviceData中。
一个典型Chromebook的Shopfloor Service的实现至少需要支持下面两个事件：
#### Finalize事件
DUT已经确认终版且恢厂等待发货，那么此时为Finalize事件。Finalize事件不包含隐私相关的字段，如MAC地址或者注册码等。如果厂商需要验证这些值，可以自定义相关测试项。
#### Refinalize事件
标识DUT被送往OQC（Outgoing Quality Control 出货质量控制），现在被送回进行重置和数据擦除，即恢厂。
同样地，“data”参数不应包含隐私信息，如MAC地址或者注册码等。如果厂商需要验证这些值，可以自定义相关测试项。
4.4.5 GetDeviceInfo()函数
获取DUT相关的配置信息；
参数:
- data: struct FactoryDeviceData
返回值:
A struct DeviceData for values to update in the device_data.GetDeviceData.
举例:
GetDeviceInfo({'serials.mlb_serial_number': 'C123'})
# Returns {'serials.serial_number': 'A1234', 'vpd.ro.region': 'us'}
该函数通过与backend shopfloor server进行通信，获取DUT设备配置信息，如VPD值和SKU等。
2.4.6 ActivateRegCode()函数
通知shopfloor backend，DUT设备已经成功配置了注册码（或者ECHO码）
参数:
- ubind_attribute: A string for user registration code.
- gbind_attribute: A string for group registration code.
- hwid: A string for HWID of the DUT.
返回值:
A struct DeviceData for values to update in the device_data.GetDeviceData.
举例:
ActivateRegCode('uuu', 'ggg', 'LINK A2C-B3D')
Returns {} and device_data.GetDeviceData('factory.activate_reg_code') is
True.
注册码应该被标记为“used”，并记录在shopfloor backend，然后回传给Google CPFE进行激活。由于涉及到隐私信息，该注册码不可以关联到序列号或者其他数据当中。所以该方法的设计与FactoryDeviceData没有任何关联。
4.4.7 UpdateTestResult()函数
发送指定的测试结果给Shopfloor Backend。
参数:
- data: struct FactoryDeviceData
- test_id: A string as identifier of the given test.
- status: TestState字符串（区分大小写）
- details: (optional) A struct to provide more details test results,
including at least one string member 'error_message' as message
reported from the error.
返回值:
A struct DeviceData for values to update in the device_data.GetDeviceData.
If a member 'action' is included, its value will be used to decide
how to proceed with testing flow.
举例:
UpdateTestResult(data, 'smt.type_c_left', 'PASSED') # Returns {}
UpdateTestResult(data, 'smt.type_c_left', 'FAILED',
{'error_msg': 'Unknown'})
# Returns {'action': 're-run'}
“TestState”在cros.factory.test.state中有定义（../test/state.py），status参数必须是下面的一种"PASSED,FAILED,SKIPPED,FAILED_AND_WAIVED"
Shopfloor也许会通过“DeviceData“的“action”和使用这些方法来标识DUT设备的下一个测试项。比如重新运行测试项、跳过测试项、中止测试项。
五、TestLists &&
PyTests
ChromeOS Factory Test Lists介绍
这部分主要介绍factory test lists，详细可参考“http://goto/cros-factory-test-list(http://goto/cros-factory-test-list)或者[JSON_TEST_LIST.md](./JSON_TEST_LIST.md)”
-
TEST LISTS
初始化阶段，test list ‘manager’会加载当前目录下的所有" *.test_list.json "文件。如果JSON文件定义为"tests”，那么该test list ID将会被导出为有效测试列表。执行命令“factory test-list --list”可以找到所有有效的测试列表（test lists）。执行命令“factory test-list <teste-list-id>”来激活对应的test list。
-
活动的测试列表（Test List）
正常情况下，活动的测试列表的ID保存在"/usr/local/factory/py/config/active_test_list.json"中。Goofy会通过该配置文件来首次尝试读取此ID。命令执行factory test-list <test-list-id>激活某个活动列表时，对应的id会保存到该文件当中去。如果没有配置活动的test list，则有两种方式来决定默认的test list。
1.ID-将会首先检查‘main_${model}’ ，通过命令"mosys platform model"来检查'${model}' 源自哪里。
2.有ID的测试项-如定义了“main”和“generic_main”
-
覆写激活的Test List
"setup/cros_docker.sh goofy try"允许开发者从本地源码运行工厂套件。那么，我们建议开发者在docker中，保存活动的测试列表到"/var/factory/config/active_test_list.json"。因为开发者电脑上的"py/config/active_test_list.json"将会使toolkit的构建更加容易。
六、List of Factory Tests（pytest）
这里通过factory的代码来介绍下所有可用的测试，如下：
|
pytest测试项 pytest name
|
description 测试项描述
|
|
测试DUT电源类型和状态
| |
|
测试加速度计
| |
|
测试加速度计校准标定
| |
|
测试基于加速度计角度
| |
|
测试音频播放功能
| |
|
测试录音和播放基本功能
| |
|
测试音频录制和播放效果
| |
|
测试音频功能
| |
|
使用音频设备测试音质
| |
|
测试显示背光
| |
|
通过运行磁盘检测指令验证存储设备
| |
|
测试DUT电池效果
| |
|
电池基本测试
| |
|
电池当前是否处于充电或放电状态
测试
| |
|
电池回路
测试
| |
|
硬件测试，包含电池是否在位及其基本的状态
| |
|
BFT fixture控制接口测试
| |
|
测试等待电池充电达到特定level
| |
|
蓝牙设备功能性测试
| |
|
使用hciconfig和hcitool.进行基于占位的蓝牙扫描配对测试
| |
|
LED和LCD背光亮度测试
| |
|
LCD背光模块功能测试
| |
|
LED亮度测试
| |
|
案件功能测试
| |
|
蜂鸣器测试
| |
|
无固定摄像头测试
| |
|
切换modem固件测试
| |
|
使用
Chameleon（
变色龙）工具进行自动化显示测试
| |
|
测试一定时间充放电的电池电量
| |
|
检测CR50固件的BoardID
| |
|
检测OS Image版本
| |
|
检查序列号设置是否正常
| |
|
指南针测试
| |
|
run-in 测试中倒计时监视器用户接口测试
| |
|
如果当前是一个白标设备，则写入cr50白标。
| |
|
显示功能测试
| |
|
显示功能测试
| |
|
显示面板功能测试
| |
|
扬声器校准测试
| |
|
以太网连接基本测试
| |
|
运行任意python脚本测试
| |
|
shell命令调用运行测试
| |
|
外部显示测试（音频播放可选）
| |
|
PyTest FactoryStateLayer控制协助测试
| |
|
CPU风扇功能测试
| |
|
使用fastboot flash进行镜像升级
| |
|
切换量产版本的封板测试
| |
|
Fingerprint sensor测试
| |
|
刷ap固件到网络引导固件
| |
|
允许在Android DUT上进行GPS芯片相关的测试和验证
| |
|
陀螺仪测试
| |
|
陀螺仪校准测试
| |
|
使用HWID v3来生成/编码和验证设备的硬件标识符
| |
|
测试测试中断次数是否超出预期
| |
|
键盘功能测试
| |
|
键盘背光测试
| |
|
贴片测试中进行键盘引脚连接的测试
| |
|
Uses ectool to control the onboard LED light, and lets either operator or SMT fixture confirm LED functionality.
| |
|
LID切换测试
| |
|
环境光感测试
| |
|
光感校准测试
| |
|
警示灯测试
| |
|
使用交互式shell脚本测试DUT
| |
|
验证LTE模块配置
| |
|
参考固件中的信息测试存储大小是否正确
| |
|
显示一条信息
| |
|
测试确认和设置KSU信息
| |
|
验证和关闭modem访问授权
| |
|
初始化也验证恢复模式内存测试
| |
|
等待网络连接操作
| |
|
空操作测试
| |
|
pytest offline_test.offline_test
| |
|
pytest offline_test.shell.deploy
| |
|
pytest offline_test.shell.fetch_log
| |
|
检查分区表是否延伸到存储末端，即覆盖整个磁盘。
| |
|
检查PD(TCPC)固件版本大于等于EC驱动中最小版本。
| |
|
Ping测试
| |
|
夹具USB type-C CC2功能测试
| |
|
检查USB type-C CC 线电极，反转操作测试
| |
|
USB type-c接口充电功能测试
| |
|
Tests USB type-C DP function with Plankton-Raiden, which links/unlinks DUT USB type-C port to DP sink. And with Plankton-HDMI as DP sunk to capture DP output to verify.
| |
|
pytest power_under_stress
| |
|
测试设备组件是否正常
| |
|
尝试从modem status中获取信息
| |
|
尝试从modem status中后去SIM卡信息
| |
|
SIM卡卡托测试
| |
|
从VPD中配置设备数据
| |
|
测试访问热插拔存储设备
| |
|
从U盘或factory server获取JSON配置文件
| |
|
从Factory server获取参数文件
| |
|
使用Graphyte.测试RF芯片负载能力
| |
|
控制机器人来测试特定感应器
| |
|
主板特定测试
| |
|
SAR金距离感应测试
| |
|
提示测试员输入字符串
| |
|
决定当前设备是否可以进行抽样测试
| |
|
检查DUT贴片测试的状态
| |
|
远程调用与shopfloor backend的交互
| |
|
开关机/重启测试
| |
|
空间传感器校准
| |
|
检查测试列表设置就绪
| |
|
开始或结束站位测试
| |
|
为站位测试设置站位
| |
|
执行命令持续对单个文件进行读写操作
| |
|
CPU/闪存/存储压力测试
| |
|
手写笔功能测试
| |
|
显示当前站位测试状态
| |
|
指定周期性挂起和唤醒设备
| |
|
连接工厂服务器查找可更新的固件，并上传日志
| |
|
时间同步
| |
|
平板电脑模式测试
| |
|
屏幕旋转测试
| |
|
热传感器负载响应测试
| |
|
热传感器测试
| |
|
处理器高低温测试
| |
|
检查和升级触摸设备固件
| |
|
验证触摸均匀性
| |
|
验证触摸功能
| |
|
触控板测试
| |
|
通过绘制各种图案来测试触摸屏和手写笔功能
| |
|
ouchscreen_calibration校准测试
| |
|
测试下次重启时清除TPM用户
| |
|
运行tpm_selftest进行TPM自我诊断
| |
|
验证TPM签名密钥
| |
|
更新Cr50固件
| |
|
测试更新Device Data
| |
|
执行ChromeOS固件升级，强制升级Main(AP)/EC/PD 固件
| |
|
更新Fingerprint MCU固件
| |
|
应用到新内核到DUT测试
| |
|
SKU ID和FW Config升级到
EEPROM
测试
| |
|
通过生成伪随机数进行cpu压力测试
| |
|
usb测试
| |
|
验证外设测试
| |
|
验证分区完整性
| |
|
pytest video_playback
| |
|
VSWR 验证传输效率
| |
|
VSync 引脚测试
| |
|
检测等待外部夹具测试结束
| |
|
验证夹具状态
| |
|
WebGL 性能测试（包含一系列WebGL相关操作）
| |
|
电压检测
| |
|
检查Whale’s cover开启/关闭状态
| |
|
从/sys/kernel/debug/ieee80211/phy*/ath9k/dump_eep_power
检测wifi校准表
| |
|
WIFI负载测试
| |
|
wifi连接基本功能测试
| |
|
测试无线连接
| |
|
写入设备数据到VPD
| |
|
测试写保护功能
|
扫一扫
3040
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
