Desktop Pairing App Changelog
To ensure the client app has received all data required to finalize the pairing process, the desktop pairing app now asks the client app to confirm that. This additional check is done at the end of the pairing process and ensures the device is successfully paired.
- On Oculus Quest devices the app starts the settings application if the device owner cannot be set due to Android user accounts preventing it. The user can then remove the accounts from within the headset, without having to open the settings application manually.
- In some cases, specific devices might not be able to automatically start the client app due to a restriction Android applies to applications that have never been visible to the user. To overcome the issue, the client app is now started at the end of the pairing process and is visible in the headset for a short period of time before it closes itself.
- In case an error occurs during the pairing of a device, the desktop pairing app now attempts to uninstall the client app.
- Some devices had a chance to raise errors when installing the client app while another ADB operation was running at the same time.
- On macOS, once the user was logged in and later closed the app, all further attempts to start the app had a chance to never progress past the loading indicator.
- Logging out failed in specific scenarios and resulted in a loading icon to be displayed until the user restarted the app.
- Additional details have been added to the logging to ease troubleshooting of potential issues.
- The model name for connected devices is now the same name that the web portal shows.
- On Windows, the machine could take a while to start up the updater once the user started it. Anti-virus software is blocking the start of the updater until it finishes scanning the file for viruses. The result is a longer wait, in which a user may attempt to start the app again before the self-update completed. As this sometimes crashed the app, the self-update process has been changed to not close the app until the update is started. Once it is running, the updater will ask the user to close the app instead.
- If the updater was started at the end of the app's shutdown process, the updater was unable to identify that the app is still running. This had a chance to fail the update process.
- 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.
- The app now updates itself in the background and notifies the user that they can restart the app with a button click to run the latest version. In case the user does not apply the update in the running session, the update is installed the next time the app starts up.
- Preview builds of the app can be used side-by-side with the regular version of the app.
- On Windows the app is now distributed via an installer/setup executable. Users can delete previous versions of the app once they have installed the new version.
- There can only be a single running instance of the app. The existing window is brought to the front when the user attempts to start another instance.
- The internals of the app have been adjusted to prevent silent warnings while the user is not yet logged in.
- On macOS the app sometimes crashed on startup while the user was logged out and an update to the app was available.
- The operating system version used for troubleshooting purposes on macOS was giving details about the Unix kernel instead of the macOS version.
- The user was not asked to log in again when the login session was no longer valid.
- Automatic error collection stopped after a specific error was encountered.
- Links to some knowledge base articles were outdated.
- 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.
- 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 now identifies itself as such in login sessions. This allows the web portal to display that the user is logged-in in the app, in contrast to being logged-in in the portal itself.
- 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.
- Installing the client app to specific devices failed because the device's temporary directory didn't exist yet.
- Reinstalling the client app on a device didn't correctly wipe the past app's data. This in turn prevented the new install from showing up on the web portal.
- When a device's client app was deactivated remotely via the web portal, it took up to 5 minutes for a new installation to that device to show up in the web portal.
- Various issues that can occur during the pairing process are directly recognized. Along with an explanation of the encountered issue comes an instruction on how to potentially resolve the issue. For selected issues a link to an article of the knowledge base is given, too.
- A connected device's title can be changed as part of a reinstall operation.
- The app checks for updates to itself and asks the user to update (manually).
- On macOS the app links to the support page from the help menu item.
- The versioning scheme used by both the client app and the 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 app and the client 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.
- The app asks to log in first, before showing the devices table. I.e. a short visible flicker of the table has been removed.
- The technology used for the app has changed. It supports older operating system versions on both Windows and macOS: Windows 10 version 1803 (April 2018 Update) or macOS version 10.11 (El Capitan) or later are required
- The size of the app has been greatly reduced on both Windows and macOS.
- On Windows the app supports the [WebView2 Runtime](https://developer.microsoft.com/microsoft-edge/webview2/). On PCs that do not have the WebView2 runtime installed yet, the older built-in WebView is used.
- The signed-in session displayed in the user's Account Settings page is able to list that a session is from the app.
- On macOS the crash details shown by the operating system have been significantly improved to help with troubleshooting.
- The app is sandboxed on macOS, bringing additional security to Mac users.
- Reinstalling the client app via the app works without having to uninstall the previous version. This change works around an issue on devices that have a bug in the Android internals, which required a factory-reset any time the client app should be reinstalled on affected devices.
- To ensure the device can't get into a state that can't be resolved, the app no longer allows canceling the (re)install to a device.
- Logging out of the app didn't always start the login flow again.
- The sign-in session of a previous run of the app was sometimes not utilized, despite it still being active. The user is no longer asked to log in again in this case.
- The app didn't recognize that the sign-in session was no longer valid and consequently didn't ask the user to log in again. Until the app was restarted, this resulted in (re)install operations failing at the very end and connected devices that were already paired to the platform failed to show the device's title.
- A connected device that is still booting up had a very small chance to cause the app to not update the devices list for a few seconds.
- On macOS the app didn't behave like a regular app. That included proper window shadows, the expected menu items like text cut, copy and paste as well as support for various shortcuts (including closing the window and quitting the app).
- The app had a small chance to crash on startup on specific Mac models.
- On VR devices that use a more modern Android version the app sometimes had issues pairing the installed client to the platform.