This will let us see (a) whether the user has a legit build or something they
built themselves and (b) what Android release it corresponds to.
This isn't as useful as showing what Platform Tools release we correspond to,
but I'm planning on doing that as a separate line.
Bug: N/A
Test: adb --version ; fastboot --version
Change-Id: Idca489295e3c6f8571146f95822c08808e36b382
ashmem buffers start with PROT_EXEC | PROT_READ | PROT_WRITE and can
have bits individually removed (but not added) through the
ASHMEM_SET_PROT_MASK ioctl. Test that removing prot bits more than once
works, and that the kernel blocks adding prot bits.
Also test that the complementary ASHMEM_GET_PROT_MASK ioctl returns the
expected prot mask.
Test: /data/nativetest64/libcutils_test/libcutils_test64 \
--gtest_filter=AshmemTest.* (on hikey)
Test: /data/nativetest/libcutils_test/libcutils_test32 \
--gtest_filter=AshmemTest.* (on hikey)
Change-Id: If7b13672547ec4cf6dfd1886197f40f12b2f1c85
Signed-off-by: Greg Hackmann <ghackmann@google.com>
ashmem has in-kernel handlers for lseek() and read(), but they aren't
currently being tested.
Add tests for various seeks on a buffer containing holes. If we land
inside data, then check that we read() the expected data at that offset.
Test: /data/nativetest64/libcutils_test/libcutils_test64 \
--gtest_filter=AshmemTest.* (on hikey)
Test: /data/nativetest/libcutils_test/libcutils_test32 \
--gtest_filter=AshmemTest.* (on hikey)
Bug: 37254818
Change-Id: I96135a8cea2ce99932e3bc97b5254c95ef6b264a
Signed-off-by: Greg Hackmann <ghackmann@google.com>
A couple of folks had trouble understanding the existing message.
Before:
8XV7N15917000596 no permissions (udev requires plugdev group membership); see [http://developer.android.com/tools/device.html]
After:
8XV7N15917000596 no permissions (user buttmunch is not in the plugdev group); see [http://developer.android.com/tools/device.html]
This also fixes a libusb regression where we wouldn't show anything for
devices where we don't have permissions.
Bug: http://b/37707122
Test: ran "adb devices" as user buttmunch
Change-Id: I2fcd735ff4178145432b532a6e4dc8c93b2743fd
Current AVB flow in fs_mgr doesn't allow verification error even if the
device is unlocked. This makes first stage mount fail when the device
is flashed with a different-sized boot.img because there is verification
error (HASH_MISMATCH) for the boot partition.
Fix this by allowing verification error only when the device is
unlocked. Whether to enable dm-verity for HASHTREE partitions is still
controlled by the HASHTREE_DISABLED flag in the top-level vbmeta.
Bug: 37985430
Test: First stage mount /vendor with AVB on a device.
Check dm-verity is enabled on /vendor.
Test: Unlock device, flash a different-sized boot.img. Boot device and check
dm-verity is still enabled on /vendor.
Test: First stage mount /vendor with AVB on a device with HASHTREE_DISABLED
is set on the top-level vbmeta, check dm-verity is not enable on /vendor.
Change-Id: I709431bc1c37e4f86133d171cee8e90621cdb857
- It was using blk dev name from fstab and quota / super block check was always
failing for FDE
bug: 37913441
Test: reboot and confirm quota
Change-Id: I8a9e890ef2787f2959e6a0225c6b21d35602f19e
Test: Boot on bullhead.
Test: Ran the libbacktrace tests on bullhead.
Test: Added a temporary log message in the signal handler, and ran the
Test: backtrace tests.
Change-Id: I0a6888c9f311af2c8cc7fbb4929315911bd2bb3c
Replace a hard-coded 3 second sleep with logic to wait until we've
scanned USB devices once and they've all come online.
Before:
adb shell true 0.00s user 0.00s system 0% cpu 3.047 total
After:
adb shell true 0.00s user 0.00s system 9% cpu 0.041 total
Bug: http://b/37869663
Test: `time adb shell true` after adb kill-server
Change-Id: I251d42afb885908ed9d03167287594ea16650d3f
Use fdevent_run_on_main_thread to initialize mDNS in a thread and
register an fdevent from the main thread upon success.
This reduces the startup time of `adb server` by ~3 seconds when mDNS
can't be successfully started. With an already running adb server,
`time adb server nodaemon` goes from:
adb server nodaemon 0.00s user 0.16s system 4% cpu 3.817 total
to:
adb server nodaemon 0.00s user 0.01s system 1% cpu 0.665 total
Bug: http://b/37869663
Test: `adb server nodaemon` with an existing adb server
Change-Id: Ia5a1a2a138610f3bf6792400050ca68f95ae3734
Add a function to run a function on the main thread, to allow fdevents
that depend on a blocking function to be registered.
Bug: http://b/37869663
Test: adb_test on linux
Change-Id: I84a0b372360420b7647057297b8f437e8afa874e
Private interface to permit testing only added to fs_config to
expose android_files and android_dirs.
Make sure that both paths to a partition are specified in fs_config
internal tables.
Test: gTest libcutils-unit-test --gtest_filter=fs_config.*
Bug: 37703469
Change-Id: Ida5fccdb786dc6d67325005d4fdd1fa1ffaef396
The exec_service documentation was difficult to read, clarify it.
Tests:
Run grip.py to verify that the markdown still works correctly.
Run aspell to verify spelling.
Change-Id: I29bdd456f3d3ea2a91c9d4772bd09a5a195f97a9
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Also, add a link to the .clang-format-2 for this directory and clang
format the files that changed.
Bug: 31919199
Test: Boot bullhead.
Test: Run unit tests on bullhead. There are a few that fail, but they
Test: failed before and are not a result of this change.
Change-Id: I3d3b2111f6f6bf8a0d7039295d34d5168c191651
Files in the ramdisk by default have the rootfs label and must be
manually restoreconed.
Bug: 35219933
Change-Id: I2a749f128dc3a609907101ce703747f8990b4386
Invent keyutils.h to supply capability to set session keyring.
The keyring will hold things like the FBE encryption keys.
Test: gTest logd-unit-tests --gtest_filter=logd.statistics
Bug: 37751120
Bug: 36645158
Change-Id: Ieb44fa8f53dda6cf506a6243498c72d7f7f3cde7
For legacy reason, /data/data is a real dir and /data/user/0 is a
symbolic link to it. Overhead for linux kernel to walk through
symbolic link is not negligible. This is unnessary overhead to
carry over. This patch is to make /data/user/0 a a real dir and
make legacy folder /data/data a symbolic link. OTAed system does
not get impacted.
Test: Manual test
Change-Id: I419564a75f6ebf3154badb8725ba9831164592b6
Signed-off-by: cjbao <cathy.bao@intel.com>
Refine DAC security surrounding logd.daemon worker thread and add a
positive test for logd failure to access /data/system/packages.list.
- Add AID_PACKAGE_INFO to groups of worker thread.
- Move AID_SYSTEM to groups, setgid to AID_LOGD.
- Do not drop capabilities until after setting the uid and gids.
- Add a test that is part of logd.statistics test to check when
packagelistparser appears broken.
- If /data/system/packages.list is encrypted, ensure we do not pick
up the existing inode to ensure strong positive when finding access
problems.
- Replace all occurrences of NULL with nullptr in gTest code for
compliance with best practices.
Test: gTest logd-unit-tests --gtest_filter=logd.statistics
(expect consistent failure, later CLs fix)
Bug: 37751120
Bug: 36645158
Change-Id: I01b26fe5e25203246ae432d272c8daa9c07cab54
Delete the sysdeps/mutex tests that -Wthread-safety complains about.
We're using the standard library's std::mutex on all platforms now,
anyway.
Test: mma
Change-Id: I3bf958c72604b29dfb1d9c898d3c9aa34aed2685
Similar to what installkey used to do, init_user0 forks and
synchronously waits for vdc to return. This is dangerous to do in
init however as init also processes properties from a single thread.
I'm not aware of any specific issues that this is currently causing,
but it's a good preventative measure to match what installkey does and
use do_exec().
Test: Boot bullhead, see that init_user0 still happens
Change-Id: I853c61594fe3d97e91bbb2319ebddf2bbe80d457
Previously, adb was assuming a fixed maximum packet size of 1024 bytes
(the value for an endpoint connected via USB 3.0). When connected to an
endpoint that has an actual maximum packet size of 512 bytes (i.e.
every single device over USB 2.0), the following could occur:
device sends amessage with 512 byte payload
client reads amessage
client tries to read payload with a length of 1024
In this scenario, the kernel will block, waiting for an additional
packet which won't arrive until something else gets sent across the
wire, which will result in the previous read failing, and the new
packet being dropped.
Bug: http://b/37783561
Test: python test_device.py on linux/darwin, with native/libusb
Change-Id: I556f5344945e22dd1533b076f662a97eea24628e
