Effective date: August 29, 2026
Simmo picks the right SIM (or calling app) for your outgoing calls based on rules you set. The short version of this policy: everything Simmo does with your calls happens on your device. A number you dialed never leaves it in full, and no contact’s name or number leaves it at all. Data leaves your device only with your involvement: optional crash reporting and usage statistics, off until you turn the “Help make Simmo better” switch on — with one exception on a single launch, if you are updating from a version where that switch was on by default — and a debug log that goes nowhere unless you choose to share it.
Simmo uses Firebase Crashlytics and Google Analytics for Firebase to help us fix crashes and understand which features are used:
••• before it is sent, and an error’s own message is dropped
whoever wrote it.
Never a contact name, and never a dialed number, redacted or otherwise.
That log may also carry why Simmo’s previous runs ended — Android’s own
reason, the exit code or signal, how important Android considered Simmo at
that moment, and when it happened — together with when Simmo was installed
and last updated. It is Simmo’s account of itself, not anything about you
or your calls: a dialed call is what wakes Simmo when it is not running, so
whether the app had just been killed and restarted is often the difference
between a rule that failed and a rule that never got the chance to run.
Android’s free-text reason description is not included.Neither ever includes the full numbers you dial, any contact’s name or number, or a full account identifier, and ad personalization is turned off. The only thing about your contacts that a crash report carries is counts: how many of them each calling app can call, how many call rows that app has written, and how many of your rules are about a specific person. A rule you wrote for one person never carries who that person is — not their name, their number, or the identifier Android uses for them — in a crash report or a shared report.
Both are controlled by the “Help make Simmo better” switch, shown during setup and available anytime in Simmo’s settings: it is off until you turn it on, and turning it off again stops both crash reporting and usage statistics immediately. Nothing is sent before you turn it on, with one exception on a single launch — described at the end of this section — if you are updating from a version of Simmo where this switch was on by default. Those installs come back off, and Simmo puts the question to you on its main screen rather than assuming an answer you were never given the chance to make. After that, each app start applies the most recent choice you made.
Sent, rather than collected, because the two are not the same and the difference is the next paragraph’s subject: the crash reporting library still writes a crash to your phone while the switch is off. It is never sent, and it is discarded rather than released — see below.
A crash captured while reporting is off is written to your phone and never sent. It is discarded when you first turn reporting on, rather than released: switching the reporter to “don’t send” never stopped it writing crashes to the phone, so turning it on would otherwise release a report collected before you agreed. Turning reporting off discards what is still held, for the same reason.
One exception, on one launch, if you are updating from a version where this switch was on: the reporting libraries start before any of Simmo’s own code, so a report they were already holding can go in the moment before Simmo turns them off and discards. From the next launch onward they start off, and a fresh install is never in this position. This data is processed by Google’s Firebase services on our behalf; see Firebase’s privacy documentation for how Firebase handles it.
To decide which SIM a call should use, Simmo looks at the number you dialed and works out the destination country. This happens entirely on your device, in memory, using an offline phone-number library. The complete number is never written to storage and exists only in memory for the moment the call is being placed, and Simmo never sends it off your device on its own. (A redacted partial number may appear in the debug log described under “Sharing debug logs” — never the complete number. A redacted copy of that log is kept in Simmo’s private storage so it survives an unexpected exit — a crash, or the system closing the app; the prior run’s copy is included if you share a report, then removed. It is never backed up.)
A redacted number reaches us one way and no other: a debug log you choose to
share. A crash report does not carry one — the log Simmo attaches to a crash
replaces every number, SIM name and phone account with ••• before it is sent,
so even the redacted partial stays on your device. The complete number never
leaves your device by any route.
One exception to keep in mind: if a rule (or your choice in Simmo’s chooser) hands a call off to another calling app, such as Google Voice, Simmo passes the dialed number to that app on your device so it can place the call — that is the feature doing its job. What the receiving app does with the number is governed by that app’s own privacy policy.
Your rules, your settings, and a registry of the SIMs your device has used (their names and carriers, so rules can refer to them, plus each SIM’s home country and its own phone number — when your device reports them — so you can tell your SIMs apart on the SIMs screen). Simmo never transmits your rules or this registry anywhere — with one narrow exception: while crash reporting is on, a crash report says which rule a recent call used, why the rules above it were skipped, and what those rules pick — the SIM by its display label, the app, the countries (see “Crash reporting”). It never includes a SIM’s phone number.
Like most Android apps, this app data is included in Android’s standard backup and device-to-device transfer, so if you have device backup turned on, Android copies it to your backup (for example, your Google Account) along with your other app data. That is handled by Android under your device’s backup settings, not by Simmo. Because the complete dialed number is never written to storage at all — the debug log holds only redacted partials, and the copy of it Simmo keeps to survive an unexpected exit (see “Sharing debug logs”) lives in Simmo’s private cache, which is excluded from backup — no call data can ever appear in a backup.
Rules you wrote for a specific person are the one exception, and you choose where they go. Such a rule stores the identifier Android gives Simmo for that contact. That identifier is generated by your phone, and for a contact saved only on your device — not synced to any account — it can contain the contact’s own name. So it is the one thing Simmo stores that is about somebody else, and it travels only as far as you allow:
Everything else Simmo stores — your other rules, your settings, the SIM registry — is backed up as before, and none of it identifies a person.
Simmo also keeps a copy of your contacts’ names and numbers in its private cache. Only if you granted the Contacts permission, and only so it doesn’t have to read your whole address book again every time it starts: reading it takes about a second and a half, which is most of the time Simmo has to decide how to place a call, and the answer is almost always the same as last time. The copy holds what Simmo already reads live — your contacts’ names and phone numbers, which calling apps can reach them, and, for each of those app entries, the identifier the app itself wrote there. That last one is usually a phone number, but some apps use an email address or their own account id instead, so it is named here rather than filed under “which apps”. Where the app wrote something Simmo can read as a phone number it keeps the number part; anything else — an email address, an account id — is kept exactly as the app wrote it.
It also keeps, for every contact in that copy, the identifier Android gives Simmo for them — the same kind of identifier described above for a rule you wrote about a specific person, which on a contact saved only to your device can contain their name. Above, that identifier is stored for the few people you wrote rules about; here it is part of the copy of your whole address book, which is why it is said again rather than assumed. It is what lets Simmo tell one contact’s rows from another’s. And for the people you wrote rules about, the copy also records who each rule points to — that contact’s name and identifier — so a rule can show its subject’s name straight away at the next start, even for a contact who currently has no phone number saved. Everything in this section stays on your device under the terms below.
Simmo’s Settings screen has a Share debug logs action to help diagnose a problem — for example, a call that didn’t route the way you expected. When you tap it, Simmo builds a short text report and opens Android’s share sheet so you can send it wherever you choose (and also copies it to your clipboard). Nothing is sent anywhere unless you take that action and pick a destination.
The report contains your device and app-build details, whether Simmo holds the call-redirection role, whether each permission Simmo can request (phone state, phone numbers, call phone, contacts, notifications) and each special access it can use (“display over other apps”, full-screen intent) is currently granted or denied, your current settings, your calling rules, your data rules, your country groups, and the names, carriers, home countries, and own numbers of the SIMs Simmo has seen (so a rule like “in Mongolia, use Verizon” can actually be diagnosed). Because a warning about data roaming can only be checked against what Simmo was looking at when it decided, the report also describes your current mobile-data situation: the country your phone is connected in, which SIM is carrying data, and for each SIM its name, its home country, whether your network says it is roaming, and whether its data-roaming switch is on — plus which of your data rules decided, or, if none did, why. Nothing here identifies a SIM beyond the name you see in Android’s own settings: no SIM serial number, no IMSI, and no subscriber identifier of any kind. Rules you wrote for a specific person are listed too, but only by what they do, whether you have turned them off or deleted them, and whether they can work right now — “a contact → use SIM Telstra”, never which contact. “Whether they can work” is the state the app already shows you beside the rule: that the contact could not be found, that they have no number to call, that the app the rule hands calls to is not installed, or that they share a number with somebody else so calls to that number skip the rule. That last one says a number is shared; it does not say whose, and none of these name the person, the number, or the identifier. The identifier Android gives Simmo for a contact is generated by your phone and can contain the contact’s own name, so it is kept on your device and never put in a report. It also records why Simmo’s previous runs ended — Android’s own reason (a crash, an out-of-memory reclaim, an app update, the system stopping it), the exit code or signal the process ended on, how important Android considered Simmo at that moment, and when it happened — together with when Simmo was installed and last updated. This is Simmo’s account of itself, not anything about you or your calls: a dialed call is what wakes Simmo when it is not running, so whether the app had just been killed and restarted is often the difference between a rule that failed and a rule that never got the chance to run, and without this there is nothing afterwards to tell those apart. Android’s reason text is not included. It also includes a short log of Simmo’s recent routing decisions and any errors. For each call it records what Simmo had to work with: how many SIMs and calling accounts it could see, the country your phone was connected in, whether your contacts could be read, how many of your contacts each calling app can call and how many call rows it has written (counts, not who), whether the apps your rules hand calls to are installed, and whether a screen could be shown — then which rule was used and why the rules above it were skipped. It records the same two things for mobile data whenever they change: the situation above (country, which SIM has data, each SIM’s home country and its two roaming flags — names and countries, never an identifier) and the conclusion Simmo drew from it, with the data rule that decided or the reason none did. Where your phone reports no home country for a SIM, Simmo works one out from the SIM itself or, failing that, from its own number — only the country it belongs to, never the number itself — and the log names which of those the country came from rather than passing it off as reported. It also records each SIM’s operator code (the MCC and MNC — the country and network your SIM belongs to, the same operator the log already names), so you can check that working-out rather than take it on trust. That code identifies an operator, never you: it is the same for every subscriber on that network. When a call was handed to another app, it also records how far that hand-off got — whether the app was opened, whether the offer had to be put back for you to tap, whether a call actually started, and whether anything failed — named by the app, never by the contact. It also records what the app was pointed at, which takes one of two shapes because the two kinds of hand-off work differently. For an app that calls a contact — the kind Android’s Contacts app lists under “Connected apps” — it names which of that app’s actions was opened (its “voice call” row rather than its “video call” one, say) and whether the app had registered that row against the line being called, against another of the same contact’s numbers, or against no line Simmo could resolve: which of the three, and nothing more. For an app handed a number by a link — Google Voice, Viber — it records that number in the same redacted form as everywhere else in the log: the country code and the last three digits, with everything between them masked. Both hold whether a rule chose the app or you picked it in Simmo’s chooser. Beyond that it is the app’s own description of what it can do, plus which of your rules acted: no contact name, no full number, and no identifier for the contact record itself. The report also lists the apps on your phone that can call a contact directly, as Android’s Contacts app lists them under a contact’s “Connected apps” — the app’s name and the kind of action it offers (voice call, video call, message, and so on). That is a list of installed apps and what they can do, not a list of your contacts: none of your contacts, their names, or their numbers are read to produce it. It is there because “why isn’t my calling app offered?” cannot be answered without seeing what that app told Android it can do. That is the difference between “my rule didn’t fire” and knowing which one didn’t, and why. A redacted copy of this log is kept in Simmo’s private storage so it survives an unexpected exit (a crash, or the system closing the background app), which is what makes that kind of problem diagnosable; the prior run’s copy is included once when you share a report, then removed (and it is cleared with the app’s cache anyway). It is never included in a backup. Every phone number in the report — a dialed number in the log, or a SIM’s own number — appears only in redacted form: the country code and the last three digits, with everything between them masked. A number written in national format has no country code to keep, so a couple of its leading digits are kept instead — never more than half the number. Either way a complete number is never written to the report or shared. You can review the report in the share sheet or paste it from the clipboard before sending it.
Simmo asks for all of the permissions below during setup, and is designed and tested with all of them granted. Only the first two are required in the sense that Simmo cannot route a call at all without them; the rest are ones you can decline — Skip proceeds without them, and you can grant any of them later, either from system settings or when a feature asks for it in context. The last group is different in one way: Android has no in-app dialog for those, so setup can only send you to the system settings screen where you turn them on yourself. Declining one never sends any extra data anywhere; it simply turns off the feature that uses it, and those features are part of how Simmo is meant to work, so expect parts of the app not to behave as described until the permission is granted.
Required — Simmo cannot route calls without these:
READ_PHONE_STATE) — lists your SIMs and calling
accounts, so rules can name them and Simmo can recognize your SIMs.Also asked for — each powers a specific feature, and that feature is off without it:
READ_CONTACTS) — used to recognize that a dialed number belongs
to one of your contacts. Powers calling a contact through another app (such as
WhatsApp or Meet), the “Use contacts’ local numbers” correction, which needs the
contact’s other numbers to find one local to where you are, and the “suggested
countries from your contacts” shortcut in the country picker. Contact data is read on your device only and never leaves it.
Without this permission, those features simply don’t activate.POST_NOTIFICATIONS) — used for reminders and error
notices: “your SIM is now active — place the call?”, “new SIM — add a rule?”,
and “couldn’t open Google Voice” with a Redial shortcut. Without it, error
notices appear as a brief on-screen message instead, and the reminders don’t
appear. The travel warnings go with them — “using data roaming”, “no data here”,
and the wrong-data-SIM nudge are not raised while you are out and about; the same
information waits on Simmo’s own screen until you next open it, which can be after
the roaming has been paid for. It also decides whether Simmo can act on a rule that has to put a screen
up at all: with notifications off, or Simmo’s “Call screens” notification category
turned down below High (Android’s own settings can do that without blocking it —
a quieter notification can’t put a screen up mid-call), rules that ask which
SIM to use and rules that hand the call to an app Simmo has to open (WhatsApp,
Google Voice) are skipped entirely — Simmo won’t cancel your carrier call for a
screen it can’t show — and the call falls through to your next rule. A hand-off to
a calling account registered with Android (a SIP or VoIP provider) is unaffected,
since that is a plain redirect with no screen involved. The rule holds for anything Simmo would otherwise put
on screen while a call is being placed: a delay countdown is skipped, so the call
goes through with no chance to cancel it, and a contact’s local number is either
applied without confirming it with you or left alone, rather than asked about.CALL_PHONE) — used to place a call in one tap when you
confirm a choice in Simmo’s chooser or tap Redial on an error notice. Without
it, Simmo opens your dialer with the number filled in and you place the call
yourself.READ_PHONE_NUMBERS) — used to show each SIM’s own
phone number in two places, both so you can tell similar SIMs apart: on the
SIMs screen, and on the buttons when Simmo asks which SIM to use for a call,
where the number is the point of the question — it is what the person you are
calling will see. The number is read and stored on your device only, and it is
never sent anywhere. Without it, neither surface shows numbers; the SIM’s name
and slot are used instead.Special access — turned on in Android’s own settings, because no in-app dialog exists for them:
SYSTEM_ALERT_WINDOW) — Simmo never draws an
overlay. It does not put anything on top of another app, and it does not use
this to watch, cover, or intercept what you are doing. It is here for one
reason: Android blocks an app from opening a screen while it is not already on
your screen, and holding this permission is the exemption. A call is dialed from
your dialer, so Simmo is by definition not on screen when your rule fires — and
a rule that hands the call to another app has to open a screen to do it. With
this granted, that screen (and behind it the calling app your rule picked, such
as WhatsApp) opens by itself. Without it, the same thing still happens, but only
after you tap a notification Simmo posts. Offered as a row during setup, and in
Settings. Declining it costs you the tap, nothing else.USE_FULL_SCREEN_INTENT) — covers the other case: it
lets that same mid-call screen appear while your phone is locked or idle,
rather than waiting as a notification you have to unlock and tap. It does not
cover the unlocked, in-use case — Android deliberately downgrades a full-screen
intent to a banner there, so as not to seize the screen of someone mid-task.
Simmo runs on Android 14 and later, where this always needs your explicit
grant, so Settings shows a hint with a button to the system screen that gives
it. Declining it costs you the tap, nothing else.Emergency calls are never redirected, altered, or interfered with in any way.
We are considering adding usage statistics about routing itself in a future version: which SIM (by the name you gave it) is used to call which destination country, and how often calls complete or fail — never contact names, contact numbers, or the phone numbers you dial. These would be covered by the same “Make Simmo better” switch. If they ship, this policy will be updated at the same time to describe exactly what is collected and why, and the effective date will change.
We may also add links to useful travel products, such as buying a travel eSIM, and some of those may be affiliate links (meaning we can earn a commission on purchases). Opening such a link would never send the numbers you dial, your contacts, or your rules to anyone. If a link ever shares any other data from your device, this policy will be updated first to say exactly what and why.
Any changes will be posted at this page with an updated effective date.
Questions about this policy: mikel@mikelward.com