diff --git a/OVERVIEW.TXT b/OVERVIEW.TXT
index f0b184c..3e20037 100644
--- a/OVERVIEW.TXT
+++ b/OVERVIEW.TXT
@@ -62,8 +62,8 @@
     Host Services:
       These services run within the ADB Server and thus do not need to
       communicate with a device at all. A typical example is "adb devices"
-      which is used to return the list of currently known devices and their
-      states. They are a few other services though.
+      that is used to return the list of currently known devices and their
+      states. There are a few other services, though.
 
     Local Services:
       These services either run within the adbd daemon, or are started by
@@ -77,7 +77,7 @@
 
   1. Client <-> Server protocol:
 
-    This details the protocol used between ADB clients and the ADB
+    This section details the protocol used between ADB clients and the ADB
     server itself. The ADB server listens on TCP:localhost:5037.
 
     A client sends a request using the following format:
diff --git a/OWNERS b/OWNERS
index 2108ae5..6cbf5b3 100644
--- a/OWNERS
+++ b/OWNERS
@@ -1,4 +1,4 @@
-jmgao@google.com
+shaju@google.com
 enh@google.com
 
 include platform/packages/modules/common:/MODULES_OWNERS  # see go/mainline-owners-policy
diff --git a/README.md b/README.md
index 224387c..5f37bf2 100644
--- a/README.md
+++ b/README.md
@@ -33,11 +33,11 @@
 
 A smart socket is a simple TCP socket with a smart protocol built on top of it. This is what Clients connect onto from the Host side. The Client must always initiate communication via a human readable request but the response format varies. The smart protocol is documented in [SERVICES.TXT](SERVICES.TXT).
 
-On the other side, the Server communicate with a device via a Transport. adb initially targeted devices connecting over USB, which is restricted to a fixed number of data streams. Therefore, adb multiplexes multiple byte streams over a single pipe via Transport. When devices connecting over other mechanisms (e.g. emulators over TCP) were introduced, the existing transport protocol was maintained.
+On the other side, the Server communicates with a device via a Transport. adb initially targeted devices connecting over USB, which is restricted to a fixed number of data streams. Therefore, adb multiplexes multiple byte streams over a single pipe via Transport. When devices connecting over other mechanisms (e.g. emulators over TCP) were introduced, the existing transport protocol was maintained.
 
 ## THREADING MODEL and FDEVENT system
 
-At the heart of both the Server and Daemon is a main thread running an fdevent loop, which is an platform-independent abstraction over poll/epoll/WSAPoll monitoring file descriptors events. Requests and services are usually server from the main thread but some service requests result in new threads being spawned.
+At the heart of both the Server and Daemon is a main thread running an fdevent loop, which is a platform-independent abstraction over poll/epoll/WSAPoll monitoring file descriptors events. Requests and services are usually served from the main thread but some service requests result in new threads being spawned.
 
 To allow for operations to run on the Main thread, fdevent features a RunQueue combined with an interrupt fd to force polling to return.
 
@@ -61,7 +61,7 @@
 
 The asocket, apacket, and amessage constructs exist only to wrap data while it transits on a Transport. An asocket handles a stream of apackets. An apacket consists in a amessage header featuring a command (`A_SYNC`, `A_OPEN`, `A_CLSE`, `A_WRTE`, `A_OKAY`, ...) followed by a payload (find more documentation in [protocol.txt](protocol.txt). There is no `A_READ` command because an asocket is unidirectional. To model a bi-directional stream, asocket have a peer which go in the opposite direction.
 
-An asocket features a buffer where the elemental unit is an apacket. Is traffic is inbound, the buffer stores apacket until they are consumed. If the traffic is oubound, the buffer store apackets until they are sent down the wire (with `A_WRTE` commands).
+An asocket features a buffer where the elemental unit is an apacket. If traffic is inbound, the buffer stores the apacket until it is consumed. If the traffic is oubound, the buffer stores apackets until they are sent down the wire (with `A_WRTE` commands).
 
 ```
 +---------------------ASocket------------------------+
diff --git a/SYNC.TXT b/SYNC.TXT
index 4445a76..1bc5d99 100644
--- a/SYNC.TXT
+++ b/SYNC.TXT
@@ -11,17 +11,17 @@
 differs from the regular adb protocol. The connection stays in sync mode until
 explicitly terminated (see below).
 
-After the initial "sync:" command is sent the server must respond with either
-"OKAY" or "FAIL" as per usual.
+After the initial "sync:" command is sent, the server must respond with either
+"OKAY" or "FAIL" as per the usual protocol.
 
 In sync mode both the server and the client will frequently use eight-byte
 packets to communicate. In this document these are called sync requests and sync
-responses. The first four bytes are an id that specifies the sync request. It is
-represented by four utf-8 characters. The last four bytes are a Little-Endian
-integer, with various uses. This number will be called "length" below. In fact
-all binary integers are Little-Endian in the sync mode. Sync mode is
-implicitly exited after each sync request, and normal adb communication
-follows as described in SERVICES.TXT.
+responses. The first four bytes constitute an id that specifies the sync request.
+It is represented by four ASCII bytes in order to make them more human-readable
+when debugging. The last four bytes are a Little-Endian integer, with various
+uses. This number shall be called "length" below. In fact, all binary integers
+are Little-Endian in the sync mode. Sync mode is implicitly exited after each
+sync request, and normal adb communication follows as described in SERVICES.TXT.
 
 The following sync requests are accepted:
 LIST - List the files in a folder
diff --git a/apex/apex_manifest.json b/apex/apex_manifest.json
index 4a07bdc..7c9dc75 100644
--- a/apex/apex_manifest.json
+++ b/apex/apex_manifest.json
@@ -1,4 +1,4 @@
 {
   "name": "com.android.adbd",
-  "version": 300900700
+  "version": 319999999
 }
diff --git a/socket_spec.cpp b/socket_spec.cpp
index c93b023..a71b2c9 100644
--- a/socket_spec.cpp
+++ b/socket_spec.cpp
@@ -264,7 +264,7 @@
             errno = EINVAL;
             return false;
         }
-        fd->reset(socket(AF_VSOCK, SOCK_STREAM, 0));
+        fd->reset(socket(AF_VSOCK, SOCK_STREAM | SOCK_CLOEXEC, 0));
         if (fd->get() == -1) {
             *error = "could not open vsock socket";
             return false;
@@ -374,7 +374,7 @@
             errno = EINVAL;
             return -1;
         }
-        unique_fd serverfd(socket(AF_VSOCK, SOCK_STREAM, 0));
+        unique_fd serverfd(socket(AF_VSOCK, SOCK_STREAM | SOCK_CLOEXEC, 0));
         if (serverfd == -1) {
             int error_num = errno;
             *error = android::base::StringPrintf("could not create vsock server: '%s'",