Service notice

Companion Mode has been retired

A Google Messages update changed what an application must send in order to pair with a phone. The new requirement is not technical. It asks every third-party application to transmit a written acknowledgement that it is accessing an undocumented Google API without authorization, contrary to the Google APIs Terms of Service. OzarksMade will not make that statement on behalf of its users, and Companion Mode has therefore been retired. OzarksMade RCS, an RCS network of our own, replaced it and is free of charge through December 31, 2026.

The short version. If pairing stopped working for you, nothing is wrong with your device, your account or the application. Google now requires every companion application to transmit a written acknowledgement of unauthorized access to an undocumented API before pairing is permitted. Other projects have chosen to send it. OzarksMade has not, and will not. Companion Mode has been retired, text and picture messaging continued without interruption, and OzarksMade RCS now carries the chat features on infrastructure that requires no one else's permission.

Retirement complete. Companion Mode has been retired for every user, on every release channel. No action was required. Text and picture messaging was unaffected, and conversation history remained on the device.

What people saw

You opened our app, chose to connect to Google Messages, and it said Contacting your phone. The matching emoji appeared for a moment, and then, in about a second, pairing failed. It could show as 3/UNRECOGNIZED or simply refuse to finish. It happened immediately, before you even got a chance to confirm the emoji on your phone.

The pairing screen in Messages by OzarksMade showing pairing fail with the 3/UNRECOGNIZED error
Pairing fails within about a second, right after the emoji appears.

You are not alone, and it is not just our app

This is the most important thing to understand: anyone who hit this with our app would have hit it with Beeper too, and with any other app that connects to Google Messages this way. It is not a sign that our app is poorly made or that something is wrong with your setup. Google made one change on the phone side, and it shut all of us out at the same moment.

The team behind Beeper (the widely used mautrix bridge that powers it) is tracking the identical failure in a public bug report. You can read it here:

Beeper / mautrix bug report #91: pairing fails with the same error

Their report describes the same behavior: pairing fails at the final step, about a second after starting, with an error code that did not exist in Google Messages until this update.

That project has since restored pairing by sending the acknowledgement. The bridge now transmits the statement Google requires, word for word, and pairing proceeds. The text of that statement is reproduced below. It is an acknowledgement that the application is accessing an undocumented Google API without express authorization, which the Google APIs Terms of Service prohibit. Applications that transmit it are, by the terms of the statement itself, operating outside those terms, and they carry whatever consequence follows from that. This is not a criticism of the engineering. It is a statement of what the requirement is and of the position anyone who complies with it now occupies.

OzarksMade will not transmit that acknowledgement. The application would be making an admission, on behalf of every person using it, in order to obtain a capability that we are able to provide ourselves. The decision is not a close one, and it is not conditional on how widely the requirement is enforced.

Why it happened

Google Messages lets a computer or a companion app pair with your phone using a short handshake and a matching emoji. That handshake had worked the same way for years. Around the end of August 2026, Google began requiring a new piece of information as part of that handshake. If the app trying to pair does not include it, the phone rejects the pairing instantly.

The important detail is how Google turned this on. It was not a single app update you could point to. It was a gradual change on Google's own servers, switched on for some phones and Google accounts before others. That is why the problem looked so random. Two people could run the identical steps on the identical app and phone, and it worked for one and failed for the other, purely because Google had flipped the switch for one of them and not the other. It was not anyone's account being broken, their device model, or our app version.

Because it was a gradual rollout, it was expected to widen over time. That is why we treated it seriously even while it reached only some users.

What this means for you

There is no setting on your device that restores pairing, and none is worth pursuing: the requirement is Google's, it applies to every third-party application, and Companion Mode was retired rather than brought into line with it.

  • Text and picture messaging continues. Texts, group messages and photos are carried by the mobile network and are unaffected by any of this.
  • Your conversations stay where they are. Nothing is deleted, and history remains on the device.
  • Chat features now run on OzarksMade RCS, which is live and free of charge through December 31, 2026.
This is not a defect in the application
There is nothing to correct on your device and no setting that was missed. The handshake the application uses is the one every comparable application uses, and Google has changed what it requires of all of them.

The technical details, in full

For readers who want the real depth, here is precisely what changed. We investigated this directly rather than guessing.

The error

Google Messages pairing ends with a final step the protocol calls client finished. In the failing case, the phone answers that step with a rejection whose numeric error code is 32. That code is brand new. The list of pairing error codes in the public protocol used by every third-party client stopped at 31 before this update, which is why our app, Beeper, and the shared open-source library all display it as an unrecognized error: none of them had a name for a code that did not exist a week earlier. Decoded, code 32 means the phone considers a required confirmation to be missing.

What is now required

The updated Google Messages app expects the pairing request to carry a new field that older requests never included. When that field is absent, the phone treats the request as coming from an unapproved client and refuses at the final step, in under a second, before any emoji confirmation is even considered. Every third-party client built before this change omits the field, so every third-party client fails identically. The official Google Messages web client at messages.google.com includes the field, which is why pairing a computer through Google's own website continues to work.

How we know, and what the new requirement actually is

We examined the pairing handshake performed by Google's own web client, step by step, and compared it against what companion apps send. The difference is a single new field the phone now insists on. Here is the part that matters, and it is not what most people would assume.

Google did not lock companion apps out with cryptography. There is no secret key, no hardware security token, no signature that only a genuine Google client could produce. What they added is a field in which the pairing app must transmit, word for word, this exact statement:

This is an undocumented API. Use or access of undocumented Google APIs
without express authorization is prohibited per the Google API Terms of
Service (https://developers.google.com/terms).

Read that again. To keep pairing working, every companion app is now required to send back a message that acknowledges it is accessing an undocumented Google API in violation of Google's own Terms of Service. It is not a security check. It is a legal one. Google is not stopping anyone technically. They are requiring every third-party app to first transmit a written admission of wrongdoing, and then they let the pairing through.

OzarksMade is not willing to send that acknowledgement. It is a single field, and adding it would restore pairing immediately. It would also mean that the application, on behalf of every person who installs it, asserts that it is accessing an undocumented Google API without authorization and contrary to Google's terms. That is a legal position, not a technical one, and it is not ours to take on a user's behalf. Companion Mode is being retired instead, and the capability it provided is being delivered on infrastructure that belongs to OzarksMade.

Why this matters beyond one bug
A messaging companion works by speaking the same protocol the official app speaks. When the company that owns that app can, at any moment, require every independent app to sign away its footing just to keep working, it is a reminder that building on top of someone else's service is building on borrowed ground. That is exactly why, weeks before this happened, we changed course.

The replacement: OzarksMade RCS

The decision to build a network of our own was taken before this change was announced, for the reason set out above: an application built on another company's service holds its position only for as long as that company permits. OzarksMade RCS is that network, operated on OzarksMade infrastructure and built on the published GSMA and IETF specifications that carrier RCS runs on.

It provides the conversation experience Companion Mode provided, and more than it could: delivery and read notification, typing indicators, full-quality photos and video, group chats, end-to-end encryption, synchronization across a person's devices, and a developer platform open to third parties. There is no pairing step, no dependency on another application, and no acknowledgement to transmit to anyone.

It is live now and free of charge through December 31, 2026. Details of the service and of the plans that follow that date are on the OzarksMade RCS page.

Where things stand

Companion Mode has been retired for every user, on every release channel. No action was required.

Text messages and multimedia messages are unaffected and continue to work exactly as they always have, including group messages and photos. Conversation history remains on the device. Chat features now run on OzarksMade RCS, and they turn on by themselves once Messages by OzarksMade is your messaging app.

If something is not working as you expect, the most useful information is your phone model, your Android version and a screenshot. Email messages@ozarksmade.net, or select Contact us in the application, which includes your device and application details automatically.

Email us about this About OzarksMade RCS Back to home

Last updated: September 19, 2026. This page will be updated as the retirement proceeds.