It looks like many Key System tests crash. These should run fine on M. I don't know that 64-bit has been tested, though. Is there a way to get the native call stack? boliu might be better able to help investigate this.

Who owns MediaCodecUtil?

06-23 23:53:49.239 15031 15050 W System.err: java.util.IllegalFormatConversionException: %d can't format java.lang.Boolean arguments
06-23 23:53:49.240 15031 15050 W System.err: 	at java.util.Formatter.badArgumentType(Formatter.java:1489)
06-23 23:53:49.240 15031 15050 W System.err: 	at java.util.Formatter.transformFromInteger(Formatter.java:1689)
06-23 23:53:49.240 15031 15050 W System.err: 	at java.util.Formatter.transform(Formatter.java:1461)
06-23 23:53:49.240 15031 15050 W System.err: 	at java.util.Formatter.doFormat(Formatter.java:1081)
06-23 23:53:49.240 15031 15050 W System.err: 	at java.util.Formatter.format(Formatter.java:1042)
06-23 23:53:49.240 15031 15050 W System.err: 	at java.util.Formatter.format(Formatter.java:1011)
06-23 23:53:49.240 15031 15050 W System.err: 	at java.lang.String.format(String.java:1554)
06-23 23:53:49.240 15031 15050 W System.err: 	at org.chromium.base.Log.formatLog(Log.java:52)
06-23 23:53:49.240 15031 15050 W System.err: 	at org.chromium.base.Log.e(Log.java:316)
06-23 23:53:49.240 15031 15050 W System.err: 	at org.chromium.media.MediaCodecUtil.createDecoder(MediaCodecUtil.java:223)
06-23 23:53:49.240 15031 15050 W System.err: 	at org.chromium.media.MediaCodecUtil.canDecode(MediaCodecUtil.java:157)

feedback on swarming: it made finding the logcat that corresponds to a test a *lot* more difficult (not that it was super easy before..), I believe there is a bug to fix that already..

we also lost native stack symbolization after swarming (afaik), and I know at least one instance where this caused more work for developers

-> dale for the stack in #2

I think liberato@ just landed this change.

That kinda indicates this code has never executed before until we started running that test..?

Issue 622942 has been merged into this issue.

c#6: https://codereview.chromium.org/2084143002/ modified the method MediaCodecUtil.canDecode() that is used in this test

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c0b1b3f71b5639502bf32eab0d083dd22e172851

commit c0b1b3f71b5639502bf32eab0d083dd22e172851
Author: liberato <liberato@chromium.org>
Date: Fri Jun 24 18:51:45 2016

Fix Log formatting in MediaCodecUtils.

BUG= 622927 
TEST=Added fake 'throw' to test the error condition.

Review-Url: https://codereview.chromium.org/2091253003
Cr-Commit-Position: refs/heads/master@{#401915}

[modify] https://crrev.com/c0b1b3f71b5639502bf32eab0d083dd22e172851/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/706549dfc00c63b6455ea416b3a1908a66b7bdcb

commit 706549dfc00c63b6455ea416b3a1908a66b7bdcb
Author: liberato <liberato@chromium.org>
Date: Wed Jun 29 15:25:00 2016

[M52] Make AVDA fall back to software decoding if needed.

This is a merge to M52 of:
https://codereview.chromium.org/2084143002
https://codereview.chromium.org/2091253003

Android MediaCodec creation will sometimes never come back.  On a
N7 (2013) with Lollipop, this can happens when an attempt to allocate
a hardware codec fails, and falls back to a software codec.  Once
mediaserver gets into a bad state, future attempts to create a
hardware codec will hang.  As a result, no additional AVDA instances
will get codecs.  Further, destroying any of them will hang the gpu
process when it tries to join the thread that handles construction.

This CL does several things:
    - Don't join the construction thread if there are outstanding
      MediaCodec creations on it.  While this may sometimes not
      shut down the thread if the AVDA is destroyed while the
      creation is pending (and would return if we just waited a bit
      longer), the thread will be shut down the next time an AVDA
      instance is destroyed.  It isn't leaked permanently.

    - Fall back to requesting a software codec if we believe that
      construction of a hardware codec is hung.  We don't attempt
      to salvage the AVDA instance(s) that have pending HW codecs,
      but future AVDA instances will fall back to software.  If
      those HW codecs are eventually allocated, then we will start
      requesting HW codecs again.  For example, if we simply time
      out too quickly, or if mediaserver is restarted, then we can
      try for hardware codecs for future AVDA instances.

    - Release hardware codecs on a separate thread, since that can
      hang too if mediaserver is in a bad state.

BUG=613238,  622927 
TBR=dalecurtis@chromium.org
NOPRESUBMIT=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2106133003
Cr-Commit-Position: refs/branch-heads/2743@{#519}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/media_codec_bridge.h
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/media_codec_util.cc
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/ndk_media_codec_bridge.cc
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/ndk_media_codec_bridge.h
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/sdk_media_codec_bridge.cc
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/base/android/sdk_media_codec_bridge.h
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/gpu/android_video_decode_accelerator.cc
[modify] https://crrev.com/706549dfc00c63b6455ea416b3a1908a66b7bdcb/media/gpu/android_video_decode_accelerator.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/125c85c497ce34c57b28e83ec252a1c7b7f76231

commit 125c85c497ce34c57b28e83ec252a1c7b7f76231
Author: dalecurtis <dalecurtis@chromium.org>
Date: Thu Jun 30 16:39:39 2016

Remove usage of MediaCodec.getName(), use proxy instead.

This method does not exist API < 18 and it is simpler to just
trust the |require_software_codec| value which is the inverse
of |allow_autodetection_|.

BUG=613238, 622927 ,624482
TEST=none

Review-Url: https://codereview.chromium.org/2114473002
Cr-Commit-Position: refs/heads/master@{#403197}

[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java
[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/base/android/media_codec_bridge.h
[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/base/android/ndk_media_codec_bridge.cc
[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/base/android/ndk_media_codec_bridge.h
[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/base/android/sdk_media_codec_bridge.cc
[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/base/android/sdk_media_codec_bridge.h
[modify] https://crrev.com/125c85c497ce34c57b28e83ec252a1c7b7f76231/media/gpu/android_video_decode_accelerator.cc