Add getTetheredDhcpRanges() interface and call it before calling
mNwService.startTethering() to update dhcp ranges. This will allow p2p app
to run well concurrently with other tethering app(e.g. usb tethering).
Change-Id: I5e8ffeb5d2d396f48b897cd9396f133e25ecca57
Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
When there was no thumbnail for a given image, the getThumbNail() convenience
method could return a previously-returned thumbnail instead of null.
b/15771860
https://code.google.com/p/android/issues/detail?id=40714
Change-Id: Ibd18e048145bf347469f800afdf436247ea6b693
Client has to call recycle() on parcel object after its usage
otherwise native layer of binder won't clear the resources of
parcel which were allocated for IPC
Change-Id: Ib31ddcc92aa4ebd80bb66729922b9133692e9c9e
64-bit process will have virtual addresses that don't fit in an
unsigned long if ActivityManagerService is in a 32-bit process,
and the locations of the '-' and ' ' characters in the maps
are not predictable. Fix the sscanf for finding the start of the
mapping, and use it again to find the end of the mapping. Also
fix a few 64-bit warnings.
Change-Id: I8855c76085142768be1d45346f1032fd37cbe4eb
The existing code for notification manager/listeners uses a oneway
binder api to deliver messages. One problem with this is that
notification objects can sometimes get fairly large, and can bump
into the oneway binder transaction buffer if many happen at once.
To reduce this issue, flip the service into a oneway delivery of
a status bar notification holder, whose wrapped content is then
immediately fetched upon receipt of the one-way message. This moves
the meat of the fetch to be over a two-way interface without changing
the properties of which object is actually sent (a tickle solution
with lookup key would have changed this)
Further research: attempt to chunk notification objects themselves.
They can sometimes transfer hundreds of KB over a binder transaction.
Bug: 15426276
Change-Id: Ib1a1f4ff848c16f80bcf2ae4dfd2b87a9091f0b2
----
Explicitly track consumed state for WindowInsets
Treating 0-insets as fully consumed is incorrect since it means that
you can't dispatch empty insets down the view hierarchy - traversal
terminates immediately. Track consumed state independent of actual
values. Replacing a given set of insets with all zeroes will mark it
consumed.
----
Fix incorrect dispatch of empty WindowInsets from ActionBarOverlayLayout
Fix a bug where ActionBarOverlayLayout was using a private constructor
of WindowInsets to return empty insets that should have been marked
fully consumed. This caused dispatch to further child views not to
stop appropriately, corrupting application layout in some cases.
---
Fix CTS regression in fitSystemWindows
Don't attempt to apply null insets from a call to fitSystemWindows.
Immediately return false since null insets cannot be applied.
----
Bug: 15452706
Change-Id: I34276a90305b141b4653aef0048f70350c69d02a
- Do not call IActivityContainer.release() from
ActivityView.finalize() if it has already been called from
ActivityView.release(). Eliminates IBinder finalized Exception.
- Call ActivityRecord.makeFinishing() before calling ActivityStack.
destroyActivityLocked(). Forces call to scheduleDestroyActivity()
and eventually removeFromHistory(). Otherwise removeFromHistory()
is never called and window manager AppWindowTokens become orphans.
- Defer call to ActivityContainer.detachLocked() until all
activities have finished or timed out. Fixes problem where Display
is removed while activities are still launching.
- Call ActivityStackSupervisor.deleteActivityContainer() when all
activities have finished or timed out. Fixes orphaned
ActivityContainers.
Fixes bug 15450798.
Fixes bug 15484154.
Fixes bug 15383479.
Fixes bug 15316558.
Fixes bug 15168560.
Fixes bug 15143914.
Change-Id: Id3c641976b6f825458690f9ee063c07818b56f23
