# Version provided

# 1. Provide basic information for Apps

Perfect application information is a prerequisite for rapid approval. When each version of an App is submitted, you need to provide materials that meet the following requirements. If the information remains unchanged, such materials do not need to be submitted repeatedly.

# 1.1 Apps' name

Provide an accurate App name.

# 1.2 1.2 APK package of App

The size of the installation package shall not exceed 30M, and the disk usage after installation shall not exceed 40M

# 1.3 App icon

  • Size: 148*148px
  • Format: PNG
  • Shape: Right-angled square

# 1.4 Introduction image for App

  • Size: 320*360px
  • Format: PNG
  • Shape: Square
  • Quantity: 3-5 sheets

# 1.5 App profile

Description within 20 words

# 1.6 App details

Described the App in detail within 100 words. The description shall be consistent with the App's function; misleading users is strictly prohibited.

# 1.7 Update instructions

Please provide users with updated descriptions. In addition, please provide a detailed list of changes to help imoo perform tests.

# 1.8 Developer information

Provide the developer's accurate corporate information.

# 1.9 Contact

For user consultation and problem feedback, paid Apps are required to provide a service number or service hotline.

# 1.10 Instructions for App use

Please provide detailed instruction for the use of the App's features. This will be synced with the imoo customer service department and used to assist in user consultation.

# 2. Provide a disclaimer letter

It is strictly forbidden to release Apps which may violate the laws, administrative regulations and local rules and regulations of the country or region, and the App shall not infringe upon the interests of any third party. When the App is on shelf for the first time, please provide a disclaimer letter in accordance with the standard documents.

Disclaimer letter.docx

# 3. Provide test report

In addition to submitting an APK package that meets the review standards and related information of the App, in order to carry out the review of Apps in a quick manner, please refer to the following documents to provide test cases and test reports when submitting each version of the App.

Application test check table and standard V1.4.xlsx

If the App is on the shelf for the first time, you need to provide a server stress test report to ensure that the App's experience is normal when a large number of users are flooding the server, or else please give remarks on the reason when the information is provided, and ensure that the service can be used normally when the App is released.

Performance test report template V1.2.doc

For the test process, please refer to the following documents.

Application test process guidance.docx

# 4. Version provided

When the App is on the shelf or updated, please compress the basic information, test report, etc. of the App into a package and send it to developer@eebbk.com.

# 5. Audit criteria for App version quality

  • If the version of the submitted App for testing encounters such serious and unavoidable bugs as "A module is not available" in the blocked acceptance test, acceptance shall be suspended, and the submitted version for testing shall be directly rejected.
  • If there are five or more unavoidable problems in the basic functions of the initial version of the App, or if there are three or more unavoidable problems in the basic functions of the iterative version of the App, acceptance shall be suspended, and the submitted version for testing shall be directly rejected.

  • For Apps that have been rejected once, a new revised version will be accepted after two working days; for Apps that have been rejected twice, a new version will be accepted after four working days; for Apps that have been rejected three times, a new version will be subject to scheduling and waiting.

  • App rejection is informed by email notification, while normal acceptance feedback which is not included in such notification is mainly based on communication.

# 6. Additional notes

  • The APK versionCode provided each time must increase by +1 on the basis of the previous one.
  • Since there are multiple models of the watch, there may be differences in functions between models. As such, it is best to use an APK that is compatible with these differences and can be processed by reading the system model (android.os.Build.MODEL).
  • The APK packageName given each time cannot be changed.
Last Updated: 12/30/2020, 10:10:57 AM