Initial CL for talking to the WebAPK server to generate WebAPK

chrome/browser/android/webapk/webapk.proto

+// Copyright 2016 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.
+
+syntax = "proto2";
+
+option optimize_for = LITE_RUNTIME;
+
+package webapk;
+
+// Creates a WebAPK on the server and returns URL to download WebAPK from Google
+// Play.
+message CreateWebApkRequest {
+  optional WebApk webapk = 1;
+}
+
+// Response to CreateWebApkRequest.
+message CreateWebApkResponse {

[pkotwicz, 2016/07/11 20:43:52]

This differs from the previously agreed version of the protos. It does not makes
sense for the WebAPK server to send to the client the bitmaps for all of the
icons in the Web manifest as a response.

The client cares about just one field the market_url.

The pattern of the request and the response being different is used in several
places in Chrome. One example is in
components/safe_browsing_db/safebrowsing.proto FindThreatMatchesRequest &
FindThreatMatchesResponse

[scottkirkwood, 2016/07/13 14:41:45]

You need to follow the proto at
http://cs/piper///depot/google3/google/chrome/webapk/v1alpha/webapk_service.p...

There is no CreateWebApkResponse message, anymore.

If you don't care about some fields you can put them as reserved = 1, 2, 3, etc.
and your code will ignore it.

Most of the fields in WebAPK response would be emptyfits in with how the API is
designed.

[pkotwicz, 2016/07/13 19:49:35]

Based on offline discussion, scottkirkwood@ will start a conversation with the
server API folks to see if we can bring back the CreateWebApkResponse message.

There does not seem to be any precedent in Chrome for sending the same proto in
the server request and recieving the same proto back from the server in the
server response.

[ScottK, 2016/07/21 19:46:20]

Also there are only 3 chrome APIs that I could find, so not a large set of
precedents using our API system.  Once we get the green light from the API folks
we should have the ability to change the messages the way we like.

+  // URL to download WebAPK from Google Play.
+  optional string signed_market_url = 5;
+}
+
+message WebApk {
+  // The URL of the Web App Manifest.
+  optional string manifest_url = 2;
+
+  // Chrome's package name.
+  optional string requester_application_package = 4;

[pkotwicz, 2016/07/11 20:43:52]

The server proto says that "requester_application_version" is required. I am
excluding it because we do not need to send the field yet (We may need to in the
future)

[Yaron, 2016/07/13 00:24:01]

It should be required though. Isn't the host application package one of the
template fields in the manifest?

[pkotwicz, 2016/07/13 02:15:30]

Sorry for the confusion. I am purposefully excluding the
"requester_application_version" field. I am including the
"requester_application_package". The "requester_application_package" is used to
populate the host application package field in the Android Manifest

The server proto requires both "requester_application_version" and
"requester_application_package"

[scottkirkwood, 2016/07/13 14:41:45]

You really should send it as we use this as part of the row key.

[pkotwicz, 2016/07/13 19:49:35]

Based on offline discussion we do not use "requester_application_version" as
part of the row key but we use "requester_application_package"

[Yaron, 2016/07/19 17:31:13]

Actually, please add the version number now. The number of bytes we're talking
about is trivial and the flexibility it offers in the server is not to be
underestimated. A simple example is being able to protect the server from a
buggy client release.

[pkotwicz, 2016/07/20 05:13:41]

Done.

+
+  // The Web App Manifest.
+  optional WebAppManifest manifest = 6;
+}
+
+// Contains data from the Web App Manifest.
+message WebAppManifest {
+  optional string name = 1;
+  optional string short_name = 2;
+  optional string start_url = 4;
+  repeated string scope = 5;
+  repeated Image icon = 6;

[pkotwicz, 2016/07/11 20:43:52]

The names of the repeated fields are "scope" instead of "scopes" and "icon"
instead of "icons" because these names make the generated code make more sense.

webapk::Image* webapk::WebAppManifest::add_icon()
makes more sense than
webapk::Image* webapk::WebAppManifest::add_icons()

[scottkirkwood, 2016/07/13 14:41:45]

That was the old recommendation, now the new recommendation is to pluralize:
Please see http://shortn/_nk2AGQpWvJ

[pkotwicz, 2016/07/13 19:49:35]

Done.

+  optional string orientation = 9;
+  optional string display_mode = 10;
+
+  // Colors are in ARGB format. 0x80000000 if the color was not specified in
+  // the manifest.

[pkotwicz, 2016/07/11 20:43:52]

The colors are ints instead of CSS strings as previously discussed.

[pkotwicz, 2016/07/11 20:47:33]

The default looks wrong but that's what content::ManifestParser uses. I will
investigate why it uses such a weird value.

[scottkirkwood, 2016/07/13 14:41:45]

Right, and we agreed you should pass strings in the format "#FEFEFE".

[pkotwicz, 2016/07/13 19:49:35]

Done.

+  optional uint64 theme_color = 11;
+  optional uint64 background_color = 12;
+}
+
+message Image {
+  // Image's URL.
+  optional string src = 1;
+
+  // MD5 hash of the icon's bytes. There should not be any transformations
+  // applied to the icon's bytes prior to taking the MD5 hash.

[pkotwicz, 2016/07/11 20:43:52]

I excluded the "hash_method" field in the server proto. If no "hash_method" is
specified the server should assume MD5.

[scottkirkwood, 2016/07/13 14:41:45]

fine, please just "reserve" all fields you are not using.

[pkotwicz, 2016/07/13 19:49:35]

Done.

+  optional string hash = 5;
+
+  // Actual bytes of the image. This image may be re-encoded from the original
+  // image and may not match the MD5 hash field above.
+  optional bytes image_data = 6;
+}