Bug: 30645605
Change-Id: I9854ccbe98ace6d5490cb99586ca36379f5a1db1

Bug: 30832954
Change-Id: I37e0b2ffab65c0703244917a4ade9bb8afbb5e6f
(cherry picked from commit 9a236066)

BUG: 29824203

Change-Id: I795f8abe31575f70da263921c6ec13b73b24dc7b

commit efa6f355b06675aa4d0879fd279e22c16d5c046c
Author: Mikhail Naganov <mnaganov@google.com>
Date:   Wed Aug 10 12:25:13 2016 -0700

    MIDI: Use server-side socket in blocking mode for virtual devices

    Since virtual MIDI servers may misbehave, blocking mode will throttle
    them if clients are not coping with their sending speed.

    Bug: 29413812
    Change-Id: I9c4a2a7a7ea3ea060c93fedc7d0f033427c557c9

commit 755dfb5f83749d3963c63d98d692307f8271c804
Author: Mikhail Naganov <mnaganov@google.com>
Date:   Fri Jul 8 13:26:19 2016 -0700

    Protect MIDI framework against client blocks in MidiReceiver.onSend

    Make the server-side socket non-blocking when creating MidiOutputPort
    for clients. Thus if a client ceases to read from its side of the
    socket pair, the server will just fail to write instead of blocking.

    One drawback is that the MidiOutputPort on the client can't indicate
    that it has become dysfunctional, but it's not possible without
    changing the API.

    Bug: 29413812
    Change-Id: I9dfcbdd214a815cea8fd1365324fd78ca459268a

commit c740b13953761f58233ac651a0b5227733b1bdcc
Author: Mikhail Naganov <mnaganov@google.com>
Date:   Fri Jun 17 04:11:25 2016 -0700

    UsbMidiDevice: Clean up terminology and fix comments

    When working with physical MIDI devices, an *input* stream is used
    for reading from *output* port of the device, and vice versa. Thus,
    using "input" and "output" without specifying whether it's a stream
    or a port is confusing.

    Clarify names of counter variables, and fix a couple of comments
    that were incorrect due to this confusion. No functional changes.

    Change-Id: If561eaca4bade94e9296d2c703c9fcebc91296e2

commit 4269c6417287737624f6165a8bbeb5aa427de9a0
Author: Glenn Kasten <gkasten@google.com>
Date:   Thu May 5 18:49:16 2016 -0700

    Update MIDI package summary

    Bug: 28625060
    Change-Id: If552ca8e1a0666d402b5f536699bf3fb09c1e324

commit 862d40b73168bde7d0be5280d997985c18061014
Author: Phil Burk <philburk@google.com>
Date:   Tue Apr 19 15:56:24 2016 -0700

    MidiDevice: do not open ports on closed device

    Fix involves client side mIsDeviceClosed flag.

    Bug: 24949216
    Change-Id: I666284a787fbb9a710d2372fb424e8e54f6a2825
Signed-off-by: Phil Burk <philburk@google.com>

commit 6f1de358b9f2616e03f4655f01454770915ddd66
Author: Phil Burk <philburk@google.com>
Date:   Mon Apr 18 16:05:28 2016 -0700

    MidiService: fix resource leak

    The proxy object was being used to match when adding or removing objects.
    But they are different each time. So now we use an asBinder() object.

    Bug: 28153736
    Change-Id: I1bccebf1e9464668db757ff08b41902d0cf0e3a7
Signed-off-by: Phil Burk <philburk@google.com>

commit f7386bd535bb8a1d7f8df8f44a1748ab770c991a
Author: Phil Burk <philburk@google.com>
Date:   Tue Apr 5 14:19:53 2016 -0700

    MidiDevice: fix connectPorts for same Process

    If connectPorts() was called for a device in the same process then
    the connection would die when the ParcelFileDescriptor was closed.

    Bug: 26406775
    Change-Id: Id0538452593b4761ac2a93d366ade76d2e35ce73
Signed-off-by: Phil Burk <philburk@google.com>

Change-Id: I4dfc2a2cbaf04bf1a790ae2cb39bf74fb5bb16ac

The proxy MidiReceiver in the USB device was not forwarding the flush
command to the event scheduler.

Bug: 25511696
Change-Id: I6a4759b71bc8f9ae3e20aed1238f62a2ed405e24
Signed-off-by: Phil Burk <philburk@google.com>

Note that these additions are simply artifacts of the API generation
processes. These map methods were previously implemented by superclasses.

Test: make update-api

Change-Id: Ib03ca6afb438f2d7597abd0794cdebed2083bc17

* Add explicit keyword to conversion constructors.
Bug: 28341362
Test: build with WITH_TIDY=1

Change-Id: Ieab4756042e77cfadda35e34f78f515058ae0bb3

* Add explicit keyword to conversion constructors.
Bug: 28341362
Test: build with WITH_TIDY=1

Change-Id: I7422d703de17c4266d2a022990d0e1df40f48226

Change-Id: Ib2c8f2710cb333904106f849f492c83697fdd937

* Add explicit keyword to conversion constructors.
* Add NOLINT(implicit) comments for implicit conversion constructors.
Bug: 28341362
* Use const reference type for read-only parameters.
Bug: 30407689
* Use const reference type to avoid unnecessary copy.
Bug: 30413862
Test: build with WITH_TIDY=1

Change-Id: Id6d21961f313a1ad92b15a37fdaa5be9e8ab48e1
Merged-In: Id6d21961f313a1ad92b15a37fdaa5be9e8ab48e1

Bug: 30460956
Change-Id: I8d6e721b3b04f5ca9e3e02f7f2b90487482e1b37

Doing so is likely to trigger log messages in the future, and will
hinder diagnosis of other problems.

Bug: 30292538
Change-Id: I2cb8c507e43d06d4afa7e35b564416c1474c81d1

* Add explicit keyword to conversion constructors.
Bug: 28341362
* Use const reference type for read-only parameters.
Bug: 30407689
Test: build with WITH_TIDY=1

Change-Id: Iab3e6636f60a70cb124f29dc19f20f842fa8dfda
Merged-In: Iab3e6636f60a70cb124f29dc19f20f842fa8dfda

When handleRegisterNetworkAgent in ConnectivityService,
the networkinfo of NetworkAgentInfo will be set to null.
So we need to handle the null pointer of state.networkInfo.

Change-Id: I2a278f1f1b2455057fd2ed323ff4df340c3cbca9
Signed-off-by: zhangshuxiao <zhangshuxiao@xiaomi.com>

Change-Id: I73dd6af604304ea4eb8e01990454f491af659602

Let RuntimeInit use an UncaughtExceptionPreHandler to log an exception
rather than relying on UncaughtHandler, which apps can replace. This
makes it easier to diagnose application death, especially during app
compatibility testing for a new version of Android.

Test: Verified manually, with the help of a small sample app (not
checked in), that stacktraces for RuntimeExceptions thrown on main
or background threads are logged even when the app set a default
UncaughtExceptionHandler that swallows the exception with no action.

Note that such an inappropriate UncaughtExceptionHandler will still
cause threads to die without the app being killed, which it should be.
In an exception then happens on the main thread, the app will freeze
until the ANR dialog kicks in after a few seconds. I have manually
verified that this behavior is unchanged from before this CL.

No new integration tests are included because the default system
behavior has not changed.

Bug: 29624607
Change-Id: Ie87377b0bcadc3ba4083a8ab1bedb8f3dd95a4bd

The old version was seriously obsolete, primarily in that it ignored
C11 and C++11 atomics and the programming model underlying them.  As
a result it paid way too much attention to hardware characteristics,
which 0.001% of application programmers should really be aware of.
And some of those hardware descriptions were also obsolete.

This is a fairly complete rewrite.

Bug: 18523857

Change-Id: Icc14a390f74486193486c2ba07a86b05611e7d3c