Expose NAN characteristics as an API.
(cherry-pick of commit 3a9de10963)
Bug: 31912101
Test: build and validate API updates
Change-Id: If02942d738aab8fa2f2f47489c6840af1bc38280
NAN discovery can expose location based on service signatures.
(cherry-pick of commit e1d8a5a6fc)
Bug: 31907534
Test: unit test + integrated (sl4a) testing
Change-Id: Iec0fae507dfdae65fe08ab6e2ddb89334c15def5
Validate publish and subscribe configurations and message length using
the NAN configuration retrieved from the firmware.
(cherry-pick of commit 65eaa6d821)
Bug: 31912101
Test: unit tests
Change-Id: I0328cabf1aafb3f350c5fe38e6d03b0e002c693b
When bond is created from Bluetooth Settings, profiles gets properly
auto connected when services are discovered. If pairing is done from any
other app, i.e. NFC app, the bond is not being recognized as initiated
from local device, and profiles are not connected.
This patch makes sure that if bonding is initiated, no matter from which
app, it will cause proper profiles to connect.
Bug: 30211618
Change-Id: I71131f33eb5b9db2f5b4a8737b191d541bf1fd3d
This CL adds the support for X509Certificate and PrivateKey objects.
Bug: 31834143
Test: frameworks/base/wifi/tests/runtest.sh
Change-Id: I1416a2aeeb0dfdd4a562d1a3b578addf55deb4ab
The original logic cuts down the mShownPosition, causing 1 pixel offset,
sometimes this will cause flash.
To fix this, Use Math.round() instead.
google issue:
https://code.google.com/p/android/issues/detail?id=224185
Change-Id: I8a2fe55a2df6eaa9eda4ba78966a74ea492ab8ea
The warnings were being hidden by the use of -isystem to include
frameworks/native/include.
Bug: 31752268
Test: m -j
Change-Id: Ib7227295e7b94c79cdc52e19c71be4066a11cedc
Broadcast can be registered protected (as in this CL) in which case they
are restricted to system apps. Broadcasts sent by the System Service must
be protected (so no one else can fake them).
The WIFI_NAN_STATE_CHANGED is sent by the System Service and no other apps
should be able to send them (e.g. to deny access to NAN to other apps).
(cherry-pick of commit b8ce87175e)
Bug: 31811154
Test: build & run - enable/disable Wi-Fi to trigger bug
Change-Id: I77ea18291d68c38a63d64a75affc6b7ea114e549
The migration of this config to CarrierConfig breaks the build on
certain devices, so we should leave the original config in.
Bug: 29873049
Change-Id: I2f526c37198359de7adec4cfd4c391ccaa8ab0be
Add KEY_EDITABLE_VOICEMAIL_NUMBER_BOOL and default value to
CarrierConfigManager, and remove the references to the old config in
core/res/res/values/[config.xml/symbols.xml]
This value exists to fix http://b/14093735. If a SIM card has no
voicemail number available, since the default number is empty, we allow
users to edit the voicemail number when this flag is true.
Merged-In: I68a494e2176306e4e9181a8ccb0aa818f3e08154
Bug: 29873049
Change-Id: I68a494e2176306e4e9181a8ccb0aa818f3e08154
We call uncrypt services to setup / clear bootloader control block (BCB)
for scheduling tasks under recovery (applying OTAs, performing FDR).
However, we cannot start multiple requests simultaneously. Because they
all use the same socket (/dev/socket/uncrypt) for communication and init
deletes the socket on service exits.
This CL fixes the issue by a) adding synchronized blocks for the service
requests; b) checking the availability of the socket before initiating a
new one.
Note that adding synchronized blocks to RecoverySystem doesn't help,
because the calls could be made from different processes (e.g. priv-app,
system_server).
Bug: 31526152
Test: FDR works while a priv-app keeps calling clear BCB.
Change-Id: I95308989e849a9c98a9503ac509f2bc51ed3de19
Remove old config within frameworks/base. With move to CarrierConfig no
need for the old editable_voicemailnumber resources.
Merged-In: Ib70ac5f488b45f32b705e471478e13802ebe9dd7
Bug: 29873049
Change-Id: Ib70ac5f488b45f32b705e471478e13802ebe9dd7
When using am dumpheap -n, modify the code to print the new
way malloc debug works instead of the old way.
Also, the old code had a hard-coded number of backtrace frames. The
new code allows this to be variable so the code needed to be modified
for this too.
Test: am dumpheap -n <PID> <FILE> dumps properly.
Change-Id: Id79e4acbe04313090eb2b973f023e5b27591bb7d
https://code.google.com/p/android/issues/detail?id=223731
It is possible that an activity in pending launches be resumed while
it's package was stopped by some other reason, like uninstall pkg.
Merged-In: I130ded89cee162aa59ac2bf330f026e49e16ef69
Change-Id: I130ded89cee162aa59ac2bf330f026e49e16ef69
Signed-off-by: liulvping <liulvping@xiaomi.com>
This will enable the developers to check if they could replace an unbuffered
I/O operation with a corresponding buffered I/O operation.
The policy can be set as follow:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectUnbufferedIO().build());
Test: vogar BlockGuardTest
Bug: 3018772
Change-Id: Ib804a8e9980ae40abfd216f8b87c250fd413bd5c
(cherry picked from commit 9b7184a8fd)w
