Compatibility Test Suite
How does the CTS work?
The Compatibility Test Suite (CTS) is a free, commercial-grade test suite, available for&. The CTS represents the "mechanism" of compatibility.
The CTS runs on a desktop machine and executes test cases directly on attached devices or an emulator. The CTS is a set of unit tests designed to be integrated into the daily workflow (such as via a continuous build system) of the engineers building a device. Its intent is to reveal incompatibilities early on, and ensure that the software remains compatible throughout the development process.
The CTS is an automated testing harness that includes two major software components:
The CTS tradefed test harness runs on your desktop machine and manages test execution.
Individual test cases are executed on the Device Under Test (DUT). The test cases are written in Java as JUnit tests and packaged as Android .apk files to run on the actual device target.
The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the CTS available for&. CTS Verifier provides tests for APIs and functions that cannot be tested on a stationary device without manual input (e.g. audio quality, accelerometer, etc).
The CTS Verifier is a tool for manual testing and includes the following software components:
The CTS verifier app that is executed on the DUT and collects the results.
The executable(s) or script(s) that are executed on the desktop machine to provide data or additional control for some test cases in the CTS Verifier app.
Figure 1.&How to use CTS
This diagram summarizes CTS workflow. Please refer to the subpages of this section starting with&&for detailed instructions.
Types of test cases
The CTS includes the following types of test cases:
Unit tests&test atomic units of code within the A e.g. a single class, such as java.util.HashMap.
Functional tests&test a combination of APIs together in a higher-level use-case.
Future versions of the CTS will include the following types of test cases:
Robustness tests&test the durability of the system under stress.
Performance tests&test the performance of the system against defined benchmarks, for example rendering frames per second.
Areas covered
The unit test cases cover the following areas to ensure compatibility:
AreaDescription
Signature tests
For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.
Platform API Tests
Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK&&to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling.
Dalvik Tests
The tests focus on testing the Dalvik Executable Format.
Platform Data Model
The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK&&package: contacts, browser, settings, etc.
Platform Intents
The CTS tests the core platform intents, as documented in the SDK&.
Platform Permissions
The CTS tests the core platform permissions, as documented in the SDK&.
Platform Resources
The CTS tests for correct handling of the core platform resource types, as documented in the SDK&. This includes tests for: simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources.
阅读(...) 评论()Android CTS(frome google)
时间： 09:53:57
&&&& 阅读：238
&&&& 评论：
&&&& 收藏：0
Compatibility Test Suite
How does the CTS work?
The Compatibility Test Suite (CTS) is a free, commercial-grade test suite, available for&. The CTS represents the "mechanism" of compatibility.
The CTS runs on a desktop machine and executes test cases directly on attached devices or an emulator. The CTS is a set of unit tests designed to be integrated into the daily workflow (such as via a continuous build system) of the engineers building a device. Its intent is to reveal incompatibilities early on, and ensure that the software remains compatible throughout the development process.
The CTS is an automated testing harness that includes two major software components:
The CTS tradefed test harness runs on your desktop machine and manages test execution.
Individual test cases are executed on the Device Under Test (DUT). The test cases are written in Java as JUnit tests and packaged as Android .apk files to run on the actual device target.
The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the CTS available for&. CTS Verifier provides tests for APIs and functions that cannot be tested on a stationary device without manual input (e.g. audio quality, accelerometer, etc).
The CTS Verifier is a tool for manual testing and includes the following software components:
The CTS verifier app that is executed on the DUT and collects the results.
The executable(s) or script(s) that are executed on the desktop machine to provide data or additional control for some test cases in the CTS Verifier app.
Figure 1.&How to use CTS
This diagram summarizes CTS workflow. Please refer to the subpages of this section starting with&&for detailed instructions.
Types of test cases
The CTS includes the following types of test cases:
Unit tests&test atomic units of code within the A e.g. a single class, such as java.util.HashMap.
Functional tests&test a combination of APIs together in a higher-level use-case.
Future versions of the CTS will include the following types of test cases:
Robustness tests&test the durability of the system under stress.
Performance tests&test the performance of the system against defined benchmarks, for example rendering frames per second.
Areas covered
The unit test cases cover the following areas to ensure compatibility:
AreaDescription
Signature tests
For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.
Platform API Tests
Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK&&to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling.
Dalvik Tests
The tests focus on testing the Dalvik Executable Format.
Platform Data Model
The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK&&package: contacts, browser, settings, etc.
Platform Intents
The CTS tests the core platform intents, as documented in the SDK&.
Platform Permissions
The CTS tests the core platform permissions, as documented in the SDK&.
Platform Resources
The CTS tests for correct handling of the core platform resource types, as documented in the SDK&. This includes tests for: simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources.
标签：原文地址：http://www.cnblogs.com/CoderTian/p/5975991.html
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！bects耳机中文怎么读？_百度知道
bects耳机中文怎么读？
我有更好的答案
碧池，，，，
憋死他耳机？这个耳机有点意思，呵呵
其他1条回答
为您推荐：
其他类似问题
耳机的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。Android中CTS的编译和使用_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Android中CTS的编译和使用
&&Android中CTS的编译和使用
阅读已结束，下载本文需要
想免费下载更多文档？
定制HR最喜欢的简历
你可能喜欢5050人阅读
Framework(MTK)（13）
& & 首先这里需要详细叙述一下标题中”监听Android CTS测试项解决方案“的需求。这里的需求是指我们需要精确的监听到当前CTS测试正在测试的测试项。
& & 因为我们知道CTS认证是获得Google推出的 Android 系统中 Android Market 服务的前提。CTS 兼容性测试的主要目的和意义在于使得用户在 Android 系统的应用过程中，有更好的用户体验，并展现出 Android
系统的优越特性；使得 Android 应用程序编写者更容易编写高质量的应用程序；充分展现 Android Market 的优势，让获得CTS认证的终端得到 Android Market 的使用许可。而我们在实际进行的CTS测试中并不是完全一帆风顺的，此时我们就需要掌握一些基本的CTS测试原理和流程。当然google已经开源了CTS Verifier测试工具的源码，从源码入手分析也是我们一个选择。
& & 三思而后行，通过研究和分析这里提供两个方案（这里以Accelerometer Measurement Test测试项为例）：
方案一：监听当前正在运行的Activity是否是Accelerometer Measurement Test测试项所处的Activity
方案二：监听当前测试项是否是Accelerometer Measurement Test测试项
一：监听当前正在运行的Activity是否为Accelerometer Measurement Test测试项所处的Activity
& & 这种方式看起来已经跟CTS Verifier测试工具没有什么关系了，因为我们这里监听的是Activity，那么如何监听当前正在运行的Activity呢；从源码中并没发现谷歌提供该接口（至少是我没有找到）。那么我们知道Activity管理师通过task栈进行管理的，而且通过不同的启动方式，Activity的栈也不是唯一的。但是如果我们能够得到顶层栈中栈顶Activity则就可以检测到当前处于活动状态的Activity。
& 当然谷歌这里已经开放了相关接口，我们先认识一下：
final ActivityManager am = (ActivityManager)mContext.getSystemService(Context.ACTIVITY_SERVICE);
List&RunningTaskInfo& list = am.getRunningTasks(1);
if (list.size() != 0) {
RunningTaskInfo topRunningTask = list.get(0);
ComponentName c= topRunningTask.topA
String packageName=c.getPackageName();
String className=c.getClassName();
android.util.Log.d(&ComponentName&,&packageName--&&+packageName+&--className--&&+className);
& 从上面的代码中我们可以取到顶层栈中栈顶topActivity的信息，该信息被封装在ComponentName中。那么此时是不是完成了需求呢？
答案当然是否定的。
& 因为我们要时时刻刻监听栈顶Activity，才能确定当前活动的Activity是我们需要监听的Activity，因此除了能够得到栈顶的Activity我们还需要监听Activity的切换，但是此时Android原生代码中并没有提供相关的接口，这个时候有人会想到可以使用线程或者服务反复的去判断栈顶Activity是否已经发生变化。当然这样是不可取的，因为我们还要考虑到该线程或者服务不会被系统回收。因此我们该如何去监听Activity的切换呢？
& 我们知道，Activity的切换无非有两种，第一种：启动或者创建一个新的Activity；第二种：唤醒后台运行的Activity。因此如果我们能够成功监听到启动或者创建一个Activity，或者唤醒Activity我们就基本完成了Activity的切换的监听。
& 在源码/frameworks/base/core/java/android/app目录下ActivityThread.java中为我们提供了这样一个方法来帮助我们完成对Activity启动、创建、销毁、暂停、停止，唤醒等生命周期的监听。
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, &&&& handling: & + codeToString(msg.what));
switch (msg.what) {
case LAUNCH_ACTIVITY: {
/// M: enable profiling @{
if ( true == mEnableAppLaunchLog && !mIsUserBuild && false == mTraceEnabled ) {
FileInputStream fprofsts_in = new FileInputStream(&/proc/mtprof/status&);
if ( fprofsts_in.read()== '3' ) {
Log.v(TAG, &start Profiling for empty process&);
mTraceEnabled =
Debug.startMethodTracing(&/data/data/applaunch&); //applaunch.trace
} catch (FileNotFoundException e) {
Slog.e(TAG, &mtprof entry can not be found&, e);
} catch (java.io.IOException e) {
Slog.e(TAG, &mtprof entry open failed&, e);
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER | Trace.TRACE_TAG_PERF, &activityStart&); /// M: add TRACE_TAG_PERF for performance debug
ActivityClientRecord r = (ActivityClientRecord)msg.
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER | Trace.TRACE_TAG_PERF); /// M: add TRACE_TAG_PERF for performance debug
case RELAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityRestart&);
ActivityClientRecord r = (ActivityClientRecord)msg.
handleRelaunchActivity(r);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case PAUSE_ACTIVITY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityPause&);
handlePauseActivity((IBinder)msg.obj, false, msg.arg1 != 0, msg.arg2);
maybeSnapshot();
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case PAUSE_ACTIVITY_FINISHING:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityPause&);
handlePauseActivity((IBinder)msg.obj, true, msg.arg1 != 0, msg.arg2);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case STOP_ACTIVITY_SHOW:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityStop&);
handleStopActivity((IBinder)msg.obj, true, msg.arg2);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case STOP_ACTIVITY_HIDE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityStop&);
handleStopActivity((IBinder)msg.obj, false, msg.arg2);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case SHOW_WINDOW:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityShowWindow&);
handleWindowVisibility((IBinder)msg.obj, true);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case HIDE_WINDOW:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityHideWindow&);
handleWindowVisibility((IBinder)msg.obj, false);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case RESUME_ACTIVITY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER | Trace.TRACE_TAG_PERF, &activityResume&); /// M: add TRACE_TAG_PERF for performance debug
handleResumeActivity((IBinder)msg.obj, true,
msg.arg1 != 0, true);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER | Trace.TRACE_TAG_PERF); /// M: add TRACE_TAG_PERF for performance debug
case SEND_RESULT:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityDeliverResult&);
handleSendResult((ResultData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case DESTROY_ACTIVITY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityDestroy&);
handleDestroyActivity((IBinder)msg.obj, msg.arg1 != 0,
msg.arg2, false);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case BIND_APPLICATION:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &bindApplication&);
AppBindData data = (AppBindData)msg.
handleBindApplication(data);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case EXIT_APPLICATION:
if (mInitialApplication != null) {
mInitialApplication.onTerminate();
Looper.myLooper().quit();
case NEW_INTENT:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityNewIntent&);
handleNewIntent((NewIntentData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case RECEIVER:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &broadcastReceiveComp&);
handleReceiver((ReceiverData)msg.obj);
maybeSnapshot();
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case CREATE_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &serviceCreate&);
handleCreateService((CreateServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case BIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &serviceBind&);
handleBindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case UNBIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &serviceUnbind&);
handleUnbindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case SERVICE_ARGS:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &serviceStart&);
handleServiceArgs((ServiceArgsData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case STOP_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &serviceStop&);
handleStopService((IBinder)msg.obj);
maybeSnapshot();
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case REQUEST_THUMBNAIL:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &requestThumbnail&);
handleRequestThumbnail((IBinder)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case CONFIGURATION_CHANGED:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &configChanged&);
mCurDefaultDisplayDpi = ((Configuration)msg.obj).densityD
handleConfigurationChanged((Configuration)msg.obj, null);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case CLEAN_UP_CONTEXT:
ContextCleanupInfo cci = (ContextCleanupInfo)msg.
cci.context.performFinalCleanup(cci.who, cci.what);
case GC_WHEN_IDLE:
scheduleGcIdler();
case DUMP_SERVICE:
handleDumpService((DumpComponentInfo)msg.obj);
case LOW_MEMORY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &lowMemory&);
handleLowMemory();
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case ACTIVITY_CONFIGURATION_CHANGED:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &activityConfigChanged&);
handleActivityConfigurationChanged((IBinder)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case PROFILER_CONTROL:
handleProfilerControl(msg.arg1 != 0, (ProfilerControlData)msg.obj, msg.arg2);
case CREATE_BACKUP_AGENT:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &backupCreateAgent&);
handleCreateBackupAgent((CreateBackupAgentData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case DESTROY_BACKUP_AGENT:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &backupDestroyAgent&);
handleDestroyBackupAgent((CreateBackupAgentData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case SUICIDE:
Process.killProcess(Process.myPid());
case REMOVE_PROVIDER:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &providerRemove&);
completeRemoveProvider((ProviderRefCount)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case ENABLE_JIT:
ensureJitEnabled();
case DISPATCH_PACKAGE_BROADCAST:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &broadcastPackage&);
handleDispatchPackageBroadcast(msg.arg1, (String[])msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case SCHEDULE_CRASH:
throw new RemoteServiceException((String)msg.obj);
case DUMP_HEAP:
handleDumpHeap(msg.arg1 != 0, (DumpHeapData)msg.obj);
case DUMP_ACTIVITY:
handleDumpActivity((DumpComponentInfo)msg.obj);
case DUMP_PROVIDER:
handleDumpProvider((DumpComponentInfo)msg.obj);
case SLEEPING:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &sleeping&);
handleSleeping((IBinder)msg.obj, msg.arg1 != 0);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case SET_CORE_SETTINGS:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &setCoreSettings&);
handleSetCoreSettings((Bundle) msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case UPDATE_PACKAGE_COMPATIBILITY_INFO:
handleUpdatePackageCompatibilityInfo((UpdateCompatibilityData)msg.obj);
case TRIM_MEMORY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, &trimMemory&);
handleTrimMemory(msg.arg1);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
case UNSTABLE_PROVIDER_DIED:
handleUnstableProviderDied((IBinder)msg.obj, false);
case REQUEST_ASSIST_CONTEXT_EXTRAS:
handleRequestAssistContextExtras((RequestAssistContextExtras)msg.obj);
case TRANSLUCENT_CONVERSION_COMPLETE:
handleTranslucentConversionComplete((IBinder)msg.obj, msg.arg1 == 1);
case INSTALL_PROVIDER:
handleInstallProvider((ProviderInfo) msg.obj);
if (DEBUG_MESSAGES) Slog.v(TAG, &&&& done: & + codeToString(msg.what));
/// M: ActivityThread log enhancement @{
if(!mIsUserBuild && isDebuggableMessage(msg.what)){
Slog.d(TAG, codeToString(msg.what) + & handled &
+ &: & + msg.arg1 + & / & + msg.obj);
& & 这里我们可以看到，我们可以通过监听LAUNCH_ACTIVITY和RESUME_ACTIVITY来判断Activity的切换，因此我们可以将通过在ActivityThread.java中将获得顶层栈栈顶Activity的方法在这里调用以实现我们的需求。
& & 那么这样是否能够完成我们的需求呢？
& & 答案依旧是否定的。即使我们能够编译通过，但是在我们测试观察log的时候，并不能得到当前处于活动状态的Activity。那么为什么会出现这种情况呢？
& & 通过观察log我们发现，这里我们需要GET_TASK权限，当然我们可以通过添加权限的方式，但这样有风险，那么有没有一个更可靠的方式呢。
& & 依旧是通过观察log，我们发现Android系统会使用一个ActivityClientRecoder类来记录Activity的信息，而这个类在ActivityThread中也得到了应用，因此我们可以通过得到ActivityClientRecoder的对象r来获得Activity对象，在通过Activity对象的getComponent（）来得到ComponentName的对象，在ComponentName对象中便封装了应用程序包名和当前处于活动状态的Activity。
& & 具体实现方式这里不再赘述。
& & 此外还有一种备用的方式，就是我们可以通过得到当前处于活动状态进程信息来判断当前处以活动状态的进程。
& & 实现方式如下：
final ActivityManager am = (ActivityManager)mAppContextImpl.getSystemService(Context.ACTIVITY_SERVICE);
List&RunningAppProcessInfo& list = am.getRunningAppProcesses();
if (list.size() != 0) {
RunningAppProcessInfo topRunningProcess = list.get(0);
if(topRunningProcess.processName.equals(&com.android.xx.xxxxx&)){
我们如何得到我们需要判断的那个Activity的名字呢，当然如果那个Activity是你开发定义的就无所谓了，如果不是，或者是第三方的APK，也没关系，google提供了一个工具可以对apk进行反编译，因此我们可以从反编译的AndroidManifest.xml文件中得到相关Activity的name。
访问：1203768次
积分：11296
排名：第1664名
原创：137篇
转载：77篇
译文：13篇
评论：141条
(2)(1)(9)(1)(3)(2)(13)(11)(9)(6)(8)(8)(6)(5)(14)(28)(89)(6)(1)(2)(2)(1)