tree 11bcf2c908ef0e1c4fe3f5a8591274202d33f53e
parent 3cde0f0c33581702008577c96790d3be80f1c6b0
author Tobias Thierer <tobiast@google.com> 1541004908 +0000
committer Tobias Thierer <tobiast@google.com> 1584963272 +0000

Refactor Network's use of mUrlConnectionFactory.

1.) Replace maybeInitUrlConnectionFactory() with a static method
    createUrlConnectionFactory(Dns) and move the logic to acquire
    the lock and initialize mUrlConnectionFactory out into
    openConnection. This makes it a bit clearer that the lock
    is acquired during openConnection().
2.) Use @GuardedBy("mLock") rather than a human readable comment
    on mUrlConnectionFactory.
3.) Make mUrlConnectionFactory non-volatile (since it's guarded by
    mLock), as recommended by Narayan on the review thread for
    http://r.android.com/370652
    Alternatively, the field could have remained volatile
    and we could have used double-checked locking to avoid
    acquiring the lock in the common case.
    The lock is only acquired during getSocketFactory() and
    openConnection(), so it shouldn't usually be contended.

This CL is a pure refactoring that shouldn't have any observable
behavior change.

Bug: 38311512
Test: Treehugger
Exempt-From-Owner-Approval: refactoring only, owner didn't respond in time
Change-Id: I1cf6075dc7cd994657b11d6a82de3ec63235fb1e