This project took a while to finish since Omaha is also an installer/meta-installer and we had to rework several of our installation flows to make it all work well. Since Omaha is an out-of-process updater, if we shipped a completely broken client we could still update it. So we decided it was time to move our auto-update mechanism out of the main app.īack in 2014, we accomplished this on Windows by taking Google’s Omaha project and adapting it to our needs. Eliminating these potential failures was crucial to maintain continuity of Dropbox’s value to its users. More importantly, it also meant that small bugs in other parts of the client could affect auto-update. This meant that the client had to be running in order to update itself.
Basically, as part of regular file syncing, the server can send down an entry in the metadata that says, “Please update to version X with checksum Y.” The client would then download the file, verify the checksum, open the payload, replace the files on disk, restart the app and boom! It would be running version X.
Our auto-update system, as originally designed, was written as a feature of the desktop client. It allows our developers to rapidly innovate, showcase new features to our users, maintain compatibility with server endpoints, and mitigate risk of incompatibilities that may creep in with platform/OS changes. Keeping users on the latest version of the Dropbox desktop app is critical.
