Update SK_IMAGE_VERSION to test RAW

tools/dm_flags.py

Index: tools/dm_flags.py
diff --git a/tools/dm_flags.py b/tools/dm_flags.py
index f7398b414695410cd1d55c2ab7c7d4c789dd1e79..beb3085b84930cb60edd505288a0c3a8fc233622 100755
--- a/tools/dm_flags.py
+++ b/tools/dm_flags.py
@@ -159,6 +159,13 @@ def get_args(bot):
     blacklist.extend([   '2ndpic-8888', 'gm', '_', test])
     blacklist.extend(['serialize-8888', 'gm', '_', test])
 
+  # NexusPlayer runs out of memory running RAW codec tests

[scroggo, 2016/02/01 15:05:13]

Should we file a bug for this? Alternatively, we could try fixing this bot
another way. For example, we could not run with threads on the NexusPlayer -
that way we will only have one RAW file open at a time, which might fix the
problem (at the expense of making the bot run more slowly).

One thing that might help, by at least reducing the memory used by the encoded
data, would be to share it between various CodecSrc's (and AndroidCodecSrcs,
BRDSrcs...). The problem with this approach is that we don't want to create the
SkData initially and hang on to it, since that would mean holding on to it
longer than necessary (basically from when it's first opened til when the last
source using it unrefs it). I could imagine a set of weakly referenced SkDatas,
so a CodecSrc (etc) could first check to see if the file has already been opened
and ref it.

My first thought was that the NexusPlayer probably doesn't do anything
interestingly different, so it's okay to skip these tests, but clearly it has
less memory, which could point out a problem with decoding a single image.
(OTOH, we *know* there are problems with the amount of memory the SkRawCodec
holds, so maybe this gives us no more useful info.)

[msarett, 2016/02/01 15:43:11]

I like this idea, but I think it would probably be too slow.  How do we decide
how slow is "too slow"?
I like this idea the best.  When thinking about large streams, it seems
particularly bad that we read them into memory over and over again for all of
the different scales and tests etc.

How hard do you think this would be?
I think it's worth filing a bug that we don't have any x86 (or x86-64) Android
bots that run the RAW code.  Not sure whether the fix is to fix the bot or add a
new bot.

Regardless, I agree that there isn't any interesting/different behavior not
covered by other Android bots or other x86 bots.

+  if 'NexusPlayer' in bot:
+    r = ["arw", "cr2", "dng", "nef", "nrw", "orf", "raf", "rw2", "pef", "srw",
+         "ARW", "CR2", "DNG", "NEF", "NRW", "ORF", "RAF", "RW2", "PEF", "SRW"]
+    for raw_ext in r:
+      blacklist.extend(('_ image _ .%s' % raw_ext).split(' '))
+
   if blacklist:
     args.append('--blacklist')
     args.extend(blacklist)