Add "usages" field to Image in WebApk.proto

chrome/browser/android/webapk/webapk.proto

Index: chrome/browser/android/webapk/webapk.proto
diff --git a/chrome/browser/android/webapk/webapk.proto b/chrome/browser/android/webapk/webapk.proto
index 05615266b6673f476a9457578ac0f929d1ffcd51..c445140425420e3c6b8faf4fe4012ab277145f73 100644
--- a/chrome/browser/android/webapk/webapk.proto
+++ b/chrome/browser/android/webapk/webapk.proto
@@ -71,6 +71,12 @@ message WebAppManifest {
 }
 
 message Image {
+
+  enum Usage {

[hartmanng, 2017/02/07 14:53:22]

It could be useful to have a

USAGE_UNDEFINED = 0;

as well.

[F, 2017/02/08 15:32:14]

Resolved offline :)

+    PRIMARY_ICON = 1;

[hartmanng, 2017/02/07 14:53:22]

I haven't been following discussions around this - can you explain quickly why
we're diverging from the spec here? Under what conditions do we determine that
an icon is a "primary icon"? Is it just whenever it's not a badge?

[hartmanng, 2017/02/07 18:18:29]

We've discussed offline and I understand the situation now. Thanks for
explaining, Felix.

[F, 2017/02/08 15:32:14]

:)

+    BADGE_ICON = 2;
+  }
+
   // Image's URL.
   optional string src = 1;
 
@@ -82,5 +88,8 @@ message Image {
   // image and may not match the murmur2 hash field above.
   optional bytes image_data = 6;
 
+  // Specifies intended usages for the image.
+  repeated Usage usages = 7;

[pkotwicz, 2017/02/07 14:38:06]

If we end up putting this information in the Android Manifest, we should make
this a repeated field of string.

The reason is that other browsers may want to extract the values from the
Android Manifest. The string values are specified by the spec so are unlikely to
change. The enum values are not specified by the spec so using them from a
non-Chrome browser perspective is more risky.

[hartmanng, 2017/02/07 14:53:22]

We've actually already added a Purpose member to the server-side proto (my
apologies for not pointing you to it earlier, completely slipped my mind).

We don't use it for anything yet, and it would be quite easy for us to change,
so we can still support the strategy in this CL if it's better. However, if we
go with "Usages" instead of "Purposes" here, please mark 7 as "reserved" and use
8 for Usages to avoid proto incompatibility.

[hartmanng, 2017/02/07 18:18:29]

To sum up our offline conversation, I think what we should do (for now, at
least), is that you should go forward with this CL and land a Usages member, and
leave Purposes out for the time being.

Please do mark 7 as reserved and move Usages to 8 in this CL, though.

[hartmanng, 2017/02/07 18:18:29]

That's not entirely true. The Usage type isn't exactly the same as the spec's
official Purpose type. It's true that the spec defines "badge" as a kind of
Purpose, but as far as I understand, the spec has no concept of a primary icon -
that's a Chrome abstraction.

[F, 2017/02/08 15:32:14]

Done. Thanks for pointing out 7 is already used :)

+
   reserved 2 to 4;
 }