phone_call: don't count an ongoing call an iOS phone never started

[zunda-pixel]

What

A call that arrives over Pebble Protocol is taken to mean the phone is Android, so answering one starts the call-duration timer and offers a hangup:

static bool prv_should_show_ongoing_call_ui(void) {
  // We only want to show the ongoing call UI on Android
  return (s_call_source == PhoneCallSource_PP);
}

An iOS companion sends calls the same way. iOS gives no third-party app a way to answer or end a carrier call, so the answer and the hangup we send back over PP reach an app that can do nothing with them — and the watch is left counting the seconds of a call that is still ringing on the phone.

This remembers what the mobile app said it runs on (PEBBLE_REMOTE_APP_INFO_EVENT, the same event music_endpoint_handle_mobile_app_info_event already keys off) and treats iOS-over-PP the way iOS-over-ANCS is already treated: accept-and-dismiss, no duration timer, no hangup. Android is unchanged.

How I checked it

Two host tests in tests/fw/services/test_phone_call.c, driving the same PP incoming call once after an Android app-info event and once after an iOS one, and asserting on the show_ongoing_call_ui argument the service passes to phone_ui_handle_incoming_call. Reverting the prv_should_show_ongoing_call_ui hunk fails only the iOS case, so the tests do pin the change.

Then on qemu_emery, with a companion that speaks Pebble Protocol over the emulator's port and announces its OS in its PhoneVersion response. Same incoming call each time, answered with the UP button:

firmware	phone announces	screen 3–25 s after answering
main (70ed290)	iOS	0:02 … 0:24, counting up
this branch	iOS	"Call Accepted", popup closes after 3 s
this branch	Android	0:02 … 0:24, counting up

The last row is the same binary as the middle one, so the only thing that moved is what the phone said it was.

Note

I have not reproduced this against a real iPhone and a real carrier call — I have no iOS companion that sends calls over PP to hand you. The reasoning above is from the firmware's own code and from what iOS permits a third-party app to do; the emulator rows show the branch behaves as intended, not that an iPhone triggers it in the wild.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 354c056fba

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 7be3b1ba4d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[gmarull]

main question is why on iOS we would send that over PP? Code already has a path for ANCS case.

An iOS companion sends calls the same way. iOS gives no third-party app a way to answer or end a carrier call, so the answer and the hangup we send back over PP reach an app that can do nothing with them — and the watch is left counting the seconds of a call that is still ringing on the phone.