From b6ebe7580677a773bbe32b89d3cf01aff2e5b528 Mon Sep 17 00:00:00 2001 From: "bjornv@webrtc.org" <bjornv@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> Date: Mon, 23 Jun 2014 09:14:03 +0000 Subject: [PATCH] Disables tests that breaks Android bots BUG= TBR=kwiberg@webrtc.org Review URL: https://webrtc-codereview.appspot.com/15859004 git-svn-id: http://webrtc.googlecode.com/svn/trunk@6520 4adac7df-926f-26a2-2b94-8c16560cd09d --- .../modules/audio_processing/aec/system_delay_unittest.cc | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/webrtc/modules/audio_processing/aec/system_delay_unittest.cc b/webrtc/modules/audio_processing/aec/system_delay_unittest.cc index a13d47622..5fbc56003 100644 --- a/webrtc/modules/audio_processing/aec/system_delay_unittest.cc +++ b/webrtc/modules/audio_processing/aec/system_delay_unittest.cc @@ -248,7 +248,8 @@ TEST_F(SystemDelayTest, CorrectDelayAfterUnstableStartup) { } } -TEST_F(SystemDelayTest, CorrectDelayAfterStableBufferBuildUp) { +TEST_F(SystemDelayTest, + DISABLED_ON_ANDROID(CorrectDelayAfterStableBufferBuildUp)) { // In this test we start by establishing the device buffer size during stable // conditions, but with an empty internal far-end buffer. Once that is done we // verify that the system delay is increased correctly until we have reach an @@ -332,7 +333,7 @@ TEST_F(SystemDelayTest, CorrectDelayWhenBufferUnderrun) { } } -TEST_F(SystemDelayTest, CorrectDelayDuringDrift) { +TEST_F(SystemDelayTest, DISABLED_ON_ANDROID(CorrectDelayDuringDrift)) { // This drift test should verify that the system delay is never exceeding the // device buffer. The drift is simulated by decreasing the reported device // buffer size by 1 ms every 100 ms. If the device buffer size goes below 30 @@ -366,7 +367,7 @@ TEST_F(SystemDelayTest, CorrectDelayDuringDrift) { } } -TEST_F(SystemDelayTest, ShouldRecoverAfterGlitch) { +TEST_F(SystemDelayTest, DISABLED_ON_ANDROID(ShouldRecoverAfterGlitch)) { // This glitch test should verify that the system delay recovers if there is // a glitch in data. The data glitch is constructed as 200 ms of buffering // after which the stable procedure continues. The glitch is never reported by