Add app indexing reporter public class.

chrome/android/java/res/raw/parse.js

Index: chrome/android/java/res/raw/parse.js
diff --git a/chrome/android/java/res/raw/parse.js b/chrome/android/java/res/raw/parse.js
new file mode 100644
index 0000000000000000000000000000000000000000..91a15b2aeb7240b0efac379aa00568e51f9ba300
--- /dev/null
+++ b/chrome/android/java/res/raw/parse.js
@@ -0,0 +1,9 @@
+/* Copyright 2017 The Chromium Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * TODO(dproctor): This works only for JSON-LD data. If we want to support other
+ * data formats, such as Microdata, RDF, etc. we'll need to include a parsing
+ * library.
+ */
+var a=document.querySelectorAll("script[type=\"application/ld+json\"]");if(a){ var b=[];a.forEach(function(s) {b.push(JSON.parse(s.innerHTML)) });b; }

[wychen, 2017/02/13 22:08:06]

A few corner cases we might want to handle:

{
  "@graph": [
    { ... your first JSON-LD block ... },
    { ... your second JSON-LD block ... }
  ]
}
Ref:
http://stackoverflow.com/questions/32841383/multiple-json-ld-tag-groups-in-on...

[
  {
    ...first JSON-LD
  },
  {
    ...second JSON-LD
  }
]
Ref:
http://stackoverflow.com/questions/30723531/best-json-ld-practices-using-mult...

Do you know how popular these are, compared with the typical case this CL can
handle?

[dproctor, 2017/02/13 23:11:57]

Hey, thanks for raising the issue. I didn't see any examples of these as I was
looking through head domains, I'm not aware of any easy way to query this
(sporedash/ doesn't cover it). However, I definitely think that we should
support both cases.

I'll add logic to the Java class the handle the @graph case. As for the second
case, what do you think about flattening the arrays, so, if you have 

<script>
[
  { JSON1},
  { JSON2},
]
</script>
<script>
[
  { JSON3},
  { JSON4},
]
</script>

we return [ {JSON1}, {JSON2}, {JSON3}, {JSON4} ]

?

[wychen, 2017/02/13 23:44:31]

I think flattening sounds nice, but then it would mean unpacking and packing the
JSON in Blink as well. If we keep using plain text manipulation, the output
would be [[ {JSON1}, {JSON2}], [{JSON3}, {JSON4} ]]. It might make sense to
consolidate the JSON handling logic to Java side. WDYT?