Platform management and maintenance

Major Upgrades

Major updates to Strivr in-headset software updates are available once every 3 months. These updates are made available by the Strivr account team to the customer for download, and can then be fed to the customer’s internal storage & distribution systems. Strivr will provide relevant release notes for customers to evaluate and assess new features and perform corresponding change management activities to adopt the changes.

Bug Fixes and Patches

As necessary, Strivr may provide bug fixes and patches to the existing Strivr Player upgrades depending on whether any issues are identified during the use and deployment of the in-headset software. These bug fixes / patches are released on a case by case basis and do not have a specific cadence. Strivr recommends the customer contact the account team or support team to report any issues.

Strivr recommends customers evaluate an in-headset Strivr software update every 3 months. Strivr provides relevant release notes for the customer to assess features as well as bug fixes to define whether an update meets their requirements. Customers are responsible for conducting their own internal testing and validation prior to distributing the software updates across their headset fleets.

Strivr recommends customers update to the latest released version of in-headset software for the most reliable experience. Any version older than 6 months / 2 major releases may not be supported by Strivr and may have issues connecting to the Strivr Portal and properly displaying content. Strivr recommends the customer work with the Strivr Account team to obtain the latest versions of Strivr in-headset software.

For customer-managed MDM deployment architecture, Strivr recommends customers leverage product provisioning functionality built into the respective MDM system to push and install Strivr In-headset software updates to their existing fleet of enrolled headsets.

For Strivr-managed MDM deployments, Strivr recommends the customers work with the Account and Technical teams to deploy the latest Strivr in-headset software updates on the existing headset fleet.

Because Strivr Player upgrades are available as APK files that can be downloaded from the Strivr Portal, Strivr recommends customers use the internal Android application deployment approach to upload and distribute upgrades to existing device fleets.

Alternatively, for VMware Workspace ONE UEM customers, this can be achieved via the following steps:

1. Use the Product Provisioning functionality within the Workspace ONE UEM console to embed Strivr Player as a product.

2. Within product provisioning, use the Internal Application Deployment capability to upload and deploy various versions of Strivr Player.

Note: Across AOSP devices, if these specific restrictions are enabled, one cannot use Product Provisioning based app installation within VMWare Workspace ONE to install an app on a device:

• Allow Non-Market App Installation

• Allow Modifying Applications in Settings

• Allow Installing Applications

• Allow Uninstalling Applications

Matching Player Version on Portal with Assigned Player Version on MDM

Because an MDM is a compliance tool that enforces an application assignment policy to devices, customers should ensure that the Player version assigned the default on the customer tenant in Strivr Portal matches the Player version deployed to the MDM. Here are two scenarios that can occur if the versions do not match:

• Player Version on Tenant higher than Player Version on MDM

  If the default Player version is higher than the version assigned on the MDM, and if the devices are enrolled in an organizational group where a lower Strivr Player version is assigned, the MDM enforces the lower Strivr Player version, uninstalling the higher version and installing the lower version. This will lead to the device losing its existing tenant registration and the device will need to be reprovisioned.

• Player Version on Tenant lower than Player Version on MDM

  If the tenant default Player version is lower than the version assigned on the MDM, and if the devices are enrolled in an organizational group where a higher Strivr Player version is assigned, the MDM enforces the higher Strivr Player version by upgrading the device Strivr Player version. Upgrade of versions maintains the device registration with the tenant.

Deleting or Downgrading Player on MDM

Downgrading or deleting Strivr Player from devices will un-register devices from the Strivr platform, requiring re-provisioning. Strivr recommends customers use caution before removing any Strivr Player deployment from the MDM app assignment section. If customers want to de-provision devices, it’s best to enterprise wipe specific devices and not remove the app assignment.

Assigning Strivr Player to dedicated assignment groups

Strivr recommends customers create dedicated assignment groups for Strivr Player upgrades as opposed to assigning the Strivr Player version to the entire organizational group (OG). This method alleviates potential mismatches in the existing and enforced Strivr Player version, as explained above. Strivr also recommends customers upload and assign Strivr Player versions within the specific organizational group dedicated to their existing fleet in scope for the upgrade. To facilitate easy management of multiple Strivr Player versions across different OGs, customers should not upload Strivr Player upgrades to the global OG, especially for use cases such as content reviews, IT testing etc.

Strivr recommends the customer follow the process explained below to handle in-headset software upgrades. Please keep in mind that the below is a best practice suggestion and customers can adopt their own version of this process based on their environment:

For customer managed MDM deployment architecture, the upgrade window for in-headset software is at the discretion of the customer. Strivr recommends customers perform these upgrades outside of business hours to minimize impact to the existing device fleet. However, software upgrades do not affect user experience as training content is locally downloaded and a user can go through a training experience while the updates are in process. Customers should note that if the MDM remotely installs the Strivr Player application the learners are going through a training session, the existing Strivr Player application instance will end and will be restarted to reflect the new session. In such scenarios, data from the existing training session can be lost. Thus, Strivr recommends customers conduct Strivr Player upgrades during the weekend.

While evaluating the updated Strivr Player version, Strivr recommends the customer keep the following considerations in mind:

1. User Experience: Strivr recommends the customer evaluate the highlighted changes in user experience and conduct corresponding change management procedures to ensure that the learners are informed of such changes ahead of time.

2. Cloud Connectivity: Strivr recommends testing the Strivr Player build for content downloads and telemetry uploads with existing or upcoming content releases, conducted within a stipulated throttling window.

In order for a customer to ensure that content can be downloaded and played on a headset, Strivr recommends that the minimum supported Strivr Player version for the content should be at least equal to the specific version of the Strivr Creator for 360 Video software instance upon which the content was authored. For example, If the content was authored on Creator version 1.92.22133.01, the minimum version of Strivr Player that customers should deploy to play this content should be 1.92.22133.01. Any Strivr Player version below this may not be supported for the content and may create issues.

For content authored by a customer’s in-house content development team, or a third-party content partner, Strivr recommends the customer communicate with the respective team to ensure that this criteria is met to avoid any issues

Note: Because Strivr Creator for Dialogue is a web-based application, upgrades do not follow the same versioning as Strivr Creator for 360 Video, customers should work with their Strivr account and technical team on defining a compatible Strivr Player version on their fleet.

Backward Compatibility

Once the customer upgrades to a new version of Strivr Player, content that was authored on a previous version of Strivr Creator for 360 Video should be compatible with the latest player version up to 6 previous Creator versions.

For content created with a version of Strivr Creator for 360 Video more than 6 behind the current version, content may not be compatible. In such instances, customers are recommended to republish the content via Strivr Creator for 360 Video. Strivr recommends the customer work with the Strivr support team if any such issues are encountered.

Training content is updated based on customer / business requirements (typically once per quarter on average). If the Strivr Content Solutions team engages with the customer to build content, the customer should work with the team in order to define a cadence for content updates.

For third-party content, the customer works with the specific content partner to define the cadence for updates.

• First-Party Content

  First-party content (content authored by Strivr) is natively pushed via the content management functionality of the Strivr Portal. For more details, please refer to Deploying Courses to Headsets.

• Third-Party Content - Customer Managed MDM

  For content created by third-party developers, depending on whether a customer leverages a self-managed MDM instance or Strivr-managed MDM instance, the core content files and their subsequent updates can be distributed to a headset device pool via the Android application distribution functionality within the respective MDM instance where devices are enrolled.

• VMware Workspace ONE - Third-Party Content Distribution

  Distribution of third-party content is managed in a similar way as Strivr Player updates and a user can leverage the Product Provisioning functionality within the Workspace ONE UEM console to embed the third-party content APK as a product. Within product provisioning, customers can leverage the Internal Application Deployment capability to upload and deploy the third-party content.

Based on the recommendation on the environment and device pools that should be maintained by the customers, Strivr recommends the following high-level process that can be followed by the customer to deploy any new content set to the device fleet. However, this is only a recommendation and the customer can adopt a nuanced approach based on their specific architecture:

When customers deploy a subsequent version of a content set, the headset only downloads the delta between the new and the old version. This is done to avoid repetitive downloads for the same files. This only applies to native/first-party content built with Strivr tools and does not apply to third-party content.

Strivr recommends that customers dedicate a specific device pool / location to review the content that is in testing and is being actively authored by the respective content partner team. Per the architecture recommendation above, this can be a part of the test fleet, or the pilot fleet.

Firmware updates occur infrequently. These updates are provided by the headset manufacturer and are coordinated between OEM, Strivr, and the customer. OS updates are infrequent and may include bug and security fixes.

For customer-managed MDM deployment architecture, Strivr recommends customers use functionality built into their MDM to upgrade firmware either via online or offline mechanisms using the firmware / software updater application available on the HMDs.

• Pico Headsets - Over-The-Air (OTA) Updates

  For Pico headsets including Pico G2 4K and Neo 3 Pro, Pico supports both online and offline updates. Online firmware upgrade packages typically involve a truly over-the-air update wherein the device connects to the Pico services directly to download firmware upgrades. Offline packages are provided to the customer via a file storage mechanism which needs to be either manually pushed to the device’s internal storage or remotely pushed and installed via compatible MDM platforms such as Workspace ONE UEM. Pico currently does not offer the capability to control (enable or disable) online upgrades via an MDM platform. The high-level process for updating the firmware on these devices using the offline upgrade approach is as follows:

  • Offline Upgrade Package Deployment via MDM

    Pico publishes an offline upgrade package to a specific firmware version which then is supplied to the customer as a zip package. This package can then be uploaded to the respective MDM instance and deployed remotely to a device enrolled against the instance.

    Please check with your Strivr account team or Pico to assess which firmware version update would be compatible with your headsets

  • Strivr Firmware Updater App - Custom Pico Firmware Version

    For Pico headsets provisioned by the Strivr operations team, the Strivr Firmware Updater comes pre-installed. This application is designed to expose a native android intent to an MDM application for triggering the deployment and installation of an over-the-air incremental package.

    The following exposed intent can be used to install the offline update using the Strivr Firmware Updater application:

    mode=explicit,broadcast=false,action=android.intent.action.MAIN,package=com.strivr.firmwareupdaterapp,class=com.strivr.firmwareupdaterapp.MainActivity,extraString=com.strivr.extras.FirmwareImagePath=/sdcard/Download/[Offline Update File Name].zip

  • Distribution via VMware Workspace ONE UEM

    To distribute offline upgrades via VMware Workspace ONE, customers can follow these steps:

    1. Within product provisioning, use the Files & Actions functionality to upload offline updates and configure the installation manifest mentioned above.

    2. Use the Product Provisioning functionality within the Workspace ONE UEM console to embed the offline firmware update product.

    3. Deploy the update to device pools segregated by Organizational Groups or Smart Groups.

  • High-Level Process

    Strivr recommends customers follow a staged approach for rolling out firmware upgrades, in a similar way, as done for Strivr Player software. Customers however, may choose to have a wider evaluation framework for assessing the changes of the updated firmware from a user experience, third party application compatibility and security perspective. This is explained in the diagram below:

    

For customer-managed MDM deployment architecture, the upgrade window for firmware upgrades is at the discretion of the customer. A user may not be able to use the headsets while these upgrades are being performed. Strivr recommends customers perform these upgrades during non-business hours for minimal impact and no disruption to existing business operations.

Strivr periodically pushes updates to various cloud services which govern functions such as device management, connectivity and health reporting, analytics, and content management. Such upgrades are directly pushed over the air by the Strivr engineering team without intervention by the customer.

Strivr aims to provide close to zero downtime and negligible brownouts. If an update requires downtime, Strivr provides advance notice to its customers. Strivr doesn’t have a fixed upgrade window for deploying these updates.