Make building of resource zips and srcjars hermetic

Make building of resource zips and srcjars hermetic

When the inputs of a zip are the same, this ensures that the output zip
is the same by using a constant for file timestamps.

When making a change to base_java, and recompiling chrome_apk, time to
build went from 74sec -> 67sec

BUG=523420
Committed: https://crrev.com/5cb5ae912f80e5c7c6f7e71a8dc9b77ec7c87edf
Cr-Commit-Position: refs/heads/master@{#347097}

[agrieve, 2015-08-26 15:45:14]

agrieve@chromium.org changed reviewers:
+ jbudorick@chromium.org

[agrieve, 2015-09-01 15:00:43]

agrieve@chromium.org changed reviewers:
+ dpranke@chromium.org

[jbudorick, 2015-09-01 18:11:32]

jbudorick@chromium.org changed reviewers:
- dpranke@chromium.org

[jbudorick, 2015-09-01 18:11:33]

https://codereview.chromium.org/1319623002/diff/1/build/android/gyp/util/buil...
File build/android/gyp/util/build_utils.py (right):

https://codereview.chromium.org/1319623002/diff/1/build/android/gyp/util/buil...
build/android/gyp/util/build_utils.py:241: zipinfo =
zipfile.ZipInfo(filename=zip_path, date_time=HERMETIC_TIMESTAMP)
Maybe I'm not following ... if the inputs are the same, won't the timestamp be
the same? And if the timestamp changes, don't we want to update the zip?

[agrieve, 2015-09-01 19:06:16]

https://codereview.chromium.org/1319623002/diff/1/build/android/gyp/util/buil...
File build/android/gyp/util/build_utils.py (right):

https://codereview.chromium.org/1319623002/diff/1/build/android/gyp/util/buil...
build/android/gyp/util/build_utils.py:241: zipinfo =
zipfile.ZipInfo(filename=zip_path, date_time=HERMETIC_TIMESTAMP)
On 2015/09/01 18:11:33, jbudorick wrote:
> Maybe I'm not following ... if the inputs are the same, won't the timestamp be
> the same? And if the timestamp changes, don't we want to update the zip?

The most relevant example is in our process_resources.py step. The doesn't have
a good idea of when it needs to re-run, so it re-runs fairly aggressively,
(often) generating the same assets as before, but with new timestamps. Rules
that depend on process_resources use md5_check to see if the results have
changed, and if so re-run themselves. Without this change, the outputs looks
like they always change because md5_check is foiled by timestamps embedded in
the file.

[agrieve, 2015-09-02 14:51:35]

On 2015/09/01 19:06:16, agrieve wrote:
>
https://codereview.chromium.org/1319623002/diff/1/build/android/gyp/util/buil...
> File build/android/gyp/util/build_utils.py (right):
> 
>
https://codereview.chromium.org/1319623002/diff/1/build/android/gyp/util/buil...
> build/android/gyp/util/build_utils.py:241: zipinfo =
> zipfile.ZipInfo(filename=zip_path, date_time=HERMETIC_TIMESTAMP)
> On 2015/09/01 18:11:33, jbudorick wrote:
> > Maybe I'm not following ... if the inputs are the same, won't the timestamp
be
> > the same? And if the timestamp changes, don't we want to update the zip?
> 
> The most relevant example is in our process_resources.py step. The doesn't
have
> a good idea of when it needs to re-run, so it re-runs fairly aggressively,
> (often) generating the same assets as before, but with new timestamps. Rules
> that depend on process_resources use md5_check to see if the results have
> changed, and if so re-run themselves. Without this change, the outputs looks
> like they always change because md5_check is foiled by timestamps embedded in
> the file.

Remembered the other spot where this makes a difference: in creating .srcjar
files. 

There are rules for every library that has native libraries attached that create
a NativeLibraries.java file, then put it in a .zip file (called .srcjar). Before
this change the changing timestamp was causing the .jar to be re-compiled &
re-dex'ed even though the .java file wasn't changing (but was being re-written)

[agrieve, 2015-09-02 17:13:49]

agrieve@chromium.org changed reviewers:
+ dpranke@chromium.org

[Dirk Pranke, 2015-09-02 21:17:51]

lgtm

[agrieve, 2015-09-03 00:48:08]

The CQ bit was checked by agrieve@chromium.org

[commit-bot: I haz the power, 2015-09-03 00:48:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1319623002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1319623002/20001

[commit-bot: I haz the power, 2015-09-03 02:34:48]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-09-03 02:35:19]

Patchset 2 (id:??) landed as
https://crrev.com/5cb5ae912f80e5c7c6f7e71a8dc9b77ec7c87edf
Cr-Commit-Position: refs/heads/master@{#347097}