Remove timestamps from AARs [67597902]

Fixed

Feature Request

Status Update

No update yet.

Description

au...@google.com

created issue #1

Oct 9, 2017 09:00PM

Currently Android Gradle Plugin (AGP) builds jars that have time stamps stripped (yay), but the rest of the contents inside aars have time stamps (boo), which makes aars non-reproducible (e.g. if you build the same aar a minute later you will get a different sha1 of the aar).

It would be great if AGP included an option to drop all the timestamps from all the files inside the aar.

Comments

cm...@google.com <cm...@google.com> #2Nov 15, 2017 10:27AM

Assigned to cm...@google.com.

We should just do this by default.

xa...@google.com <xa...@google.com> #3Nov 15, 2017 05:48PM

Agreed.

The timestamp don't matter for Gradle consumers because Gradle will ignore them when doing up-to-date checks, but it's just better not to have them.

au...@google.com <au...@google.com> #4Dec 12, 2017 05:32PM

Is this going to make it to 3.1? If no, what workarounds could we do to our tasks to strip all these timestamps?

cm...@google.com <cm...@google.com> #5Dec 12, 2017 05:40PM

Probably not. There's some done.

au...@google.com <au...@google.com> #6Dec 12, 2017 05:48PM

Can you elaborate a bit more? What is done and what is still missing? Could we add steps on top of your tasks to strip it ourselves?

je...@google.com <je...@google.com> #7Dec 13, 2017 05:27PM

Reassigned to st...@google.com.

Stephen, please reach out to cmw@ for context.

cm...@google.com <cm...@google.com> #8Dec 20, 2017 06:16PM

For context, the AAR itself uses deterministic ordering and does not keep timestamps, the issue is the jars in it, where I believe the order of entries in them is not deterministic.

au...@google.com <au...@google.com> #9Dec 20, 2017 06:29PM

That's not true from my observations. If I take an AAR of support-compat and look inside of it all the files inside the aar have timestamps (including the classes.jar), however classes.jar itself has not timestamps inside.

See attached screenshot and attached AAR.

Screenshot from 2017-12-20 10-27-02.png

249 KB

View

Download

support-compat-27.0.2.aar

525 KB

Download

cm...@google.com <cm...@google.com> #10Dec 20, 2017 07:05PM

Timestamps in the jars are 0, but the entry ordering is not necessarily
deterministic.

On Wed, 20 Dec 2017, 18:29 aurimas, <buganizer-system+aurimas@google.com>
wrote:

- Show quoted text -

au...@google.com <au...@google.com> #11Jan 11, 2018 09:23PM

Can this make it to 3.2?

au...@google.com <au...@google.com> #12Jan 11, 2018 09:29PM

I would really like to make this a P1 so it makes it to 3.2. It would save us a lot of test runs when try to submit these binaries for internal google app consumption.

je...@google.com <je...@google.com> #13Jan 11, 2018 09:42PM

Any update on this? (I’d be happy to take a crack at it if that could help)

xa...@google.com <xa...@google.com> #14Jan 11, 2018 09:48PM

I agree we should fix this for 3.2. However, feel free to take a stab at it if you have bandwidth.

je...@google.com <je...@google.com> Feb 16, 2018 12:32AM

Accepted by je...@google.com.

je...@google.com <je...@google.com> Feb 22, 2018 12:30AM

Marked as fixed.

au...@google.com <au...@google.com> #15Feb 22, 2018 12:32AM

Can you comment on #10? cmw@ mentioned that the jar ordering is not deterministic. Is that true?

je...@google.com <je...@google.com> #16Feb 22, 2018 02:11PM

I didn't notice #10 to be a problem for Support Library anyway.

When I updated the dependency from Support Library to Android Gradle Plugin to be the latest version (3.2.0-dev) and ran two fresh builds in a row on my computer, I found that the .aar files were binary equal between the two builds.

I did find a few other files to be different, but I guess that none of the differing files were embedded in any .aar files

cm...@google.com <cm...@google.com> #17Feb 26, 2018 02:26PM

The jar ordering is currently dependent on file system iteration ordering.