2009-03-03 19:31:44 -08:00
|
|
|
LOCAL_PATH:= $(call my-dir)
|
|
|
|
|
include $(CLEAR_VARS)
|
|
|
|
|
|
|
|
|
|
LOCAL_CFLAGS += -DHAVE_CONFIG_H -DKHTML_NO_EXCEPTIONS -DGKWQ_NO_JAVA
|
|
|
|
|
LOCAL_CFLAGS += -DNO_SUPPORT_JS_BINDING -DQT_NO_WHEELEVENT -DKHTML_NO_XBL
|
|
|
|
|
LOCAL_CFLAGS += -U__APPLE__
|
|
|
|
|
|
|
|
|
|
ifeq ($(TARGET_ARCH), arm)
|
|
|
|
|
LOCAL_CFLAGS += -DPACKED="__attribute__ ((packed))"
|
|
|
|
|
else
|
|
|
|
|
LOCAL_CFLAGS += -DPACKED=""
|
|
|
|
|
endif
|
|
|
|
|
|
2009-06-19 13:31:12 -07:00
|
|
|
ifeq ($(WITH_JIT),true)
|
|
|
|
|
LOCAL_CFLAGS += -DWITH_JIT
|
|
|
|
|
endif
|
|
|
|
|
|
2009-03-03 19:31:44 -08:00
|
|
|
ifneq ($(USE_CUSTOM_RUNTIME_HEAP_MAX),)
|
|
|
|
|
LOCAL_CFLAGS += -DCUSTOM_RUNTIME_HEAP_MAX=$(USE_CUSTOM_RUNTIME_HEAP_MAX)
|
|
|
|
|
endif
|
|
|
|
|
|
2010-08-08 00:14:31 -07:00
|
|
|
ifeq ($(USE_OPENGL_RENDERER),true)
|
|
|
|
|
LOCAL_CFLAGS += -DUSE_OPENGL_RENDERER
|
|
|
|
|
endif
|
|
|
|
|
|
2009-04-10 14:24:30 -07:00
|
|
|
LOCAL_CFLAGS += -DGL_GLEXT_PROTOTYPES -DEGL_EGLEXT_PROTOTYPES
|
|
|
|
|
|
2009-03-03 19:31:44 -08:00
|
|
|
LOCAL_SRC_FILES:= \
|
|
|
|
|
ActivityManager.cpp \
|
|
|
|
|
AndroidRuntime.cpp \
|
2009-06-24 23:12:06 -07:00
|
|
|
Time.cpp \
|
2011-07-12 14:14:01 -07:00
|
|
|
com_android_internal_content_NativeLibraryHelper.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
com_google_android_gles_jni_EGLImpl.cpp \
|
|
|
|
|
com_google_android_gles_jni_GLImpl.cpp.arm \
|
2010-05-04 11:40:40 -07:00
|
|
|
android_app_NativeActivity.cpp \
|
Manually merge 129, 174, and 233 from donut
This adds a static OpenGL ES API.
Here are the three commit messages for the original changes:
Clean up trivial Eclipse warnings and fix whitespace.
Added @Override to overridden methods.
Removed unused imports.
Converted tabs to spaces.
Removed \r characters from end-of-lines.
Add .gitignore file to ignore the .class files that are
generated when the "gen" script is run.
This is the 2nd commit message:
Improve glgen
+ gen script is really a bash script rather than a sh script,
so declare that to be true. (For example, it uses pushd,
which is a part of bash, but not a part of sh. Not sure
how this worked until now. Possibly gen was only run in
environments where /bin/sh was really bash.
+ Check the results of the java compile of the code generator,
and abort the script if the compile fails.
+ Turn on the bash shell option that guards against using
uninitialized variables in the script.
+ Remove the generated class files.
Refactor JniCodeEmitter into two classes: a general-purpose
JniCodeEmitter and a specific Jsr239CodeEmitter. The hope is
to use JniCodeEmitter as a base for emitting static OpenGL ES
bindings.
This is the 3rd commit message:
Add an Android-specific static OpenGL ES 1.1 Java API.
This change adds four new public classes that expose a static OpenGL ES 1.1 API:
android.opengl.GLES10
android.opengl.GLES10Ext
android.opengl.GLES11
android.opengl.GLES11Ext
Benefits:
+ The static API is slightly faster (1% to 4%) than the existing Interface based JSR239 API.
+ The static API is similar to the C API, which should make it easier to import C-based
example code.
+ The static API provides a clear path for adding new OpenGL ES 1.1 extensions
and OpenGL ES 2.0 APIs, neither of which currently have a JSR standard.
Example:
import static android.opengl.GLES10.*;
...
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Note that it is possible to mix-and-match calls to both the static and JSR239 APIs.
This works because neither API maintains state. They both call through to the same underlying
C OpenGL ES APIs.
Implementation details:
This change enhances the "glgen" "gen" script to generate both the original JSR239 and
new static OpenGL ES APIs. The contents of the generated JSR239 classes remained the same as before,
so there is no need to check in new versions of the generated JSR239 classes.
As part of this work the gen script was updated to be somewhat more robust, and to
work with git instead of perforce. The script prints out commands to git add the generated files,
but leaves it up to the script runner to actually execute those commands.
2009-04-13 16:22:25 -07:00
|
|
|
android_opengl_GLES10.cpp \
|
|
|
|
|
android_opengl_GLES10Ext.cpp \
|
|
|
|
|
android_opengl_GLES11.cpp \
|
|
|
|
|
android_opengl_GLES11Ext.cpp \
|
2009-11-19 16:34:55 +08:00
|
|
|
android_opengl_GLES20.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_database_CursorWindow.cpp \
|
Rewrite SQLite database wrappers.
The main theme of this change is encapsulation. This change
preserves all existing functionality but the implementation
is now much cleaner.
Instead of a "database lock", access to the database is treated
as a resource acquisition problem. If a thread's owns a database
connection, then it can access the database; otherwise, it must
acquire a database connection first, and potentially wait for other
threads to give up theirs. The SQLiteConnectionPool encapsulates
the details of how connections are created, configured, acquired,
released and disposed.
One new feature is that SQLiteConnectionPool can make scheduling
decisions about which thread should next acquire a database
connection when there is contention among threads. The factors
considered include wait queue ordering (fairness among peers),
whether the connection is needed for an interactive operation
(unfairness on behalf of the UI), and whether the primary connection
is needed or if any old connection will do. Thus one goal of the
new SQLiteConnectionPool is to improve the utilization of
database connections.
To emulate some quirks of the old "database lock," we introduce
the concept of the primary database connection. The primary
database connection is the one that is typically used to perform
write operations to the database. When a thread holds the primary
database connection, it effectively prevents other threads from
modifying the database (although they can still read). What's
more, those threads will block when they try to acquire the primary
connection, which provides the same kind of mutual exclusion
features that the old "database lock" had. (In truth, we
probably don't need to be requiring use of the primary database
connection in as many places as we do now, but we can seek to refine
that behavior in future patches.)
Another significant change is that native sqlite3_stmt objects
(prepared statements) are fully encapsulated by the SQLiteConnection
object that owns them. This ensures that the connection can
finalize (destroy) all extant statements that belong to a database
connection when the connection is closed. (In the original code,
this was very complicated because the sqlite3_stmt objects were
managed by SQLiteCompiledSql objects which had different lifetime
from the original SQLiteDatabase that created them. Worse, the
SQLiteCompiledSql finalizer method couldn't actually destroy the
sqlite3_stmt objects because it ran on the finalizer thread and
therefore could not guarantee that it could acquire the database
lock in order to do the work. This resulted in some rather
tortured logic involving a list of pending finalizable statements
and a high change of deadlocks or leaks.)
Because sqlite3_stmt objects never escape the confines of the
SQLiteConnection that owns them, we can also greatly simplify
the design of the SQLiteProgram, SQLiteQuery and SQLiteStatement
objects. They no longer have to wrangle a native sqlite3_stmt
object pointer and manage its lifecycle. So now all they do
is hold bind arguments and provide a fancy API.
All of the JNI glue related to managing database connections
and performing transactions is now bound to SQLiteConnection
(rather than being scattered everywhere). This makes sense because
SQLiteConnection owns the native sqlite3 object, so it is the
only class in the system that can interact with the native
SQLite database directly. Encapsulation for the win.
One particularly tricky part of this change is managing the
ownership of SQLiteConnection objects. At any given time,
a SQLiteConnection is either owned by a SQLiteConnectionPool
or by a SQLiteSession. SQLiteConnections should never be leaked,
but we handle that case too (and yell about it with CloseGuard).
A SQLiteSession object is responsible for acquiring and releasing
a SQLiteConnection object on behalf of a single thread as needed.
For example, the session acquires a connection when a transaction
begins and releases it when finished. If the session cannot
acquire a connection immediately, then the requested operation
blocks until a connection becomes available.
SQLiteSessions are thread-local. A SQLiteDatabase assigns a
distinct session to each thread that performs database operations.
This is very very important. First, it prevents two threads
from trying to use the same SQLiteConnection at the same time
(because two threads can't share the same session).
Second, it prevents a single thread from trying to acquire two
SQLiteConnections simultaneously from the same database (because
a single thread can't have two sessions for the same database which,
in addition to being greedy, could result in a deadlock).
There is strict layering between the various database objects,
objects at lower layers are not aware of objects at higher layers.
Moreover, objects at higher layers generally own objects at lower
layers and are responsible for ensuring they are properly disposed
when no longer needed (good for the environment).
API layer: SQLiteDatabase, SQLiteProgram, SQLiteQuery, SQLiteStatement.
Session layer: SQLiteSession.
Connection layer: SQLiteConnectionPool, SQLiteConnection.
Native layer: JNI glue.
By avoiding cyclic dependencies between layers, we make the
architecture much more intelligible, maintainable and robust.
Finally, this change adds a great deal of new debugging information.
It is now possible to view a list of the most recent database
operations including how long they took to run using
"adb shell dumpsys dbinfo". (Because most of the interesting
work happens in SQLiteConnection, it is easy to add debugging
instrumentation to track all database operations in one place.)
Change-Id: Iffb4ce72d8bcf20b4e087d911da6aa84d2f15297
2011-10-31 17:48:13 -07:00
|
|
|
android_database_SQLiteCommon.cpp \
|
|
|
|
|
android_database_SQLiteConnection.cpp \
|
|
|
|
|
android_database_SQLiteGlobal.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_database_SQLiteDebug.cpp \
|
2009-03-09 11:52:12 -07:00
|
|
|
android_emoji_EmojiFactory.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_view_Display.cpp \
|
2011-12-02 02:25:22 -08:00
|
|
|
android_view_DisplayEventReceiver.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_view_Surface.cpp \
|
2011-05-02 17:24:22 -07:00
|
|
|
android_view_TextureView.cpp \
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
android_view_InputChannel.cpp \
|
2011-12-01 14:01:49 -08:00
|
|
|
android_view_InputEventReceiver.cpp \
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
android_view_KeyEvent.cpp \
|
2010-12-06 17:13:33 -08:00
|
|
|
android_view_KeyCharacterMap.cpp \
|
2011-11-10 14:20:10 -08:00
|
|
|
android_view_HardwareRenderer.cpp \
|
2012-02-21 13:43:44 -08:00
|
|
|
android_view_GLES20DisplayList.cpp \
|
2010-06-16 18:44:05 -07:00
|
|
|
android_view_GLES20Canvas.cpp \
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
android_view_MotionEvent.cpp \
|
2011-04-12 22:39:53 -07:00
|
|
|
android_view_PointerIcon.cpp \
|
2011-03-14 19:39:54 -07:00
|
|
|
android_view_VelocityTracker.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_text_AndroidCharacter.cpp \
|
2010-02-24 14:33:15 -08:00
|
|
|
android_text_AndroidBidi.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_os_Debug.cpp \
|
|
|
|
|
android_os_FileUtils.cpp \
|
|
|
|
|
android_os_MemoryFile.cpp \
|
2010-05-06 12:07:10 -07:00
|
|
|
android_os_MessageQueue.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_os_ParcelFileDescriptor.cpp \
|
2012-03-06 18:26:19 -08:00
|
|
|
android_os_Parcel.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_os_Power.cpp \
|
|
|
|
|
android_os_StatFs.cpp \
|
|
|
|
|
android_os_SystemClock.cpp \
|
|
|
|
|
android_os_SystemProperties.cpp \
|
2012-03-09 14:41:15 -08:00
|
|
|
android_os_Trace.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_os_UEventObserver.cpp \
|
|
|
|
|
android_net_LocalSocketImpl.cpp \
|
|
|
|
|
android_net_NetUtils.cpp \
|
2010-04-07 17:30:50 -07:00
|
|
|
android_net_TrafficStats.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_net_wifi_Wifi.cpp \
|
|
|
|
|
android_nio_utils.cpp \
|
|
|
|
|
android_text_format_Time.cpp \
|
|
|
|
|
android_util_AssetManager.cpp \
|
|
|
|
|
android_util_Binder.cpp \
|
|
|
|
|
android_util_EventLog.cpp \
|
|
|
|
|
android_util_Log.cpp \
|
|
|
|
|
android_util_FloatMath.cpp \
|
|
|
|
|
android_util_Process.cpp \
|
|
|
|
|
android_util_StringBlock.cpp \
|
|
|
|
|
android_util_XmlBlock.cpp \
|
2010-07-19 16:59:51 +08:00
|
|
|
android/graphics/AutoDecodeCancel.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android/graphics/Bitmap.cpp \
|
|
|
|
|
android/graphics/BitmapFactory.cpp \
|
|
|
|
|
android/graphics/Camera.cpp \
|
|
|
|
|
android/graphics/Canvas.cpp \
|
|
|
|
|
android/graphics/ColorFilter.cpp \
|
|
|
|
|
android/graphics/DrawFilter.cpp \
|
|
|
|
|
android/graphics/CreateJavaOutputStreamAdaptor.cpp \
|
|
|
|
|
android/graphics/Graphics.cpp \
|
2011-03-08 12:02:59 -08:00
|
|
|
android/graphics/HarfbuzzSkia.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android/graphics/Interpolator.cpp \
|
|
|
|
|
android/graphics/LayerRasterizer.cpp \
|
|
|
|
|
android/graphics/MaskFilter.cpp \
|
|
|
|
|
android/graphics/Matrix.cpp \
|
|
|
|
|
android/graphics/Movie.cpp \
|
|
|
|
|
android/graphics/NinePatch.cpp \
|
|
|
|
|
android/graphics/NinePatchImpl.cpp \
|
2011-03-02 16:56:54 -05:00
|
|
|
android/graphics/NinePatchPeeker.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android/graphics/Paint.cpp \
|
|
|
|
|
android/graphics/Path.cpp \
|
|
|
|
|
android/graphics/PathMeasure.cpp \
|
|
|
|
|
android/graphics/PathEffect.cpp \
|
|
|
|
|
android_graphics_PixelFormat.cpp \
|
|
|
|
|
android/graphics/Picture.cpp \
|
|
|
|
|
android/graphics/PorterDuff.cpp \
|
2010-09-07 17:32:18 +08:00
|
|
|
android/graphics/BitmapRegionDecoder.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android/graphics/Rasterizer.cpp \
|
|
|
|
|
android/graphics/Region.cpp \
|
|
|
|
|
android/graphics/Shader.cpp \
|
2010-12-20 12:09:37 -08:00
|
|
|
android/graphics/SurfaceTexture.cpp \
|
2010-07-01 16:20:43 -07:00
|
|
|
android/graphics/TextLayout.cpp \
|
2011-02-24 19:56:18 -08:00
|
|
|
android/graphics/TextLayoutCache.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android/graphics/Typeface.cpp \
|
2010-09-07 17:32:18 +08:00
|
|
|
android/graphics/Utils.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android/graphics/Xfermode.cpp \
|
2009-11-30 17:52:05 +08:00
|
|
|
android/graphics/YuvToJpegEncoder.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_media_AudioRecord.cpp \
|
|
|
|
|
android_media_AudioSystem.cpp \
|
|
|
|
|
android_media_AudioTrack.cpp \
|
|
|
|
|
android_media_JetPlayer.cpp \
|
|
|
|
|
android_media_ToneGenerator.cpp \
|
|
|
|
|
android_hardware_Camera.cpp \
|
|
|
|
|
android_hardware_SensorManager.cpp \
|
2011-08-29 20:11:07 -04:00
|
|
|
android_hardware_SerialPort.cpp \
|
2010-12-30 13:39:37 -05:00
|
|
|
android_hardware_UsbDevice.cpp \
|
2011-03-11 08:18:08 -05:00
|
|
|
android_hardware_UsbDeviceConnection.cpp \
|
2010-12-30 13:39:37 -05:00
|
|
|
android_hardware_UsbRequest.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_debug_JNITest.cpp \
|
|
|
|
|
android_util_FileObserver.cpp \
|
|
|
|
|
android/opengl/poly_clip.cpp.arm \
|
|
|
|
|
android/opengl/util.cpp.arm \
|
|
|
|
|
android_bluetooth_HeadsetBase.cpp \
|
|
|
|
|
android_bluetooth_common.cpp \
|
|
|
|
|
android_bluetooth_BluetoothAudioGateway.cpp \
|
2009-05-26 19:13:43 -07:00
|
|
|
android_bluetooth_BluetoothSocket.cpp \
|
2011-07-16 19:14:18 -07:00
|
|
|
android_bluetooth_c.c \
|
2009-08-14 18:33:38 -07:00
|
|
|
android_server_BluetoothService.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_server_BluetoothEventLoop.cpp \
|
|
|
|
|
android_server_BluetoothA2dpService.cpp \
|
2011-09-02 15:36:33 -07:00
|
|
|
android_server_NetworkManagementSocketTagger.cpp \
|
2010-06-04 14:55:02 -07:00
|
|
|
android_server_Watchdog.cpp \
|
2009-03-03 19:31:44 -08:00
|
|
|
android_ddm_DdmHandleNativeHeap.cpp \
|
|
|
|
|
com_android_internal_os_ZygoteInit.cpp \
|
2009-06-12 11:06:24 -07:00
|
|
|
android_backup_BackupDataInput.cpp \
|
2009-05-19 13:41:21 -07:00
|
|
|
android_backup_BackupDataOutput.cpp \
|
2009-06-25 18:29:18 -04:00
|
|
|
android_backup_FileBackupHelperBase.cpp \
|
2010-07-01 08:10:18 -07:00
|
|
|
android_backup_BackupHelperDispatcher.cpp \
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 14:43:32 -07:00
|
|
|
android_app_backup_FullBackup.cpp \
|
2010-08-04 11:12:40 -07:00
|
|
|
android_content_res_ObbScanner.cpp \
|
2010-11-03 19:41:18 -07:00
|
|
|
android_content_res_Configuration.cpp \
|
|
|
|
|
android_animation_PropertyValuesHolder.cpp
|
2009-03-03 19:31:44 -08:00
|
|
|
|
|
|
|
|
LOCAL_C_INCLUDES += \
|
|
|
|
|
$(JNI_H_INCLUDE) \
|
|
|
|
|
$(LOCAL_PATH)/android/graphics \
|
2010-06-16 18:44:05 -07:00
|
|
|
$(LOCAL_PATH)/../../libs/hwui \
|
2012-03-05 16:16:58 -08:00
|
|
|
$(LOCAL_PATH)/../../../native/opengl/libs \
|
2009-03-03 19:31:44 -08:00
|
|
|
$(call include-path-for, bluedroid) \
|
|
|
|
|
$(call include-path-for, libhardware)/hardware \
|
|
|
|
|
$(call include-path-for, libhardware_legacy)/hardware_legacy \
|
|
|
|
|
external/skia/include/core \
|
|
|
|
|
external/skia/include/effects \
|
|
|
|
|
external/skia/include/images \
|
Add (hidden for now) purgeable bitmaps
BitmapFactory::Options now let you specify if the resulting bitmap can be
"purgeable". If so, then its decoded pixels may be purged when not actively
being drawn, freeing up that RAM. When such a bitmap is drawn, it will
automatically be re-decoded on demand. This is done by having the bitmap
keep a reference/copy of the encoded data.
Where it is a reference or a copy is controlled by the "shareable" flag in
Options. If this is true, the implementation *may* just reference the encode
data (e.g. a file descriptor) rathern than making a complete copy of it.
Currently, purgeable is not supported for generic inputstreams, but is
enabled for byte-array, file-descriptor, and assets, though for impl
reasons only file-descripts are currently enabled for "shareable", but that
may change in the future.
2009-04-24 11:09:12 -04:00
|
|
|
external/skia/src/ports \
|
2009-03-03 19:31:44 -08:00
|
|
|
external/skia/include/utils \
|
|
|
|
|
external/sqlite/dist \
|
|
|
|
|
external/sqlite/android \
|
|
|
|
|
external/expat/lib \
|
|
|
|
|
external/openssl/include \
|
|
|
|
|
external/tremor/Tremor \
|
|
|
|
|
external/icu4c/i18n \
|
|
|
|
|
external/icu4c/common \
|
2009-11-30 17:52:05 +08:00
|
|
|
external/jpeg \
|
2011-08-09 14:37:22 -07:00
|
|
|
external/harfbuzz/contrib \
|
2011-03-08 12:02:59 -08:00
|
|
|
external/harfbuzz/src \
|
2011-07-12 14:14:01 -07:00
|
|
|
external/zlib \
|
2011-04-08 14:10:28 -07:00
|
|
|
frameworks/opt/emoji \
|
|
|
|
|
libcore/include
|
2009-03-03 19:31:44 -08:00
|
|
|
|
|
|
|
|
LOCAL_SHARED_LIBRARIES := \
|
2012-02-20 16:58:20 -08:00
|
|
|
libandroidfw \
|
2009-03-03 19:31:44 -08:00
|
|
|
libexpat \
|
|
|
|
|
libnativehelper \
|
|
|
|
|
libcutils \
|
|
|
|
|
libutils \
|
2009-05-18 15:08:03 -07:00
|
|
|
libbinder \
|
2009-03-03 19:31:44 -08:00
|
|
|
libnetutils \
|
|
|
|
|
libui \
|
2010-07-14 23:41:37 -07:00
|
|
|
libgui \
|
2010-02-09 17:46:37 -08:00
|
|
|
libcamera_client \
|
2009-07-10 15:33:21 -04:00
|
|
|
libskia \
|
2009-03-03 19:31:44 -08:00
|
|
|
libsqlite \
|
|
|
|
|
libdvm \
|
|
|
|
|
libEGL \
|
|
|
|
|
libGLESv1_CM \
|
2009-11-19 16:34:55 +08:00
|
|
|
libGLESv2 \
|
2009-12-28 19:31:43 +08:00
|
|
|
libETC1 \
|
2009-03-03 19:31:44 -08:00
|
|
|
libhardware \
|
|
|
|
|
libhardware_legacy \
|
|
|
|
|
libsonivox \
|
|
|
|
|
libcrypto \
|
|
|
|
|
libssl \
|
|
|
|
|
libicuuc \
|
|
|
|
|
libicui18n \
|
|
|
|
|
libmedia \
|
2009-11-30 17:52:05 +08:00
|
|
|
libwpa_client \
|
2010-10-13 17:25:24 -07:00
|
|
|
libjpeg \
|
2010-12-30 13:39:37 -05:00
|
|
|
libusbhost \
|
2011-03-08 12:02:59 -08:00
|
|
|
libharfbuzz \
|
2011-07-12 14:14:01 -07:00
|
|
|
libz \
|
2010-05-25 19:08:48 -04:00
|
|
|
|
2010-08-08 00:14:31 -07:00
|
|
|
ifeq ($(USE_OPENGL_RENDERER),true)
|
|
|
|
|
LOCAL_SHARED_LIBRARIES += libhwui
|
|
|
|
|
endif
|
|
|
|
|
|
2009-03-03 19:31:44 -08:00
|
|
|
ifeq ($(BOARD_HAVE_BLUETOOTH),true)
|
|
|
|
|
LOCAL_C_INCLUDES += \
|
|
|
|
|
external/dbus \
|
2009-03-09 11:52:12 -07:00
|
|
|
system/bluetooth/bluez-clean-headers
|
2009-03-03 19:31:44 -08:00
|
|
|
LOCAL_CFLAGS += -DHAVE_BLUETOOTH
|
|
|
|
|
LOCAL_SHARED_LIBRARIES += libbluedroid libdbus
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
LOCAL_SHARED_LIBRARIES += \
|
|
|
|
|
libdl
|
2011-07-11 22:12:16 -07:00
|
|
|
# we need to access the private Bionic header
|
|
|
|
|
# <bionic_tls.h> in com_google_android_gles_jni_GLImpl.cpp
|
|
|
|
|
LOCAL_CFLAGS += -I$(LOCAL_PATH)/../../../../bionic/libc/private
|
2009-03-03 19:31:44 -08:00
|
|
|
|
|
|
|
|
LOCAL_LDLIBS += -lpthread -ldl
|
|
|
|
|
|
|
|
|
|
ifeq ($(WITH_MALLOC_LEAK_CHECK),true)
|
|
|
|
|
LOCAL_CFLAGS += -DMALLOC_LEAK_CHECK
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
LOCAL_MODULE:= libandroid_runtime
|
|
|
|
|
|
|
|
|
|
include $(BUILD_SHARED_LIBRARY)
|
|
|
|
|
|
|
|
|
|
include $(call all-makefiles-under,$(LOCAL_PATH))
|
