Skip to content

Commit dd7bc33

Browse files
author
The Android Open Source Project
committed
auto import from //depot/cupcake/@135843
1 parent e54eebb commit dd7bc33

File tree

466 files changed

+107173
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

466 files changed

+107173
-0
lines changed

‎Android.mk

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
#
2+
# Copyright (C) 2008 The Android Open Source Project
3+
#
4+
# Licensed under the Apache License, Version 2.0 (the "License");
5+
# you may not use this file except in compliance with the License.
6+
# You may obtain a copy of the License at
7+
#
8+
# http://www.apache.org/licenses/LICENSE-2.0
9+
#
10+
# Unless required by applicable law or agreed to in writing, software
11+
# distributed under the License is distributed on an "AS IS" BASIS,
12+
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13+
# See the License for the specific language governing permissions and
14+
# limitations under the License.
15+
#
16+
LOCAL_PATH := $(my-dir)
17+
18+
ifneq ($(TARGET_SIMULATOR),true)
19+
include $(call first-makefiles-under,$(LOCAL_PATH))
20+
else
21+
include $(addprefix $(LOCAL_PATH)/,$(addsuffix /Android.mk, \
22+
adb \
23+
libcutils \
24+
liblog \
25+
libnetutils \
26+
libpixelflinger \
27+
libzipfile \
28+
))
29+
endif

‎README

+20
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
2+
The system/ directory is intended for pieces of the world that are the
3+
core of the embedded linux platform at the heart of Android. These
4+
essential bits are required for basic booting, operation, and debugging.
5+
6+
They should not depend on libraries outside of system/... (some of them
7+
do currently -- they need to be updated or changed) and they should not
8+
be required for the simulator build.
9+
10+
The license for all these pieces should be clean (Apache2, BSD, or MIT).
11+
12+
Currently system/bluetooth/... and system/extra/... have some pieces
13+
with GPL/LGPL licensed code.
14+
15+
Assorted Issues:
16+
17+
- pppd depends on libutils for logging
18+
- pppd depends on libcrypt/libcrypto
19+
- init, linker, debuggerd, toolbox, usbd depend on libcutils
20+
- should probably rename bionic to libc

‎adb/Android.mk

+140
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,140 @@
1+
# Copyright 2005 The Android Open Source Project
2+
#
3+
# Android.mk for adb
4+
#
5+
6+
LOCAL_PATH:= $(call my-dir)
7+
8+
# adb host tool
9+
# =========================================================
10+
ifneq ($(TARGET_SIMULATOR),true) # not 64 bit clean (also unused with the sim)
11+
include $(CLEAR_VARS)
12+
13+
# Default to a virtual (sockets) usb interface
14+
USB_SRCS :=
15+
EXTRA_SRCS :=
16+
17+
ifeq ($(HOST_OS),linux)
18+
USB_SRCS := usb_linux.c
19+
EXTRA_SRCS := get_my_path_linux.c
20+
LOCAL_LDLIBS += -lrt -lncurses -lpthread
21+
endif
22+
23+
ifeq ($(HOST_OS),darwin)
24+
USB_SRCS := usb_osx.c
25+
EXTRA_SRCS := get_my_path_darwin.c
26+
LOCAL_LDLIBS += -lpthread -framework CoreFoundation -framework IOKit -framework Carbon
27+
endif
28+
29+
ifeq ($(HOST_OS),windows)
30+
USB_SRCS := usb_windows.c
31+
EXTRA_SRCS := get_my_path_windows.c
32+
EXTRA_STATIC_LIBS := AdbWinApi
33+
LOCAL_C_INCLUDES += /usr/include/w32api/ddk development/host/windows/usb/api/
34+
ifneq ($(strip $(USE_CYGWIN)),)
35+
LOCAL_LDLIBS += -lpthread
36+
else
37+
LOCAL_LDLIBS += -lws2_32
38+
USE_SYSDEPS_WIN32 := 1
39+
endif
40+
endif
41+
42+
LOCAL_SRC_FILES := \
43+
adb.c \
44+
console.c \
45+
transport.c \
46+
transport_local.c \
47+
transport_usb.c \
48+
commandline.c \
49+
adb_client.c \
50+
sockets.c \
51+
services.c \
52+
file_sync_client.c \
53+
$(EXTRA_SRCS) \
54+
$(USB_SRCS) \
55+
shlist.c \
56+
utils.c \
57+
58+
59+
ifneq ($(USE_SYSDEPS_WIN32),)
60+
LOCAL_SRC_FILES += sysdeps_win32.c
61+
endif
62+
63+
LOCAL_CFLAGS += -O2 -g -DADB_HOST=1 -Wall -Wno-unused-parameter
64+
LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE -DSH_HISTORY
65+
LOCAL_MODULE := adb
66+
67+
LOCAL_STATIC_LIBRARIES := libzipfile libunz $(EXTRA_STATIC_LIBS)
68+
ifeq ($(USE_SYSDEPS_WIN32),)
69+
LOCAL_STATIC_LIBRARIES += libcutils
70+
endif
71+
72+
include $(BUILD_HOST_EXECUTABLE)
73+
74+
$(call dist-for-goals,droid,$(LOCAL_BUILT_MODULE))
75+
76+
ifeq ($(HOST_OS),windows)
77+
$(LOCAL_INSTALLED_MODULE): $(HOST_OUT_EXECUTABLES)/AdbWinApi.dll
78+
endif
79+
80+
endif
81+
82+
# adbd device daemon
83+
# =========================================================
84+
85+
# build adbd in all non-simulator builds
86+
BUILD_ADBD := false
87+
ifneq ($(TARGET_SIMULATOR),true)
88+
BUILD_ADBD := true
89+
endif
90+
91+
# build adbd for the Linux simulator build
92+
# so we can use it to test the adb USB gadget driver on x86
93+
ifeq ($(HOST_OS),linux)
94+
BUILD_ADBD := true
95+
endif
96+
97+
98+
ifeq ($(BUILD_ADBD),true)
99+
include $(CLEAR_VARS)
100+
101+
LOCAL_SRC_FILES := \
102+
adb.c \
103+
transport.c \
104+
transport_local.c \
105+
transport_usb.c \
106+
sockets.c \
107+
services.c \
108+
file_sync_service.c \
109+
jdwp_service.c \
110+
framebuffer_service.c \
111+
remount_service.c \
112+
usb_linux_client.c \
113+
log_service.c \
114+
utils.c \
115+
116+
LOCAL_CFLAGS := -O2 -g -DADB_HOST=0 -Wall -Wno-unused-parameter
117+
LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE
118+
119+
# TODO: This should probably be board specific, whether or not the kernel has
120+
# the gadget driver; rather than relying on the architecture type.
121+
ifeq ($(TARGET_ARCH),arm)
122+
LOCAL_CFLAGS += -DANDROID_GADGET=1
123+
endif
124+
125+
LOCAL_MODULE := adbd
126+
127+
LOCAL_FORCE_STATIC_EXECUTABLE := true
128+
LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT_SBIN)
129+
LOCAL_UNSTRIPPED_PATH := $(TARGET_ROOT_OUT_SBIN_UNSTRIPPED)
130+
131+
ifeq ($(TARGET_SIMULATOR),true)
132+
LOCAL_STATIC_LIBRARIES := libcutils
133+
LOCAL_LDLIBS += -lpthread
134+
include $(BUILD_HOST_EXECUTABLE)
135+
else
136+
LOCAL_STATIC_LIBRARIES := libcutils libc
137+
include $(BUILD_EXECUTABLE)
138+
endif
139+
140+
endif

‎adb/OVERVIEW.TXT

+139
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
Implementation notes regarding ADB.
2+
3+
I. General Overview:
4+
5+
The Android Debug Bridge (ADB) is used to:
6+
7+
- keep track of all Android devices and emulators instances
8+
connected to or running on a given host developer machine
9+
10+
- implement various control commands (e.g. "adb shell", "adb pull", etc..)
11+
for the benefit of clients (command-line users, or helper programs like
12+
DDMS). These commands are what is called a 'service' in ADB.
13+
14+
As a whole, everything works through the following components:
15+
16+
1. The ADB server
17+
18+
This is a background process that runs on the host machine. Its purpose
19+
if to sense the USB ports to know when devices are attached/removed,
20+
as well as when emulator instances start/stop.
21+
22+
It thus maintains a list of "connected devices" and assigns a 'state'
23+
to each one of them: OFFLINE, BOOTLOADER, RECOVERY or ONLINE (more on
24+
this below).
25+
26+
The ADB server is really one giant multiplexing loop whose purpose is
27+
to orchestrate the exchange of data (packets, really) between clients,
28+
services and devices.
29+
30+
31+
2. The ADB daemon (adbd)
32+
33+
The 'adbd' program runs as a background process within an Android device
34+
or emulated system. Its purpose is to connect to the ADB server
35+
(through USB for devices, through TCP for emulators) and provide a
36+
few services for clients that run on the host.
37+
38+
The ADB server considers that a device is ONLINE when it has succesfully
39+
connected to the adbd program within it. Otherwise, the device is OFFLINE,
40+
meaning that the ADB server detected a new device/emulator, but could not
41+
connect to the adbd daemon.
42+
43+
the BOOTLOADER and RECOVERY states correspond to alternate states of
44+
devices when they are in the bootloader or recovery mode.
45+
46+
3. The ADB command-line client
47+
48+
The 'adb' command-line program is used to run adb commands from a shell
49+
or a script. It first tries to locate the ADB server on the host machine,
50+
and will start one automatically if none is found.
51+
52+
then, the client sends its service requests to the ADB server. It doesn't
53+
need to know.
54+
55+
Currently, a single 'adb' binary is used for both the server and client.
56+
this makes distribution and starting the server easier.
57+
58+
59+
4. Services
60+
61+
There are essentially two kinds of services that a client can talk to.
62+
63+
Host Services:
64+
these services run within the ADB Server and thus do not need to
65+
communicate with a device at all. A typical example is "adb devices"
66+
which is used to return the list of currently known devices and their
67+
state. They are a few couple other services though.
68+
69+
Local Services:
70+
these services either run within the adbd daemon, or are started by
71+
it on the device. The ADB server is used to multiplex streams
72+
between the client and the service running in adbd. In this case
73+
its role is to initiate the connection, then of being a pass-through
74+
for the data.
75+
76+
77+
II. Protocol details:
78+
79+
1. Client <-> Server protocol:
80+
81+
This details the protocol used between ADB clients and the ADB
82+
server itself. The ADB server listens on TCP:localhost:5037.
83+
84+
A client sends a request using the following format:
85+
86+
1. A 4-byte hexadecimal string giving the length of the payload
87+
2. Followed by the payload itself.
88+
89+
For example, to query the ADB server for its internal version number,
90+
the client will do the following:
91+
92+
1. Connect to tcp:localhost:5037
93+
2. Send the string "000Chost:version" to the corresponding socket
94+
95+
The 'host:' prefix is used to indicate that the request is addressed
96+
to the server itself (we will talk about other kinds of requests later).
97+
The content length is encoded in ASCII for easier debugging.
98+
99+
The server should answer a request with one of the following:
100+
101+
1. For success, the 4-byte "OKAY" string
102+
103+
2. For failure, the 4-byte "FAIL" string, followed by a
104+
4-byte hex length, followed by a string giving the reason
105+
for failure.
106+
107+
3. As a special exception, for 'host:version', a 4-byte
108+
hex string corresponding to the server's internal version number
109+
110+
Note that the connection is still alive after an OKAY, which allows the
111+
client to make other requests. But in certain cases, an OKAY will even
112+
change the state of the connection.
113+
114+
For example, the case of the 'host:transport:<serialnumber>' request,
115+
where '<serialnumber>' is used to identify a given device/emulator; after
116+
the "OKAY" answer, all further requests made by the client will go
117+
directly to the corresponding adbd daemon.
118+
119+
The file SERVICES.TXT lists all services currently implemented by ADB.
120+
121+
122+
2. Transports:
123+
124+
An ADB transport models a connection between the ADB server and one device
125+
or emulator. There are currently two kinds of transports:
126+
127+
- USB transports, for physical devices through USB
128+
129+
- Local transports, for emulators running on the host, connected to
130+
the server through TCP
131+
132+
In theory, it should be possible to write a local transport that proxies
133+
a connection between an ADB server and a device/emulator connected to/
134+
running on another machine. This hasn't been done yet though.
135+
136+
Each transport can carry one or more multiplexed streams between clients
137+
and the device/emulator they point to. The ADB server must handle
138+
unexpected transport disconnections (e.g. when a device is physically
139+
unplugged) properly.

0 commit comments

Comments
 (0)