[FEATURE PROPOSAL] Per-contact preferred SIM on e/OS: findings from reading the Dialer, Contacts and Message source
Context
This follows up on an earlier request here: Add per-contact default SIM selection for outgoing calls (Dual SIM devices)
I use a dual-SIM Fairphone on e/OS (SIM 1 for professional contacts, SIM 2 for personal contacts) and, like others in that thread, I’m missing the ability, which exists on stock Android with Google’s apps, to assign a SIM card to a contact for calls and SMS — either the first time I call or text them, or directly from the contact card when editing it.
I’d like to pick up this topic and drive it forward myself, through to a working fix. I’m relatively new to Android development, but I’ve already started digging into the actual e/OS source (Dialer, Contacts, Message repos), and I intend to keep going: learning what’s needed, building and testing patches, and iterating with feedback from this community and from maintainers, rather than just dropping an idea and waiting for someone else to pick it up. With some guided digging so far, I’ve narrowed down where things stand for both calls and SMS, with concrete file references and a candidate fix for the calls side. I’m opening a new topic rather than replying inline because this has grown from a feature request into an actual technical investigation, and I think it deserves its own visibility for anyone tracking this kind of issue.
I’m not able to build and flash a full e/OS image myself yet, so I can’t verify the proposed fix end-to-end on my own — but I’m actively working towards that, and I’ll keep this thread updated as I make progress. If anyone here has a working e/OS build environment, dev experience with the Contacts provider / Dialer, or just wants to help push this forward (testing, reviewing, or taking over parts of the implementation), I’d really welcome the help — happy to share everything I’ve found so far and to collaborate however is most useful.
Calls (Dialer)
The full mechanism already exists in the Dialer codebase (android_packages_apps_Dialer), inherited from the AOSP Dialer:
-
java/com/android/dialer/precall/impl/CallingAccountSelector.java— the pre-call action that decides whether to show a SIM picker or use a remembered preference. -
java/com/android/dialer/preferredsim/PreferredAccountWorker.java/impl/PreferredAccountWorkerImpl.java— looks up a preferred account for the dialed number. -
java/com/android/dialer/preferredsim/impl/PreferredSimFallbackProvider.java+PreferredSimDatabaseHelper.java— a fully implemented (not a stub) ContentProvider + SQLite table that stores the preference. -
Declared correctly in the Dialer’s
AndroidManifest.xml(provider +com.android.dialer.SUPPORTS_PREFERRED_SIMmeta-data).
The blocker: PreferredAccountWorkerImpl.isPreferredSimEnabled() checks, via PackageManager.resolveActivity() on the QuickContact intent, whether the currently-installed Contacts app declares this metadata on its <application> tag:
supports_per_number_preferred_account
I searched the e/OS Contacts repo (android_packages_apps_Contacts) for this exact string and got zero matches. Without it, getDataId() always returns empty, so the Dialer falls back to the system default/“always ask” SIM behavior — matching exactly what’s reported in the thread (no per-contact dialog, no way to remember a choice, and separately a reset-to-SIM-1-on-reboot behavior that may be a related/independent bug in the system default subscription).
I also checked the current AOSP platform/packages/apps/Contacts (Google’s public mirror, master branch) and this metadata isn’t present there either. Anecdotally, a user in this conversation confirmed this exact feature (choose SIM per contact for calls, remembered afterward) worked on their Fairphone under stock Android before switching to e/OS — which suggests the working implementation lives in Google’s proprietary Contacts/Phone apps (not open source), while the AOSP/open-source side has the Dialer-side machinery built but never wired up on the Contacts side. This may also affect other AOSP-based/degoogled ROMs (e.g. GrapheneOS users report the same missing feature: Save preferred SIM card per contact (dual sim operation) - GrapheneOS Discussion Forum ).
Possible fix (unverified, not yet build-tested): declare the metadata on android_packages_apps_Contacts’s <application> tag:
<meta-data
android:name="supports_per_number_preferred_account"
android:value="true" />
I haven’t been able to build a full e/OS image yet to verify this actually surfaces the dialog end-to-end (in particular whether getDataId()'s lookup via PhoneLookup.CONTENT_FILTER_URI + Data/RawContacts works correctly against e/OS’s Contacts provider). If someone with a working e/OS build environment wants to test this, that would help a lot.
SMS (Message app, QKSMS-based)
Different codebase (android_packages_apps_Message, a fork of QKSMS), and a different — partial — situation:
-
ComposeViewModel.kt/QkReplyViewModel.ktboth compute alatestSubId: thesubIdof the last message in the current conversation, and use it to preselect the SIM for the next message in that thread. -
This means: once you’ve sent at least one message to a contact (manually picking a SIM via the SIM-switch button), subsequent messages in that thread do default to the same SIM. This part works.
-
What’s missing: on the first message to a new contact, there’s no prompt —
latestSubIddefaults to-1, which falls through tosubs[0](SIM 1) silently. There’s also no persisted, explicit “preference” independent of message history — it’s inferred purely from the last message sent, which is a different (weaker) guarantee than an explicit per-contact setting.
Possible improvement direction: add a first-message prompt similar to the Dialer’s, ideally backed by the same preference storage mechanism as PreferredSimFallbackProvider (if accessible/reusable across apps) rather than a separate ad-hoc store, so a preference set from Contacts, Dialer or Messages could stay consistent.
Suggested next steps
-
If a maintainer or contributor can confirm whether
supports_per_number_preferred_accountwas ever present/used elsewhere (LineageOS history, older AOSP revisions), that would help confirm this isn’t a red herring. -
Happy to test any patch on my Fairphone once I’m able to build and flash it, and to help however else is useful — still learning the build/compilation side.
-
Given the same gap seems to affect other AOSP-based ROMs, this might be worth raising upstream (LineageOS) too, rather than only as an e/OS-specific fix.
Looking for contributors
I’d like to see this through — from filing a proper GitLab issue once this is discussed here, to testing a patch, to eventually helping with the implementation as I build up my Android/build skills. If you have experience with the Contacts provider, the Dialer’s preferredsim package, or an e/OS build environment already set up, and would be interested in collaborating on this (reviewing the analysis, testing the Contacts metadata fix, or tackling the Message app side), please comment below or reach out. Every bit of help — even just confirming or poking holes in the analysis above — is welcome.
Thanks for reading this far — feedback/corrections very welcome, especially from anyone who’s more familiar with the Contacts provider internals or has a working e/OS build setup.