Client App Changelog
- Oculus devices can now access Bluetooth settings from the multi-app launcher.
- Oculus devices can once again access Wi-Fi settings from the multi-app launcher.
- Navigating to the Wi-Fi or casting settings from the multi-app launcher resulted in the started app to be rendered incorrectly on Pico Neo 3.
- On Pico Neo 3 the multi-app launcher was not closing the app launch animation once the user returned to the launcher.
- Apps that come with .obb files were visible in the headset too early, before the .obb files were installed completely. If the headset user started these apps during that time, the apps failed to launch if they required the .obb files.
- Wi-Fi network configurations can be managed via the web portal. Users can still add and remove their own networks inside the headset, but changes to the configurations managed by the platform are prevented.
- Support for version management has been added: Users can now select the app version to deploy to their devices via the web portal. As part of this feature, users can now downgrade apps to earlier versions.
- Apps can now be installed if the build archive is a Zip64 archive. Previously these installations gave an error instead.
- To enable version management, apps are now automatically downgraded to an earlier version, if that's the version set to deploy to the device according to the web portal. Previously, devices were able to have side-loaded app versions installed that were greater than the version marked for deployment in the web portal. Users who intend to side-load different app versions (compared to what they have set in the web portal) should remove the app from the device in the web portal to prevent the client app from managing that app.
- Opening the casting options via the multi-app launcher on Oculus devices resulted in a black screen. The casting option has been removed on these devices.
- The device status was not updated while removable storage was attached to the device. Because the operating system does not provide insight into the remaining/used space of removable storage, removable storage is no longer reported as part of the device status.
- On Pico Neo 3 the multi-app launcher was rendering in portrait orientation, instead of the desired landscape orientation.
- Especially after a reboot while in multi-app launcher mode, the Pico Neo 3 had a chance to render the launcher and other 2D apps incorrectly (as if they are VR apps).
- When starting the multi-app launcher on Oculus devices, the operating system asked to switch to controllers. Hand tracking is supported on these devices again.
- The device serial is displayed in the multi-app launcher.
- The multi-app launcher displays a welcome page when the app is not set as the device owner.
- Under specific circumstances the app had a chance to crash on startup.
- Session analytics events had missing version information for the running app if the app was uninstalled shortly after it was running. As version information is required, no further events were transferred to the platform, but affected devices have been recording new events in the meantime. These devices will send all data as soon as they update to this Client App version.
- Hidden files as well as macOS resource forks were not ignored properly, leading to app installation errors.
- The Tobii User Calibration app was visible in the multi-app launcher even on device models that don't support eye tracking.
- Support for a file-based approach to configure the Client App has been added.
- To support other ways to install the app besides using the Desktop Pairing App, the Client App now automatically grants itself all required runtime permissions at startup.
- On Pico devices the multi-app launcher allows access to the Tobii User Calibration app.
- Attempting to open the casting options a second time crashed the multi-app launcher.
- On devices that support casting functionality, the multi-app launcher now includes access to the casting options.
- Apps managed via the web portal will appear first in the multi-app launcher.
- Apps that were uploaded as a zip from macOS failed to install if the OS included resource forks (found in a nested `__MACOSX` folder) for the archived files. Resource forks as well as hidden files (i.e. files that start with a dot in their name) are now ignored.
- In the rare edge case that stored information from a previous run of the app was corrupted, analytical insight was no longer recorded nor reported.
- Attempting to reboot the HTC VIVE Focus Plus while in kiosk or multi-app launcher mode didn't work.
- Additional details have been added to the logging to ease troubleshooting of potential issues.
- On some devices accessing Wi-Fi settings in the default home app failed when the launch method was either set to kiosk mode or multi-app launcher.
If the device was using kiosk mode or multi-app launcher, it failed to allow the default home environment to run and instead repeatedly tried to start the kiosk mode app/launcher.
Reduced the number of check-ins with the platform down to one.
Workers running inside the app failed to properly cancel and instead ran work multiple times.
- Details about when the device was started or stopped, as well as insight about the running applications are now recorded (even while the device is offline). The collected information is then reported to the platform to allow the user to view detailed session analytics in the web portal.
- Content that has been installed by the app previously, but has since been deleted from the platform, is now left as is and is no longer uninstalled.
- The app now regularly checks in at the servers in an optimized manner, letting the whole platform know when the device was last seen. The web portal uses this information when displaying the last status of the device, and the aforementioned analytics feature also uses the gained insight for session details.
The number of possible concurrent downloads has been increased.
- Whenever the files assigned to the device didn't actually change, the retrieval of the latest files list resulted in unnecessary checks.
- Deleting a device from the web portal didn't reset the device back to the default launch method.
- The app could crash in very specific and rare edge cases.
If an operation was canceled, the next attempt to repeat the same operation waited for the canceled operation to finish. In some cases this resulted in content installation getting stuck in the "pending" state according to the web portal.
- File management wasn't working and gave permission errors on devices running Android 10.
- On devices running Android 10 or later, the app stopped reacting to changes done in the web portal if file management failed.
- File support has been added. File operations work similar to content operations and status is reported to the user the same way via the portal. For more information on file support see this article.
- Additional measures have been added to ensure the persisted data is not corrupted even if the device shuts down unexpectedly.
- The configured launch method is enforced repeatedly in the background on devices that allow access to the device's home app.
- Automatically set the date and time. Users are still able to change their time zone if the device normally offers that functionality.
- When using external storage like an SD card, the client app no longer reported device health/status information.
- Some devices required a reboot of the device to apply self-updates to the app. Until then the app was no longer working. A potential fix has been applied and we continue to monitor the issue.
- The multi-app launcher no longer shows apps that cannot be started on their own. This includes apps like some video players, as they require pointing it to a file to view. Such apps are often instead started by file managers. All configured apps continue to be added to the list of apps allowed to run, to allow the user to transition from a file manager to a viewer app.
- Upon device deactivation, if content uninstallation is desired, all content managed via the web portal will be uninstalled from the device, even if the content was originally installed by other means.
- When setting the launch method to multi-app launcher in combination with a third-party launcher, the app will no longer aggressively restart the launcher app whenever the user backs out of it. Since the launcher allowed the user to leave it, the app allows the user to navigate to apps in the allowlist as part of this change. This change allows users on Oculus devices to utilize the browser app (if that app is also included in the allowlist).
- The rate at which progress of .apk and .obb installation is reported has been reduced to improve performance slightly. This reporting is only used for internal purposes - the content status still updates in the web portal in a span of seconds.
- Improved reliability of local data persistence in the event of app crashes and/or unexpected device shutdowns and reboots.
- Automatic error collection stopped after a specific error was encountered.
- If a device updated the operating system to run a newer Android version, the app would cease to function. This was due to the app recognizing that new permissions are available in that Android version, which weren't granted to the app because it was installed when the device was still running the older Android version.
- In the web portal the version was reported as `2021.<Week number>` instead of the expected `2021.<Week number>.<Release that week>`.
- Checking for the currently running app was stuck in an infinite loop if it has been days since the current app changed.
- All apps now include detailed version information to ease the process of identifying development and QA builds. The user-facing versions are staying the same.
- When there's an issue reporting the progressing of a content installation, the app no longer fails the installation. The issue is ignored for intermediate progress, but completion status reports are retried indefinitely.
- The multi-app launcher treats small scrolling movement as clicks. This makes it easier to start apps with a controller's trigger or on devices that support hand tracking.
- Requests to the servers are retried only when encountering transient issues. Additionally a timeout has been added to help with connection issues. Previously all errors were retried, even if there was no chance for the next attempt to give a different result. This resulted in some operations taking longer than expected.
- The app did not acknowledge that it is starting to uninstall content. For content of bigger sizes, this resulted in the web portal looking like the device is not receiving the uninstall command, only to then suddenly mark it as uninstalled.
- This release is simply a re-upload of the previous build to overcome the content download issue that is hit by devices as part of updating to this release.
- The running app will now appear in the web portal as part of the device's status.
- The startup speed of the app has been improved slightly.
- The Wi-Fi Settings app is hidden inside the multi-app launcher on Oculus devices. The operating system does not correctly show the keyboard in the system Wi-Fi dialog on those devices.
- When content failed to download, the app didn't update the content's status correctly. Download errors are now visible in the web portal.
- Downloading builds of files that have spaces or special characters in the file name failed. Due to the aforementioned issue this would not be visible to users as part of the content's status in the web portal.
- To be more responsive when encountering connection problems, all communication with the servers is retried a few times. Previously the affected operations would only be retried ten seconds later (or even later, depending on the operation).
- Additional logging has been added to ease the process of diagnosing communication problems with the servers.
- Content that has been installed by the app previously, but has since been deleted from the platform, is now uninstalled.
- The multi-app launcher showed the app itself as content.
- For devices that provide information about the remaining charge time, the time was showing up as "0 minutes" in the web portal whenever the device wasn't charging.
- Content that has no available build yet wasn't ignored properly. The app will no longer repeat an error as the content install status.
- Content installation and uninstallation sometimes failed if a previous attempt at the same operation was canceled or failed.
- The multi-app launcher failed to start up automatically the first time after a device reboot on devices running newer Android versions.
- Failure to install or uninstall content was not recognized when the final step of the operation failed due to an issue in the Android internals.
- Content that has been uploaded as a zip failed to install.
- App data wasn't properly deleted when remotely deactivating the app.
- Device health data was not visible in the web portal for some devices running Android Oreo or earlier.
- All required permissions are checked on startup of the app. Previously this wasn't done and as such some silent failures of the installation via the pairing app resulted in failing functionality in the app.
- The versioning scheme used by both the app and the pairing app is more user-friendly. Both apps follow the scheme `Year-WeekOfYear-[FurtherRelease]` where `FurtherRelease` is an ever increasing number that is starting at `0` and is attached as a suffix to the original release of the same week. E.g.: A release in the first week of 2021 is `2021.1.0`. A release to fix an issue that is released in the same week will bump that version to `2021.1.1`, while any further release in the same week would result in `2021.1.2` and so on. The (first) release of the second week will use `2021.2.0`.
- The pairing app and the app now use the system's built-in networking technology, which ensures proper support for TLS 1.2 and other modern network communication standards.
- Logging has been improved to allow easier troubleshooting of issues. Additionally, if a crash occurs the details are collected the next time the application runs.
- A reinstall of the app to a device via the pairing app shows as a single progress. Previously the operation was split into two operations that each went from 0% to 100%.
- Background work done by the app is more optimized by introducing the concept of constraints. E.g. device health is only monitored when the device is active and online.
- The app only refreshes its authorization once whenever necessary. Previously there was a likelihood of multiple refresh operations being done at the same time.
- In kiosk mode the user stays in the primary app or the launcher when using the headset's back navigation functionality. Previously there was an animation to a black screen before the user was returned back to the configured app.
- When toggling off kiosk mode or toggling off the use of the launcher, the currently running app from the previous allowlist will no longer be stopped. The user can continue in it and won't potentially lose any progress. When the user attempts to quit the Kiosk mode content they will be taken back to it automatically. To allow quitting the kiosk mode app the launch method of the device must be changed in the web portal.
- On the Vive Focus the operating system version shown in the device's overview page is now matching what the Vive menu shows.
- The app sometimes got stuck and no longer did anything. Self-updating often triggered this issue, but sometimes content operations also triggered it. A device reboot often resolved the issue for a while, but when self-updating triggered the issue even that didn't help and a reinstall of the app was required.
- Failing background work in the app is retried repeatedly. Previously specific work only was attempted again after rebooting the device.
- The multi-app launcher was leaking (an insignificant amount of) memory whenever it was started.
- When the device went offline during content management, the current content status sometimes didn't display correctly in the web portal. The information is updated once the device goes back online.
- Some edge cases resulted in remote device deactivation working, but not acknowledging it correctly in the web portal. Once deactivated, the device is deleted as expected in the web portal.