1# Review Application for the <ApiName\> API in the OpenHarmony <SubsystemName\> Subsystem 2 3## Background 4 5* API type: [Public API | System API | Test API | HDI] 6* API requirement source: 7* API usage scenario: 8* Belonging subsystem: 9* Expected API release version: 10* Contributor: 11* Number of APIs involved in this review: 12 13| Change Type| Quantity| Programming Language| 14|---|---|---| 15| Added| | | 16| Behavior changed| | 17| Deprecated| | | 18| Deleted| | | 19 20## API Description 21 22### Necessity of the Changes 23 24> Based on the as-is and gap analysis, describe what the application scenarios and benefits of the APIs are. 25 26### Feature Overview 27 28> Describe features implemented by the APIs. 29 30## Review Conclusion 31 32### Review Conclusion from Committers 33 34### Review Conclusion from Domain SIGs 35 36## Self-Check Table 37 38| Self-Check Item| Self-Check Result| 39|---|---| 40| Is the spelling check completed?| | 41| Are coding specifications complied with?| | 42| Are parts of speech (noun, adjective, adverb) used correctly?| | 43| Does the API name fully describe the API logic?| | 44|Is the number of API parameters appropriate? (Generally, there should be fewer than 7 parameters.)| | 45|Are abbreviations properly used? (Abbreviations used should be well known.)| | 46|Is it really that the caller of a void API does not need a return value?| | 47|Is the inheritance system appropriate? Does every method of a parent class apply to its child classes?| | 48|Are all possible error states included and defined?| | 49| Is the group of antonyms used correctly, for example: <br/>add/remove, create/destroy, insert/delete, start/stop, begin/end,<br/>send/receive, up/down, show/hide, open/close, source/target,<br/>source/destination, increase/decrease, first/last, next/previous| | 50|Are the description and semantic hierarchy of new APIs consistent with those of existing APIs in the same module?| | 51| Are asynchronous counterparts needed for synchronous APIs?| | 52| Are all the public APIs truly required by developers?| | 53 54## API Description 55 56> Enter the code commit address. 57 58* Code address: 59 60## API Permission Design 61 62> Specify whether developers need to apply for certain permissions to use the APIs. 63 64## API Privacy Protection Design 65 66> If user privacy data is involved, privacy protection must be considered. 67 68## Developer Guide 69 70> Optional. 71 72## API Code Example 73 74> Select either of the following: 75 76* Code address: 77* Code snippet: 78 79## API Updates 80 81> Only required for existing APIs. 82 83### Behavior Change 84 85> The API behavior change indicates that the API only has its behavior changed. 86> The new API behavior must be released in a new version. You should not change the API behavior without releasing a new version (except for defect rectification). 87 88#### Related APIs 89 90#### Reason for the Change 91 92### Deprecated APIs 93 94> Add the `@deprecated` annotation to the description of deprecated APIs (including JS, TS, C, and C++ APIs). 95 96#### Related APIs 97 98> State the version from which the API is annotated by `@deprecated`. 99 100#### Reason for Deprecation 101 102#### Substitute APIs 103 104> List the APIs provided to substitute the deprecated ones. If there are no substitute APIs provided, describe the reason. 105 106### Deleted APIs 107 108> An API can be deleted only after five API versions have been released since it is marked as deprecated. 109 110#### Related APIs 111 112#### Reason for Deletion 113 114#### Substitute APIs 115 116> List the APIs provided to substitute the deleted ones. If there are no substitute APIs provided, describe the reason. 117 118## DFX 119 120### Compatibility 121 122### Performance 123 124### Power Consumption 125 126### Reliability 127 128### Testability 129 130> Automatic API test cases must be delivered for all APIs. 131 132## Review Conclusion 133 134* Reviewed on: 135* Reviewers: 136* Review conclusion: [Pass | Fail] 137* Review meeting minutes: 138