fix(voip): Phone account creation

[diegolmello]

Proposed changes

Fixes Android VoIP incoming calls that failed from a cold state because the PhoneAccount was not yet registered with TelecomManager when the FCM push arrived. The app now registers a self-managed PhoneAccount natively (idempotently) before calling addNewIncomingCall, so calls work even before JS boots and runs RNCallKeep.setup.

Additional Android hardening via react-native-callkeep patches:

• Use packageName (locale-stable) instead of the localized app label as the PhoneAccountHandle ID, so the JS-side and native-side registrations share one handle.
• Always mark the connection as PROPERTY_SELF_MANAGED instead of querying telecomManager.getPhoneAccount(...), which requires READ_PHONE_NUMBERS on Android 11+ and isn't grantable from an FCM background context.
• Wrap hasPhoneAccount in try/catch for SecurityException.
• Null-check RNCallKeepModule.instance in startForegroundService to avoid NPE when the service starts before the JS module initialises.

Android manifest: add phoneCall to the VoiceConnectionService foregroundServiceType so the foreground service is legal for a self-managed telecom connection.

iOS: initialise event storage eagerly inside RCT_EXPORT_MODULE() so events emitted before setup isn't called (cold-start CallKit) aren't dropped.

Issue(s)

Related to the VoIP lib base branch (feat.voip-lib-new).

How to test or reproduce

Android:

1. Force-stop the app so JS is not running.
2. Trigger an incoming call to the device.
3. The CallKeep incoming-call UI should appear and the call should be answerable without the app needing to launch first.
4. Repeat after a device reboot to cover the PhoneAccount-not-yet-registered path.

iOS:

1. Force-quit the app.
2. Trigger an incoming call; the CallKit UI should appear and no ringing/answer events should be dropped.

Screenshots

N/A — native-only behavioural fix.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Improvement (non-breaking change which improves a current function)
• New feature (non-breaking change which adds functionality)
• Documentation update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if applicable)
• I have added necessary documentation (if applicable)
• Any dependent changes have been merged and published in downstream modules

Further comments

The react-native-callkeep changes live in patches/react-native-callkeep+4.3.16.patch (applied via patch-package at postinstall). The callkeep version is unchanged (4.3.16); only the patch grew. The @types/jest bump in package.json is an unrelated stray pin — harmless.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

VoIP Android now always constructs and registers a self‑managed PhoneAccountHandle (resolving app label) and tightens input validation/logging; RNCallKeep Android hardens PhoneAccount access and always marks connections self‑managed; iOS initializes delayed events; manifest foreground service types and a dev dependency updated.

Changes

Cohort / File(s)	Summary
VoIP Phone Account Registration (Android) android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt	registerCallWithTelecomManager now rejects empty callId/caller, always builds a PhoneAccountHandle using (ComponentName(...), packageName), adds getApplicationLabel() and ensureSelfManagedPhoneAccountRegistered(...), and updates SecurityException/generic exception logging.
React Native CallKeep — Android runtime changes patches/react-native-callkeep+4.3.16.patch node_modules/react-native-callkeep/.../RNCallKeepModule.java, node_modules/react-native-callkeep/.../VoiceConnectionService*	PhoneAccountHandle account id switched to context.getPackageName(); hasPhoneAccount now catches SecurityException and returns false with a warning; VoiceConnectionService for API ≥ O always sets Connection.PROPERTY_SELF_MANAGED and guards React activity lookup; two Java overloads without hasVideo removed.
React Native CallKeep — iOS node_modules/react-native-callkeep/ios/...	sendEventWithNameWrapper ensures _delayedEvents is initialized to a mutable array when nil before appending delayed events.
Android Manifest android/app/src/main/AndroidManifest.xml	io.wazo.callkeep.VoiceConnectionService android:foregroundServiceType changed from microphone → `microphone
Package metadata package.json	Dev dependency @types/jest updated from ^29.5.13 to 29.5.14.

Sequence Diagram

sequenceDiagram
participant RN as React Native JS
participant NM as Native Module
participant TM as TelecomManager
participant PA as PhoneAccountRegistry
participant VC as VoiceConnectionService

RN->>NM: displayIncomingCall / startCall (uuid, number, caller)
NM->>NM: validate inputs (non-empty callId/caller)
NM->>TM: ensureSelfManagedPhoneAccountRegistered(appLabel)
TM->>PA: registerPhoneAccount(PhoneAccount with CAPABILITY_SELF_MANAGED)
PA-->>TM: registration result / SecurityException handled
NM->>VC: create Connection (set PROPERTY_SELF_MANAGED)
VC-->>NM: connection lifecycle events

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'fix(voip): Phone account creation' directly relates to the main changes in the pull request, which involve refactoring phone account registration and creation logic across multiple VoIP-related files.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt (1)

666-669: ⚠️ Potential issue | 🟡 Minor

Redundant null checks on non-nullable String parameters.

callId and caller are declared String (non-nullable), so isNullOrEmpty() will issue a compiler warning and the log message is misleading ("callId is null or empty" also fires for empty caller). Prefer isEmpty() and disambiguate the message.

🔧 Proposed fix

-            if (callId.isNullOrEmpty() || caller.isNullOrEmpty()) {
-                Log.e(TAG, "Cannot register call with TelecomManager: callId is null or empty")
+            if (callId.isEmpty() || caller.isEmpty()) {
+                Log.e(TAG, "Cannot register call with TelecomManager: callId or caller is empty")
                 return
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`
around lines 666 - 669, The null-checks on callId and caller are redundant
because they are non-nullable Strings; replace isNullOrEmpty() with isEmpty()
and provide distinct log messages so the logged reason identifies which
parameter is empty. Locate the check in VoipNotification (the block using TAG,
callId and caller) and change the condition to test callId.isEmpty() ||
caller.isEmpty(), but log separate errors (e.g., "Cannot register call: callId
is empty" or "Cannot register call: caller is empty") or check each individually
and return after the specific log to make the message unambiguous.

🧹 Nitpick comments (1)

android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt (1)

717-733: Consider registering once per process rather than on every incoming call.

addNewIncomingCall gets invoked for every push, which means registerPhoneAccount runs each time. While the Telecom API is safe to call repeatedly, on some OEMs repeated registration can reset user-facing account state (e.g., enabled toggle) or add noticeable latency in the FCM hot path. A process-scoped AtomicBoolean/lazy guard is cheap insurance:

🔧 Proposed fix sketch

     companion object {
         ...
+        private val phoneAccountRegistered = AtomicBoolean(false)
     }
     ...
-    private fun ensureSelfManagedPhoneAccountRegistered(
+    private fun ensureSelfManagedPhoneAccountRegistered(
         telecomManager: TelecomManager,
         handle: PhoneAccountHandle,
         label: String
     ) {
         if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) return
+        if (!phoneAccountRegistered.compareAndSet(false, true)) return
         try {
             val account = PhoneAccount.builder(handle, label)
                 .setCapabilities(PhoneAccount.CAPABILITY_SELF_MANAGED)
                 .build()
             telecomManager.registerPhoneAccount(account)
         } catch (e: SecurityException) {
+            phoneAccountRegistered.set(false) // allow retry on next push
             Log.e(TAG, "SecurityException registering PhoneAccount. MANAGE_OWN_CALLS may be denied.", e)
         } catch (e: Exception) {
+            phoneAccountRegistered.set(false)
             Log.e(TAG, "Failed to register self-managed PhoneAccount", e)
         }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`
around lines 717 - 733, The ensureSelfManagedPhoneAccountRegistered call is
executed for every incoming push (via addNewIncomingCall) and should be guarded
so registerPhoneAccount runs only once per process; add a process-scoped guard
(e.g., a private companion object AtomicBoolean or a lazily-initialized flag)
and check it at the top of ensureSelfManagedPhoneAccountRegistered (or from
addNewIncomingCall) to short-circuit repeated registration, ensuring
thread-safety (compare-and-set) so the first thread registers and others skip;
preserve existing exception handling and optionally reset the flag only on fatal
unrecoverable conditions if needed.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`:
- Around line 680-686: The PhoneAccountHandle ID is currently built using
getApplicationLabel(), which is locale-dependent and causes orphaned
PhoneAccount registrations when the app locale/label changes; change the handle
ID construction to use a stable identifier such as context.packageName (keep the
localized getApplicationLabel() only for display/labeling), i.e. when creating
PhoneAccountHandle use PhoneAccountHandle(componentName, context.packageName) or
otherwise pass packageName as the persistent ID to ensure matching native/JS
handles, and update the getApplicationLabel() implementation to remain for UI
label use only and not for the PhoneAccountHandle ID (also ensure
ensureSelfManagedPhoneAccountRegistered and any other places constructing
PhoneAccountHandle use the stable packageName ID).

In `@patches/react-native-callkeep`+4.3.16.patch:
- Around line 33-55: The change unconditionally sets
Connection.PROPERTY_SELF_MANAGED in VoiceConnectionService which assumes the
PhoneAccount was always registered with CAPABILITY_SELF_MANAGED (per
VoipNotification.registerCallWithTelecomManager); add a brief comment in
VoiceConnectionService explaining this assumption and the risk if JS ever calls
RNCallKeep.setup with selfManaged:false, or alternatively add an assertion/check
to guard against mismatched capability vs property; also mention in the patch
header that removing telecomManager.getPhoneAccount(request.getAccountHandle())
avoids a potential NPE when the handle is unregistered, and update the
patch-package context/footer so the patch hash matches.

---

Outside diff comments:
In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`:
- Around line 666-669: The null-checks on callId and caller are redundant
because they are non-nullable Strings; replace isNullOrEmpty() with isEmpty()
and provide distinct log messages so the logged reason identifies which
parameter is empty. Locate the check in VoipNotification (the block using TAG,
callId and caller) and change the condition to test callId.isEmpty() ||
caller.isEmpty(), but log separate errors (e.g., "Cannot register call: callId
is empty" or "Cannot register call: caller is empty") or check each individually
and return after the specific log to make the message unambiguous.

---

Nitpick comments:
In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`:
- Around line 717-733: The ensureSelfManagedPhoneAccountRegistered call is
executed for every incoming push (via addNewIncomingCall) and should be guarded
so registerPhoneAccount runs only once per process; add a process-scoped guard
(e.g., a private companion object AtomicBoolean or a lazily-initialized flag)
and check it at the top of ensureSelfManagedPhoneAccountRegistered (or from
addNewIncomingCall) to short-circuit repeated registration, ensuring
thread-safety (compare-and-set) so the first thread registers and others skip;
preserve existing exception handling and optionally reset the flag only on fatal
unrecoverable conditions if needed.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c43b215f-56b5-45bc-bea0-e418710a4079

📥 Commits

Reviewing files that changed from the base of the PR and between 9c84d4c and d02efd3.

📒 Files selected for processing (2)

• android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt
• patches/react-native-callkeep+4.3.16.patch

📜 Review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: format

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: CR
Repo: RocketChat/Rocket.Chat.ReactNative PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-07T17:49:17.538Z
Learning: Applies to app/lib/services/voip/**/*.{ts,tsx} : Implement VoIP with WebRTC peer-to-peer audio calls in app/lib/services/voip/ using Zustand stores instead of Redux, with native CallKit (iOS) and Telecom (Android) integration; keep VoIP and VideoConf separate

📚 Learning: 2026-04-07T17:49:17.538Z

Learnt from: CR
Repo: RocketChat/Rocket.Chat.ReactNative PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-07T17:49:17.538Z
Learning: Applies to app/lib/services/voip/**/*.{ts,tsx} : Implement VoIP with WebRTC peer-to-peer audio calls in app/lib/services/voip/ using Zustand stores instead of Redux, with native CallKit (iOS) and Telecom (Android) integration; keep VoIP and VideoConf separate

Applied to files:

• android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt
• patches/react-native-callkeep+4.3.16.patch

🔇 Additional comments (2)

patches/react-native-callkeep+4.3.16.patch (2)

60-67: LGTM — iOS lazy init avoids silent event drop.

[NSMutableArray addObject:] on a nil receiver is a no-op in Objective-C, so events posted before _delayedEvents was initialized were being silently dropped. This matches the upstream workaround referenced in the comment.

---

5-28: The patch is safe; no 3-arg calls to displayIncomingCall or startCall exist in the codebase.

All VoIP service calls use 2 arguments (userId/actor, or peer/type), which will match the remaining 4-arg and 5-arg overloads with the hasVideo parameter. The MediaSessionInstance wrapper properly abstracts the native module, and no code calls the removed 3-arg forms.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

patches/react-native-callkeep+4.3.16.patch (1)

38-53: Defensive try/catch around hasPhoneAccount is reasonable; consider caching the lookup.

Wrapping the capability check in try/catch(SecurityException) is a sensible hardening (self-managed reads can still throw on some OEMs / permission states). Minor nit: telecomManager.getPhoneAccount(handle) is invoked twice — once for the null check and again for isEnabled(). Caching into a local avoids a second IPC and a theoretical TOCTOU where the second call returns null.

♻️ Optional refactor

-        try {
-            return isConnectionServiceAvailable() && telecomManager != null &&
-                hasPermissions() && telecomManager.getPhoneAccount(handle) != null &&
-                telecomManager.getPhoneAccount(handle).isEnabled();
-        } catch (SecurityException e) {
+        try {
+            if (!isConnectionServiceAvailable() || telecomManager == null || !hasPermissions()) {
+                return false;
+            }
+            PhoneAccount account = telecomManager.getPhoneAccount(handle);
+            return account != null && account.isEnabled();
+        } catch (SecurityException e) {
             Log.w(TAG, "[RNCallKeepModule] hasPhoneAccount: SecurityException querying phone account", e);
             return false;
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@patches/react-native-callkeep`+4.3.16.patch around lines 38 - 53, The
try/catch around the phone-account check is fine but avoid calling
telecomManager.getPhoneAccount(handle) twice; in the method inside
RNCallKeepModule (the block that currently calls
telecomManager.getPhoneAccount(handle) for null and then .isEnabled()), cache
the result into a local (e.g., PhoneAccount phoneAccount =
telecomManager.getPhoneAccount(handle)), then check phoneAccount != null &&
phoneAccount.isEnabled() inside the existing try, and keep the SecurityException
catch that logs and returns false.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`:
- Around line 677-680: Update the stale comment above the PhoneAccountHandle
construction (around ComponentName, CALLKEEP_CONNECTION_SERVICE_CLASS,
PhoneAccountHandle) to state that the handle ID is the app's package name
(context.packageName) not the application label, fix the wording from "collide"
to "coincide", and add a short note warning future readers not to revert to
using getApplicationLabel() for the handle ID.

---

Nitpick comments:
In `@patches/react-native-callkeep`+4.3.16.patch:
- Around line 38-53: The try/catch around the phone-account check is fine but
avoid calling telecomManager.getPhoneAccount(handle) twice; in the method inside
RNCallKeepModule (the block that currently calls
telecomManager.getPhoneAccount(handle) for null and then .isEnabled()), cache
the result into a local (e.g., PhoneAccount phoneAccount =
telecomManager.getPhoneAccount(handle)), then check phoneAccount != null &&
phoneAccount.isEnabled() inside the existing try, and keep the SecurityException
catch that logs and returns false.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1744987e-7dd3-4a22-b154-247b71c6a0e7

📥 Commits

Reviewing files that changed from the base of the PR and between d4edea7 and 35dd976.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (4)

• android/app/src/main/AndroidManifest.xml
• android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt
• package.json
• patches/react-native-callkeep+4.3.16.patch

✅ Files skipped from review due to trivial changes (1)

• package.json

📜 Review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: ESLint and Test / run-eslint-and-test
• GitHub Check: format

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: CR
Repo: RocketChat/Rocket.Chat.ReactNative PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-07T17:49:17.538Z
Learning: Applies to app/lib/services/voip/**/*.{ts,tsx} : Implement VoIP with WebRTC peer-to-peer audio calls in app/lib/services/voip/ using Zustand stores instead of Redux, with native CallKit (iOS) and Telecom (Android) integration; keep VoIP and VideoConf separate

📚 Learning: 2026-04-07T17:49:17.538Z

Learnt from: CR
Repo: RocketChat/Rocket.Chat.ReactNative PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-07T17:49:17.538Z
Learning: Applies to app/lib/services/voip/**/*.{ts,tsx} : Implement VoIP with WebRTC peer-to-peer audio calls in app/lib/services/voip/ using Zustand stores instead of Redux, with native CallKit (iOS) and Telecom (Android) integration; keep VoIP and VideoConf separate

Applied to files:

• patches/react-native-callkeep+4.3.16.patch
• android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt

🔇 Additional comments (4)

android/app/src/main/AndroidManifest.xml (1)

141-141: LGTM — foreground service types match declared permissions.

Broadening foregroundServiceType to microphone|phoneCall is consistent with the FOREGROUND_SERVICE_PHONE_CALL permission declared at line 18 and the move to a self-managed Telecom ConnectionService in this PR.

android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt (1)

716-732: Self-managed PhoneAccount registration from native looks correct.

Good call registering from native in addition to JS — this closes the gap where an FCM push arrives before RNCallKeep.setup has run on JS. The API 26+ guard, CAPABILITY_SELF_MANAGED capability, and split SecurityException / generic catch are all appropriate, and registerPhoneAccount is documented as idempotent for the same handle, so repeated invocations on each incoming call are safe.

patches/react-native-callkeep+4.3.16.patch (2)

5-12: Handle ID aligned with native registration — nice fix.

Switching the RNCallKeep PhoneAccountHandle ID to context.getPackageName() matches the native-side construction in VoipNotification.registerCallWithTelecomManager (line 680), so both paths register/lookup the same PhoneAccount regardless of device locale or a translated app_name. This is the right pairing for the orphaned-account fix.

---

87-94: iOS _delayedEvents nil-guard looks correct.

This matches the upstream workaround for the referenced issue (events enqueued before _delayedEvents is initialized by startObserving/module init would previously be silently dropped). Lazy-allocating on first append is safe here since sendEventWithNameWrapper runs on the RN JS/main queue.

[github-actions]

Android Build Available

Rocket.Chat Experimental 4.72.0.108569

Internal App Sharing: https://play.google.com/apps/test/RQVpXLytHNc/ahAO29uNSRYW-2TFrOlHk24qg7j_ZmKTAlNXVqZrEzWaZucppIt6VCyp5_QpGKTvNjZHVJvAAMSGVQYb1OzdZtrLfR

[github-actions]

Android Build Available

Rocket.Chat 4.72.0.108570

Internal App Sharing: https://play.google.com/apps/test/RQQ8k09hlnQ/ahAO29uNQYwjBaLVyN1WC8TPQDMpkyVQVcRadBPowZxvCALz-B5I1RUN-9GrN0m64M1uE8dCndGe5QDqdHMHyaAevv

[github-actions]

Android Build Available

Rocket.Chat Experimental 4.72.0.108571

Internal App Sharing: https://play.google.com/apps/test/RQVpXLytHNc/ahAO29uNTY1nXdHE8lOll-W2sb3tsLQ9dJ92nAY11bezqbwCITOtfTcRvcyUdR8IHiZZ1eyUeqPa-mWooTNV45w3TM

[coderabbitai]

🧹 Nitpick comments (1)

patches/react-native-callkeep+4.3.16.patch (1)

45-52: Minor: getPhoneAccount(handle) is still invoked twice — residual NPE window.

The try/catch correctly handles SecurityException, but the expression calls telecomManager.getPhoneAccount(handle) twice. If the first call returns non-null and the second returns null (unlikely but possible if the account is deregistered between calls, or on certain OEM stubs), .isEnabled() NPEs despite the guard. Cache the result once:

🛡️ Proposed refactor

-        try {
-            return isConnectionServiceAvailable() && telecomManager != null &&
-                hasPermissions() && telecomManager.getPhoneAccount(handle) != null &&
-                telecomManager.getPhoneAccount(handle).isEnabled();
-        } catch (SecurityException e) {
+        try {
+            if (!isConnectionServiceAvailable() || telecomManager == null || !hasPermissions()) {
+                return false;
+            }
+            PhoneAccount account = telecomManager.getPhoneAccount(handle);
+            return account != null && account.isEnabled();
+        } catch (SecurityException e) {
             Log.w(TAG, "[RNCallKeepModule] hasPhoneAccount: SecurityException querying phone account", e);
             return false;
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@patches/react-native-callkeep`+4.3.16.patch around lines 45 - 52, The
expression calls telecomManager.getPhoneAccount(handle) twice causing a residual
NPE window; update the logic in the hasPhoneAccount (or equivalent) block to
call telecomManager.getPhoneAccount(handle) once, store the result in a local
variable (e.g., PhoneAccount account), then evaluate account != null &&
account.isEnabled() combined with the existing isConnectionServiceAvailable(),
telecomManager != null, and hasPermissions() checks inside the try/catch so the
null-check and isEnabled() use the same cached account instance.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@patches/react-native-callkeep`+4.3.16.patch:
- Around line 45-52: The expression calls telecomManager.getPhoneAccount(handle)
twice causing a residual NPE window; update the logic in the hasPhoneAccount (or
equivalent) block to call telecomManager.getPhoneAccount(handle) once, store the
result in a local variable (e.g., PhoneAccount account), then evaluate account
!= null && account.isEnabled() combined with the existing
isConnectionServiceAvailable(), telecomManager != null, and hasPermissions()
checks inside the try/catch so the null-check and isEnabled() use the same
cached account instance.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 198750cd-a8a3-420c-9969-083d36ddf66d

📥 Commits

Reviewing files that changed from the base of the PR and between 35dd976 and 1e3140f.

📒 Files selected for processing (1)

• patches/react-native-callkeep+4.3.16.patch

📜 Review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: ESLint and Test / run-eslint-and-test
• GitHub Check: format

🔇 Additional comments (5)

patches/react-native-callkeep+4.3.16.patch (5)

69-89: Unconditional PROPERTY_SELF_MANAGED — see prior note on coupling to the native registration path.

Consistent with VoipNotification.ensureSelfManagedPhoneAccountRegistered always using CAPABILITY_SELF_MANAGED. The added comment clearly documents the Android 11+ READ_PHONE_NUMBERS motivation. Still worth the caveat from the earlier review: any future RNCallKeep.setup({ selfManaged: false }) path would silently advertise a mismatched PROPERTY vs CAPABILITY and be rejected by Telecom — consider an assert/guard if that flow ever becomes reachable.

---

9-10: PhoneAccountHandle id correctly aligned with native registration.

Switching to context.getPackageName() matches the handle id used by VoipNotification.registerCallWithTelecomManager (PhoneAccountHandle(componentName, context.packageName)), so both JS-side and native-side resolve to the same account. Good fix.

---

67-67: Null-check on RNCallKeepModule.instance — the targeted PR fix looks correct.

This avoids the NPE in startForegroundService when VoiceConnectionService is started before (or outside of) the React module lifecycle (e.g., FCM background wake). The downstream if (currentActivity != null) already handles the null path gracefully.

---

100-101: iOS _delayedEvents lazy-init is correct.

Appending to a nil NSMutableArray is a silent no-op in Objective-C, so delayed events were being dropped until the array was first allocated elsewhere. The lazy-init here (backed by the linked upstream issue) fixes that cleanly.

---

18-37: No risk to app code—this codebase does not call these overloads from JavaScript.

The app never invokes RNCallKeep.displayIncomingCall() or RNCallKeep.startCall() from JS code. It instead uses the @rocket.chat/media-signaling SDK for call management (via mediaSessionInstance.startCall()). The displayIncomingCall method appears only in the test mock, never in production code. The 3-argument overloads being removed are not a breaking change for this application.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt`:
- Around line 666-667: The current error log in the validation branch prints raw
identifiers (callId and caller) which may expose sensitive data; update the
Log.e call in the same block (reference TAG, callId, caller) to avoid outputting
the actual values and instead log only that fields are empty or present (e.g.,
indicate which field is empty or true/false presence flags) and keep the message
descriptive about the TelecomManager registration failure without including the
caller or callId contents.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 011c4077-2f18-4e81-8f65-49efcfc60da0

📥 Commits

Reviewing files that changed from the base of the PR and between 1e3140f and 1e6b760.

📒 Files selected for processing (1)

• android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt

📜 Review details

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: CR
Repo: RocketChat/Rocket.Chat.ReactNative PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-07T17:49:17.538Z
Learning: Applies to app/lib/services/voip/**/*.{ts,tsx} : Implement VoIP with WebRTC peer-to-peer audio calls in app/lib/services/voip/ using Zustand stores instead of Redux, with native CallKit (iOS) and Telecom (Android) integration; keep VoIP and VideoConf separate

📚 Learning: 2026-04-07T17:49:17.538Z

Learnt from: CR
Repo: RocketChat/Rocket.Chat.ReactNative PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-07T17:49:17.538Z
Learning: Applies to app/lib/services/voip/**/*.{ts,tsx} : Implement VoIP with WebRTC peer-to-peer audio calls in app/lib/services/voip/ using Zustand stores instead of Redux, with native CallKit (iOS) and Telecom (Android) integration; keep VoIP and VideoConf separate

Applied to files:

• android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt

🔇 Additional comments (3)

android/app/src/main/java/chat/rocket/reactnative/voip/VoipNotification.kt (3)

677-687: LGTM — PhoneAccountHandle now uses a stable ID.

The context.packageName handle ID matches the patched RNCallKeep handle construction, while the localized app label is kept for display only.

---

711-715: LGTM — label lookup is scoped to display text.

This helper now supports the PhoneAccount label without feeding localized text into the persistent handle ID.

---

718-734: LGTM — native self-managed registration is guarded and contained.

The Android O+ guard, CAPABILITY_SELF_MANAGED, and exception handling fit the FCM-before-JS setup path.