SIP addresses containing "911" shouldn't be considered emergency calls
This change updates isEmergencyNumberInternal() to always return false if you pass in a SIP address, since the concept of "emergency numbers" is only meaningful for calls placed over the cell network. Previously we *did* try to compare SIP addresses against the list of known emergency numbers, which caused bad behavior with SIP addresses that even contained "911"/"112"/etc as a substring (since we were filtering out non-dialable characters before doing the comparison!) TESTED: - Before this change, calls to "abc911def@example.com" or "911abcdef@example.com" were incorrectly detected as emergency numbers, and fail. - After this change, SIP addresses like "abc911def@example.com" and "911abcdef@example.com" work fine. - Also, confirmed that this change doesn't break the restriction that 3rd party apps shouldn't be able to make emergency calls. Specifically, I fired off ACTION_CALL intents (using the CallDialTest activity) for a bunch of numbers *similar* to emergency numbers, and confirmed that none of them actually resulted in an emergency call being placed. The specific ACTION_CALL intents I tested were: "911" ==> Didn't place the call; brought up dialer instead "tel:911" ==> Didn't place the call; brought up dialer instead "911@foo" ==> Tried to start a SIP call (which failed) "911%40foo" ==> Tried to start a SIP call (which failed) "tel:911@foo" ==> Tried to start a SIP call (which failed) "tel:911%40foo" ==> Tried to start a SIP call (which failed) "911@example.com" ==> Tried to start a SIP call (which failed) "sip:911" ==> Didn't place the call; brought up dialer instead "sip:911@foo" ==> Tried to start a SIP call (which failed) "sip:911%40foo" ==> Tried to start a SIP call (which failed) Bug: 5515452 Change-Id: I6f9f8690b08564c53c7a76f480654477b475d94d
Loading
Please register or sign in to comment