@@ -118,7 +118,12 @@ After developing the custom logic for an accessibility extension service, you mu
```
## Enabling or Disabling a Custom Accessibility Extension Service
To enable or disable an accessibility extension service, run the following command:
You can enable or disable a custom accessibility extension service through the command line interface or the device settings.
**Method 1**: through the command line interface
Run the **hdc shell** command, then the following system command:
- To enable the service: **accessibility enable -a AccessibilityExtAbility -b com.example.demo -c rg**
- To disable the service: **accessibility disable -a AccessibilityExtAbility -b com.example.demo**
...
...
@@ -126,3 +131,9 @@ In the preceding commands, **AccessibilityExtAbility** indicates the name of the
If the service is enabled or disabled successfully, the message "enable ability successfully" or "disable ability successfully" is displayed.
**Method 2**: through the device settings
- From the device settings screen, access the list of installed extended services under accessibility.
If an extended service is not installed, it is grayed out, and "No service" is displayed.
- Select the target extended service, and toggle on or off the switch to enable or disable it.
- If you opt to enable a service, a security reminder is displayed. Wait until the countdown ends and then select the check box indicating that you are aware of and willing to assume the listed risks.
@@ -36,7 +36,7 @@ LocalStorage provides two decorators based on the synchronization type of the co
## Restrictions
- Once created, the type of a named attribute cannot be changed. Subsequent calls to **Set** must set a value of same type.
- LocalStorage provides page-level storage. The [GetShared](../reference/arkui-ts/ts-state-management.md#getshared9) API can only obtain the LocalStorage instance transferred through [windowStage.loadContent](../reference/apis/js-apis-window.md#loadcontent9) in the current stage. Otherwise, **undefined** is returned. Example: [Sharing a LocalStorage Instance from UIAbility to One or More Pages](#sharing-a-localstorage-instance-from-uiability-to-one-or-more-pages).
- LocalStorage provides page-level storage. The [GetShared](../reference/arkui-ts/ts-state-management.md#getshared10) API can only obtain the LocalStorage instance passed through [windowStage.loadContent](../reference/apis/js-apis-window.md#loadcontent9) in the current stage. If the instance is not available, **undefined** is returned. For the example, see [Example of Sharing a LocalStorage Instance from UIAbility to One or More Pages](#example-of-sharing-a-localstorage-instance-from-uiability-to-one-or-more-pages).
## \@LocalStorageProp
...
...
@@ -300,9 +300,9 @@ struct CompA {
```
### State Variable Synchronization Between Sibling Nodes
### Example of Syncing State Variable Between Sibling Components
This example shows how to use \@LocalStorageLink to create a two-way synchronization for the state between sibling nodes.
This example shows how to use \@LocalStorageLink to create a two-way synchronization for the state between sibling components.
Check the changes in the **Parent** custom component.
...
...
@@ -377,7 +377,7 @@ Changes in the **Child** custom component:
```
### Sharing a LocalStorage Instance from UIAbility to One or More Pages
### Example of Sharing a LocalStorage Instance from UIAbility to One or More Pages
In the preceding examples, the LocalStorage instance is shared only in an \@Entry decorated component and its owning child component (a page). To enable a LocalStorage instance to be shared across pages, you can create a LocalStorage instance in the owning UIAbility and call windowStage.[loadContent](../reference/apis/js-apis-window.md#loadcontent9).
// customCounter2 of the child component can also be initialized from the parent component. The value from the parent component overwrites the locally assigned value of customCounter2 during initialization.
@@ -16,24 +16,22 @@ The size attributes set the width, height, and margin of a component.
| height | [Length](ts-types.md#length) | Height of the component. By default, the height required to fully hold the component content is used. If the height of the component is greater than that of the parent container, the range of the parent container is drawn.<br>Since API version 9, this API is supported in ArkTS widgets.<br>Since API version 10, this API supports the calc calculation feature.|
| size | {<br>width?: [Length](ts-types.md#length),<br>height?: [Length](ts-types.md#length)<br>} | Size of the component.<br>Since API version 9, this API is supported in ArkTS widgets.<br>Since API version 10, this API supports the calc calculation feature.|
| padding | [Padding](ts-types.md#padding)\|[Length](ts-types.md#length) | Padding of the component.<br>When the parameter is of the **Length** type, the four paddings take effect.<br>Default value: **0**<br>When **padding** is set to a percentage, the width of the parent container is used as the basic value.<br>Since API version 9, this API is supported in ArkTS widgets.<br>Since API version 10, this API supports the calc calculation feature.|
| margin | [Margin](ts-types.md#margin)\|[Length](ts-types.md#length) | Margin of the component.<br>When the parameter is of the **Length** type, the four margins take effect.<br>Default value: **0**<br>When **margin** is set to a percentage, the width of the parent container is used as the basic value.<br>Since API version 9, this API is supported in ArkTS widgets.<br>Since API version 10, this API supports the calc calculation feature.|
| margin | [Margin](ts-types.md#margin)\|[Length](ts-types.md#length) | Margin of the component.<br>When the parameter is of the **Length** type, the four margins take effect.<br>Default value: **0**<br>When **margin** is set to a percentage, the width of the parent container is used as the basic value. When child components are laid out along the cross axis of the **\<Row>**, **\<Column>**, or **\<Flex>** container, the cross axis size of the child components and the margins add up to the total size of the container.<br>For example, if the width of the **\<Column>** container is 100, the width of the child component is 50, the left margin is 10, and the right margin is 20, then the actual horizontal offset of the child component is 20.<br>Since API version 9, this API is supported in ArkTS widgets.<br>Since API version 10, this API supports the calc calculation feature.|
| constraintSize | {<br>minWidth?: [Length](ts-types.md#length),<br>maxWidth?: [Length](ts-types.md#length),<br>minHeight?: [Length](ts-types.md#length),<br>maxHeight?: [Length](ts-types.md#length)<br>} | Constraint size of the component, which is used to limit the size range during component layout. **constraintSize** takes precedence over **width** and **height**. Learn [how the value of this attribute affects the width and height](#impact-of-constraintsize-on-widthheight).<br>Default value:<br>{<br>minWidth: 0,<br>maxWidth: Infinity,<br>minHeight: 0,<br>maxHeight: Infinity<br>}<br>Since API version 9, this API is supported in ArkTS widgets.<br>Since API version 10, this API supports the calc calculation feature.|
|width/height|In the case of maxWidth/maxHeight > minWidth/minHeight, the layout logic of the component is used,<br>and the result is between maxWidth/maxHeight and minWidth/minHeight.<br> In other cases, the result is max(minWidth/minHeight, maxWidth, maxHeight).|
> The value of **@tc.require** must start with AR/SR or issue, for example, **issueI56WJ7**.
- The following uses base_object_test.cpp as an example to describe how to compile a multi-thread test case:
- The following uses **base_object_test.cpp** as an example to describe how to compile a multi-thread test case:
```
// The test case file header comment and test case comment are the same as those in the single-thread test case example.
...
...
@@ -345,9 +345,10 @@ The test framework supports multiple types of tests and provides different test
The procedure is as follows:
1. Add comment information to the test case file header.
> **NOTE**<br>The standard is the same as that of the single-thread test case.
> **NOTE**
>
> The standard is the same as that of the single-thread test case.
2. Add the test framework header file and namespace.
```
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h>
...
...
@@ -364,9 +365,11 @@ The test framework supports multiple types of tests and provides different test
class AAFwkBaseObjectTest : public testing::Test {......}
```
> **NOTE**<br>The standard is the same as that of the single-thread test case.
5. Add implementation of the test cases, including test case comments and logic.
> **NOTE**
>
> The standard is the same as that of the single-thread test case.
```
// Step 1 Set the function to be tested to return the factorial result.
...
...
@@ -416,7 +419,9 @@ The test framework supports multiple types of tests and provides different test
// THREAD_ID is used to distinguish threads and starts from 0. You can also use a random thread ID by passing in RANDOM_THREAD_ID. In this scenario, each thread ID is unique.
// Add the multi-thread API MTEST_POST_RUN() to execute the previously registered threads in a unified manner.
```
> **NOTE**<br>The comments for multi-thread test cases are the same as those of single-thread test cases.
> **NOTE**
>
> The comments for multi-thread test cases are the same as those of single-thread test cases.
- About C++ test case templates:
...
...
@@ -590,7 +595,7 @@ The test framework supports multiple types of tests and provides different test
> - Use the **ohos_js_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
> - The file generated for the JavaScript test suite must be in .hap format and named after the test suite name defined here. The test suite name must end with **JsTest**.
...
...
@@ -861,7 +866,7 @@ The following provides templates for different languages for your reference.
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory. **preparer** indicates the action to perform before the test suite is executed.
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory.
...
...
@@ -1103,7 +1108,7 @@ Before executing test cases, you need to modify the configuration in **developer
> If HDC is connected to the device before the test cases are executed, you only need to configure the device IP address and port number, and retain the default settings for other parameters.
...
...
@@ -1115,7 +1120,7 @@ Test cases cannot be built on Windows. You need to run the following command to
>- **product-name**: specifies the name of the product to be compiled.
>- **build-target**: specifies the test case to build. **make_test** indicates all test cases. You can specify the test cases based on requirements.
...
...
@@ -1127,7 +1132,7 @@ When the build is complete, the test cases are automatically saved in **out/ohos
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
> The test report folder is automatically generated.
...
...
@@ -1372,6 +1377,7 @@ When GCDA data is available, you can execute the test cases as follows for subsy
run -tp partname
run -tp partname1 partname2
2. Before compiling the version, modify the compilation options. Add **-- coverage** to the **cflags**, **cflags_cc**, and **ldflags** options in the **build.gn** file of the involved subsystem.
ldflags = [ "--coverage" ]
...
...
@@ -1379,6 +1385,7 @@ When GCDA data is available, you can execute the test cases as follows for subsy
C++: cflags_cc = [ "--coverage" ]
**Recommended**: You can also refer to the mode for the window subsystem. For details, see the files in this [pull request](https://gitee.com/openharmony/window_window_manager/pulls/1274/files).
3. To execute coverage test cases, perform the following to install the dependencies:
1. Run the **sudo apt install lcov** command to install lcov.
...
...
@@ -1403,7 +1410,9 @@ When GCDA data is available, you can execute the test cases as follows for subsy
run -t UT -ss *Subsystem name* -tp **Part name** -cov coverage
run -t UT MST ST -tp *Part name* -cov coverage
Note: The **-cov coverage** parameter must be added to the preceding commands.
> **NOTE**
>
> The **-cov coverage** parameter must be added to the preceding commands.
6. Obtain the coverage report from the following paths:
