From 04ac49e193abe45fadda780668ff911b98ac3c3e Mon Sep 17 00:00:00 2001 From: uabdullah Date: Thu, 5 Apr 2018 07:22:44 -0700 Subject: 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 --- java/com/android/dialer/calllog/CallLogFramework.java | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'java/com/android/dialer/calllog') 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); -- cgit v1.2.3