Introduction
SPEED Certification Categories
Security Test
To detect, test and protect the RPM Distribution System, PlatformScience Customer and Platform from malware and system vulnerabilities.
Performance Test
To ensure efficient resource usage on deployed devices andsystem architecture.
Experience Test
To evaluate application reliability and ensure performance and interoperability does not degrade the Platform User Experience.
Efficiency Test
To test and measure connection bandwidth usage and protocols.
Documentation Review
To review accuracy, scope and completeness of application software documentation, including, without limitation, any application end user license agreement or other terms.
Speed Guidelines
1. SECURITY TEST
Security Test guidelines preserve the integrity of the RPM Distribution System, Platform ScienceCustomer and Platform. A customer purchasing an application expects it to be secure and free of malware and system vulnerabilities. Submitted applications need to adhere to the following guidelines.
• Data Protection. Applications should take necessary precautions to ensure data is being transmitted securely through the cloud. This includes encrypting sensitive data like PII (Personally IdentifiableInformation).
• Unauthorized Use. Applications must clearly indicate how it plans to use data that is collected from the user and needs to ask for explicit permission to collect data on behalf of the user. Data that is collected and used in a manner not prescribed by the End User License Agreement (EULA) and/or used by a third party not identified in the agreement will be grounds for removal from the Marketplace.
• Malicious Behavior. Applications that steal data, monitor users without permissions or are otherwise malicious arenot permitted. This includes spyware, trojan horses, malware, or applications that download anexecutable other than from the RPM enabled Marketplace.
• Denial of Service. Submitted applications must take precautionary measures to prevent distributed denial-of-service (DDoS) attacks. Users found to be in violation of the aforementioned terms will have access revoked. Revoked users can request further explanation via the developer portal.
• Unauthenticated Users. Applications operating on the Platform Science platform must only allow authenticated users to access functionality within the application. Unauthorized uses should not be permitted to access any part of the application. We require the use of the Platform Science mobile authenticationSDK.
• User Data Isolation. Protect user privacy and data. Often times, there will be shared devices where multiple users can authenticate into the same device. When one user logs out, make sure the new user does not have access to previous user data.
• Fingerprint Keys. Presence of a developer signing key or certificate, paired with the application package name, will be tested for to ensure that a specific build was generated for the Platform and will function on a Platform Science tablet enabling access to local SDK APIs.
2. PERFORMANCE TEST
• Hardware Compatibility. Ensure the submitted application works with the list of currently approved Platform Science tablets. Current list available upon request.
• Software Compatibility. Platform Science routinely evaluates and upgrades the operating system on the tablets. The current version of Android supported is Android 8. Please ensure your application utilizes the features that are available on the current certified version of Android. In certain instances, backwards compatibility will also be required.
If you are submitting a web application, ensure it works with the latest version of the relevant browsers (Chrome, Edge, Firefox, Safari)..
• Beta Versions. Submitted applications should be a “final release” candidate and not include demo or beta versions of your software. The application may have the ability to provide a trial period that gives customers the ability to evaluate your software.
• Background Applications. There are certain instances where running applications in the background is a requirement to ensure the right experience. Apps that are found to take undue advantage of this provision will be asked to re-evaluate the need to run in the background.
• Additional Downloads. Applications deployed via RPM may not prompt the user for additional download or install additional features over-the-air (OTA).
3. EXPERIENCE TEST
• Accurate Descriptions/Metadata. Submitted applications must include relevant descriptions and additional metadata that accurately describes the application and the value it provides to the customer. Do not falsely associate your brand with other brands unless you have prior written approval. Additionally, please provide a list of Platform Science SDKs that are being used. (Full list of available SDKs is available as part of developer documentation)
• Overall Experience. Platform Science users want a consistent experience as they move through different applications on the device. These applications are used in a vehicle. Be mindful of that when building your application experiences. We understand your brand is unique and want to enable that without compromising the overall user experience. When possible, ensure you meet the brand experience guidelines found below.
• Unwanted Actions. Applications may never prompt the user to restart the device or suggest changes to the core settings of the tablet. For example, do not suggest users to turn off Wi-Fi, Bluetooth, etc.
• Locked Content. Applications may not display content that is partially visible or “locked” that requires the enduser to make in-app purchases and/or payments.
• Versions of Applications. Users must have a seamless way of upgrading to the latest version of the application and should not be able to inadvertently subscribe to multiple versions/instances of applications within the same device.
• Advertising. Advertising in the applications is not permitted (own upgrades or other company apps).
• Intellectual Property. Submitted applications that infringe on the intellectual property of others are not permitted.
• Compliance and HOS Rules. Submitted applications must respect local, state and federal laws as they relate to operating your application within certain Duty statuses.
• Notification Spamming. Often times, drivers will use applications while they are driving. Be judicious in popping up notifications to the user.
• In-App Purchases. Unless provided prior written approval, applications may not require in-app purchases in order to complete a transaction or view content. If you want to provide the ability to unlock features or provide additional functionality, this must be handled outside the app experience via a signed contract executed by the customer.
• Opening Browsers. Unless prior written approval is obtained, apps may not require the use of browsers (embedded or otherwise) to display content. Provide a uniform experience within the application itself.
• Application Icons. Ensure the submitted application icon accurately represents your application. Do not reuse or modify app icons used by Platform Science or other apps/extensions in the marketplace.
4. EFFICIENCY TEST
• Data/Bandwidth Usage. Applications must use data/bandwidth within reasonable amounts. If your application needs large bandwidth requirements, then prior written approval is needed.
• Loss of Connectivity. There are instances when the device will be out of network coverage. Your application must be designed to provide graceful degradation when in an area without full coverage. In addition, your application must pick up seamlessly when connectivity is available.
• Power Efficiency. Design your application to use power efficiently and be used in a way that does not damage the device. Applications are not permitted to rapidly drain the battery, generate excessive heat or put unnecessary strain on system resources.
• Restricted Content. Applications that include content that is not acceptable (pornography, extreme violence, etc.)will be subject to immediate removal from the Marketplace.
5. DOCUMENTATION REVIEW
Platform Science will review provided documentation to ensure completeness in the interest of maintaining a consistent Platform Science Marketplace experience.
• Completeness. Completeness is quantified as production-ready applications capable of integration. Make sure your documentation covers all application functionality and provides appropriate EULA, user guides, training materials, troubleshooting and customer care FAQs as appropriate for your application.
• Accuracy. Ensure your documentation reflects the current version of the application that is being deployed.
BEFORE YOU SUBMIT
After following the aforementioned guidelines, also complete these final tasks:
- Test the application for bugs and crashes.
- Deploy the application on a Platform Science approved device and check for issues.
- Remove all instances of “test” and “filler” content.
- Validate documentation is included and complete.
AFTER YOU SUBMIT
Once the application is submitted for review and Platform Science has acknowledged receipt of any supporting hardware, your submission will be in the review period. SPEED certification will commence once Platform Science has received all components required to fully replicate the usage of your application.
SPEED Certification Timing. Platform Science will generally provide results of the SPEED certification within 5 business days after the review process has started. However, if your application is complex, we will require additional time to process the SPEED certification. You will be notified of this via email.
Status Updates. The current status of your submitted application will be communicated to you via email and/orthe developer portal.
Expedited Review. If you have a critical timing issue, you may request an expedited process by contacting us
[email protected]. If we find you are abusing this option, we reserve the right to reject future expedite requests.
Rejections. Our goal is to make the SPEED certification process as transparent as possible and apply the guidelines presented fairly. If your application has been rejected, you will be provided with reasoning and steps that you can take to correct your app. If you would like to appeal the rejection, you may do so by contacting us
[email protected].
SUCCESS GUIDELINES
Adhering to the guidelines in this document provides a path to a successful app submission.Please keep the following overall success guidelines in mind.
- Keep your target customer (professional driver or back office personnel) in mind as you build your application user experience.
- Follow Android design principles and navigation patterns for applications.
- Preserve your app’s state when it goes into the background.
- Only ask for permissions that your app needs
- Only use the data that your app needs.
- When possible, limit excessive network bandwidth usage.
- Use high contrast designs that are clearly visible in low light conditions.
Copyright 2023, Platform Science, Inc. All Rights Reserved.
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or any computer language, in any form or by any third party, without the prior written permission of Platform Science, Inc.
The information and/or the products described herein are protected by the laws of the UnitedStates and/or other countries, including their laws on trade secrets, patents, trademarks, and copyrights. All information herein is subject to change without notice, and Platform Science, Inc.,hereby disclaims any express or implied warranties with respect thereto. Platform Science, Inc.,its affiliates and vendors shall not be liable for any damage caused to its products or any injury suffered by any person, either directly or indirectly, as a result of the use or repair of its products outside their intended use.
Platform Science is a registered trademark of Platform Science, Inc. in the U.S. and/or other countries. All other trademarks are the property of their respective owners.
1-5500-SPEED, Rev A
