Support new voicemail fragment in old peer.

This makes the old peer read the CallLogConfig#isNewVoicemailFragmentEnabled and show the old or new fragment accordingly.

If the user is viewing the NewVoicemail and the CallLogConfig needs to disable the framework, the new fragment is immediately replaced with the old one. This is necessary because if the user were to scroll the fragment, the AnnotatedCallLog database would be read, which would trigger creation.

I tested this by flipping flags and observing underlying data being removed:

> dialer-cmd configprovider set new_voicemail_fragment_enabled false

> adb shell ls /data/data/com.google.android.dialer/databases/ && echo && adb shell cat /data/user_de/0/com.google.android.dialer/shared_prefs/com.google.android.dialer_preferences.xml

I test flipping flags back and forth on the voicemail tab, call log tab and ensuring that they are independent.

Bug: 77601968
Test: unit and manual. Some tests are failing, so to ensure we can have the voicemail ready for the bug bash tomorrow, I've ignored them temporarily but will be fixed in a follow up CL (tracked by b/77601893)
PiperOrigin-RevId: 191738860
Change-Id: I24ca38b862e98324cf802a3020e7e9df31c0b966

1 files changed, 6 insertions, 5 deletions

diff --git a/java/com/android/dialer/calllog/CallLogFramework.java b/java/com/android/dialer/calllog/CallLogFramework.java
index b86bfbc10..be4db0675 100644
--- a/java/com/android/dialer/calllog/CallLogFramework.java
+++ b/java/com/android/dialer/calllog/CallLogFramework.java
@@ -101,12 +101,13 @@ public final class CallLogFramework {
     return Futures.transform(
         Futures.allAsList(allFutures),
         unused -> {
-          // Send a broadcast to the OldMainActivityPeer to remove the NewCallLogFragment if it is
-          // currently attached. If this is not done, user interaction with the fragment could cause
-          // call log framework state to be unexpectedly written. For example scrolling could cause
-          // the AnnotatedCallLog to be read (which would trigger database creation).
+          // Send a broadcast to the OldMainActivityPeer to remove the NewCallLogFragment and
+          // NewVoicemailFragment if it is currently attached. If this is not done, user interaction
+          // with the fragment could cause call log framework state to be unexpectedly written. For
+          // example scrolling could cause the AnnotatedCallLog to be read (which would trigger
+          // database creation).
           LocalBroadcastManager.getInstance(appContext)
-              .sendBroadcastSync(new Intent("disableNewCallLogFragment"));
+              .sendBroadcastSync(new Intent("disableCallLogFramework"));
           return null;
         },
         uiExecutor);