You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 680ee83
Browse filesBrowse the repository at this point in the historyBrowse files
fix(screening): match stored numbers in +1 form for national caller IDs
canonicalizePhone adds "+1" only when PhoneNumberUtils.formatNumberToE164
accepts the number, and that returns null for anything libphonenumber
calls invalid: fictional exchanges, unassigned area codes, and area codes
newer than the phone's metadata. Such a caller ID delivered in national
form stayed plus-less and missed the E.164-keyed spam database and prefix
list. On the API 35 emulator a call from 16495550123 rang through while
Lookup flagged +16495550123 as a prefix match.
On a NANP home region, a national-format NANP number now carries its +1
form as CheckContext.e164Fallback, and every exact stored-number lookup
tries both forms: the allow side (manual whitelist, temporary allow, the
STIR trust database probe) as well as the block side (user blocklist,
database, prefix, database prefix expansion), so an allow saved in either
form still wins. The outgoing call hold uses the same forms. Stored
identities keep their canonical form, so nothing is migrated.
Tests: PhoneIdentityCanonicalizerTest gains the fallback's pure cases.
NationalFormatLookupTest (new, Robolectric) asserts the scenario number
stays plus-less, then checks the database, prefix, E.164 user block and
E.164 allow cases; dropping the fallback fails the four behaviour cases,
and leaving only the whitelist on the canonical form fails the allow case.
No existing test changed.
0 commit comments