Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
386,651 Commits 3 Branches 0 Tags
3b3a2ade94de8a9edf34a03c96e731affd2dc1da
Commit Graph

14 Commits

Author SHA1 Message Date
Annie Meng
95264455a1 Fix accessibility_display_magnification_scale restore 
accessibility_display_magnification_scale has a default value set, so
the current check to see if it was already configured during restore
always falsely returned true. Now, we compare it to the default value
and only say it's configured if different from the default.

Bug: 72737403
Test: 1) Manual d2d restore:
a) Set non-default value on source -> correctly restores on target
b) Default value on source -> correctly has default value on target
c) Set non-default value in SUW during restore -> correctly does not
override with value from source
2) Unit: atest SettingsHelperRestoreTest

Change-Id: Ie0670aac7b4ce806ac7b8baef4eb15a7c40d5919
 2018-04-26 14:12:25 +01:00
Anton Hansson
ab6ec61251 frameworks/base: Set LOCAL_SDK_VERSION where possible. 
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.

Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.

Test: make relevant packages
Bug: 73535841
Change-Id: I4233b9091d9066c4fa69f3d24aaf367ea500f760
 2018-02-28 15:13:23 +00:00
Paul Duffin
b866307f99 Stop statically including legacy-android-test 
Statically including legacy-android-test leads to duplicate classes
which causes build time problems (with Proguard) and runtime problems on
older SDK versions. This change:
* Stops statically including legacy-android-test.
* Adds compile time dependencies on andoid.test.base, android.test.mock
  and android.test.runner where necessary.
* Adds <uses-library android:name="android.test.runner"/> to any
  affected package to ensure that the classes that were included by
  legacy-android-test are still available at runtime. That also adds a
  dependency on android.test.base and android.test.mock.

The following change descriptions were generated automatically and so
may be a little repetitive. They are provided to give the reviewer
enough information to check the comments match what has actually been
changed and check the reasoning behind the changes.

* apct-tests/perftests/core/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in CorePerfTests results
    in duplicate classes which leads to build time and compile time
    issues.

    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    CorePerfTests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

* core/tests/ConnectivityManagerTest/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    ConnectivityManagerTest's source depends on its classes and because
    of these changes they are no longer present on the compilation
    path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in ConnectivityManagerTest
    results in duplicate classes which leads to build time and compile
    time issues.

* core/tests/bandwidthtests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    BandwidthTests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in BandwidthTests results
    in duplicate classes which leads to build time and compile time
    issues.

* core/tests/bluetoothtests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    BluetoothTests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in BluetoothTests results
    in duplicate classes which leads to build time and compile time
    issues.

* core/tests/hosttests/test-apps/DownloadManagerTestApp/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in DownloadManagerTestApp
    results in duplicate classes which leads to build time and compile
    time issues.

    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    DownloadManagerTestApp's source depends on its classes and because
    of these changes they are no longer present on the compilation
    path.

* core/tests/hosttests/test-apps/ExternalSharedPerms/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    ExternalSharedPermsTestApp results in duplicate classes which leads
    to build time and compile time issues.

* core/tests/hosttests/test-apps/ExternalSharedPermsBT/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    ExternalSharedPermsBTTestApp results in duplicate classes which
    leads to build time and compile time issues.

* core/tests/hosttests/test-apps/ExternalSharedPermsDiffKey/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    ExternalSharedPermsDiffKeyTestApp results in duplicate classes
    which leads to build time and compile time issues.

* core/tests/hosttests/test-apps/ExternalSharedPermsFL/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    ExternalSharedPermsFLTestApp results in duplicate classes which
    leads to build time and compile time issues.

* core/tests/notificationtests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    NotificationStressTests's source depends on its classes and because
    of these changes they are no longer present on the compilation
    path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in NotificationStressTests
    results in duplicate classes which leads to build time and compile
    time issues.

* keystore/tests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in KeystoreTests results
    in duplicate classes which leads to build time and compile time
    issues.

* media/mca/tests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    CameraEffectsTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in CameraEffectsTests
    results in duplicate classes which leads to build time and compile
    time issues.

* media/tests/MediaFrameworkTest/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    mediaframeworktest's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in mediaframeworktest
    results in duplicate classes which leads to build time and compile
    time issues.

* nfc-extras/tests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in NfcExtrasTests results
    in duplicate classes which leads to build time and compile time
    issues.

* packages/CarrierDefaultApp/tests/unit/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    CarrierDefaultAppUnitTests's source depends on its classes and
    because of these changes they are no longer present on the
    compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    CarrierDefaultAppUnitTests results in duplicate classes which leads
    to build time and compile time issues.

* packages/ExtServices/tests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    ExtServicesUnitTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in ExtServicesUnitTests
    results in duplicate classes which leads to build time and compile
    time issues.

* packages/MtpDocumentsProvider/tests/Android.mk
    Added 'android.test.base' and 'android.test.mock' to
    LOCAL_JAVA_LIBRARIES because MtpDocumentsProviderTests's source
    depends on their classes and because of these changes they are no
    longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    MtpDocumentsProviderTests results in duplicate classes which leads
    to build time and compile time issues.

* packages/SettingsLib/tests/integ/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    SettingsLibTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in SettingsLibTests
    results in duplicate classes which leads to build time and compile
    time issues.

* packages/SettingsProvider/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in SettingsProvider
    results in duplicate classes which leads to build time and compile
    time issues.

* packages/SettingsProvider/AndroidManifest.xml
    Add uses-library for android.test.runner because otherwise this
    change would change the set of files available to SettingsProvider
    at runtime.

* packages/Shell/tests/Android.mk
    Added 'android.test.base' and 'android.test.mock' to
    LOCAL_JAVA_LIBRARIES because ShellTests's source depends on their
    classes and because of these changes they are no longer present on
    the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in ShellTests results in
    duplicate classes which leads to build time and compile time
    issues.

* packages/SystemUI/shared/tests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in SystemUISharedLibTests
    results in duplicate classes which leads to build time and compile
    time issues.

* packages/SystemUI/tests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in SystemUITests results
    in duplicate classes which leads to build time and compile time
    issues.

    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    SystemUITests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

* packages/WAPPushManager/tests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    WAPPushManagerTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in WAPPushManagerTests
    results in duplicate classes which leads to build time and compile
    time issues.

* sax/tests/saxtests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    FrameworksSaxTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in FrameworksSaxTests
    results in duplicate classes which leads to build time and compile
    time issues.

* tests/BrowserPowerTest/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    BrowserPowerTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in BrowserPowerTests
    results in duplicate classes which leads to build time and compile
    time issues.

* tests/CanvasCompare/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    CanvasCompare's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in CanvasCompare results
    in duplicate classes which leads to build time and compile time
    issues.

* tests/CoreTests/android/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    CoreTests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in CoreTests results in
    duplicate classes which leads to build time and compile time
    issues.

* tests/DataIdleTest/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    DataIdleTest's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in DataIdleTest results in
    duplicate classes which leads to build time and compile time
    issues.

* tests/FrameworkPerf/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    FrameworkPerf's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in FrameworkPerf results
    in duplicate classes which leads to build time and compile time
    issues.

* tests/HierarchyViewerTest/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    HierarchyViewerTest's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in HierarchyViewerTest
    results in duplicate classes which leads to build time and compile
    time issues.

* tests/ImfTest/tests/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    ImfTestTests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in ImfTestTests results in
    duplicate classes which leads to build time and compile time
    issues.

* tests/Internal/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in InternalTests results
    in duplicate classes which leads to build time and compile time
    issues.

* tests/MemoryUsage/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    MemoryUsage's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in MemoryUsage results in
    duplicate classes which leads to build time and compile time
    issues.

* tests/NetworkSecurityConfigTest/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    NetworkSecurityConfigTests's source depends on its classes and
    because of these changes they are no longer present on the
    compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    NetworkSecurityConfigTests results in duplicate classes which leads
    to build time and compile time issues.

* tests/SoundTriggerTests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in SoundTriggerTests
    results in duplicate classes which leads to build time and compile
    time issues.

    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    SoundTriggerTests's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

* tests/SurfaceComposition/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in SurfaceComposition
    results in duplicate classes which leads to build time and compile
    time issues.

    Added 'android.test.runner.stubs' to LOCAL_JAVA_LIBRARIES because
    SurfaceComposition's source depends on its classes and because of
    these changes they are no longer present on the compilation path.

* tests/TtsTests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in TtsTests results in
    duplicate classes which leads to build time and compile time
    issues.

    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    TtsTests's source depends on its classes and because of these
    changes they are no longer present on the compilation path.

* tests/WindowAnimationJank/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in WindowAnimationJank
    results in duplicate classes which leads to build time and compile
    time issues.

* tests/permission/Android.mk
    Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
    FrameworkPermissionTests's source depends on its classes and
    because of these changes they are no longer present on the
    compilation path.

    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in
    FrameworkPermissionTests results in duplicate classes which leads
    to build time and compile time issues.

* tests/testables/tests/Android.mk
    Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
    because statically including the classes in TestablesTests results
    in duplicate classes which leads to build time and compile time
    issues.

    Added 'android.test.base' and 'android.test.mock' to
    LOCAL_JAVA_LIBRARIES because TestablesTests's source depends on
    their classes and because of these changes they are no longer
    present on the compilation path.

Bug: 30188076
Test: make checkbuild
Change-Id: Iacfc939c97415314366ed61c5f3b7aa1a40f0ec9
 2017-12-08 00:07:17 +00:00
Paul Duffin
8aeb59ebcd Prepare for removal of legacy-test from default targets 
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.

Bug: 30188076
Test: make checkbuild
Change-Id: I13e88297731253420e4e5f5291d503f13a39a156
 2017-01-18 16:39:34 +00:00
Svetoslav Ganov
e080da9ee0 Settings recovery support 
This change allows the system to perform iterative reset
of changes to settings in order to recover from bad a
state such as a reboot loop.

To enable this we add the notion of a default value. The
default can be set by any package but if the package that
set it is a part of the system, i.e. trusted, then other
packages that are not a part of the system, i.e. untrusted,
cannot change the default. The settings setter APIs that
do not take a default effectively clear the default. Putting
a setting from a system component always makes it the
default and if the package in not trusted then value is
not made the default. The rationale is that the system is
tested and its values are safe but third-party components
are not trusted and their values are not safe.

The reset modes from the least intrusive are: untrusted
defaults - reset only settings set by untrusted components
to their defaults or clear them otherwise; untrusted clear
- clear settings set by untrusted components (or snap to
default if provided by the system); trusted defaults - reset
all settings to defaults set by the system or clear them
otherwise.

Also a package can reset to defaults changes it made to
the global and secure settings. It is also possible to
associate a setting with an optional token which can then
be used to reset settings set by this package and
associated with the token allowing parallel experiments
over disjoint settings subsets.

The default values are also useful for experiment (or
more precisely iterative tuning of devices' behavior in
production) as the stable configuration can be set to
the "graduated" safe defaults and set the values to the
experimental ones to measure impact.

Test: tests pass

Change-Id: I838955ea3bb28337f416ee244dff2fb1199b6943
 2016-12-22 01:14:28 +00:00
Svetoslav
683914bfb1 Rewrite of the settings provider. 
This change modifies how global, secure, and system settings are
managed. In particular, we are moving away from the database to
an in-memory model where the settings are persisted asynchronously
to XML.

This simplifies evolution and improves performance, for example,
changing a setting is down from around 400 ms to 10 ms as we do not
hit the disk. The trade off is that we may lose data if the system
dies before persisting the change.

In practice this is not a problem because 1) this is very rare;
2) apps changing a setting use the setting itself to know if it
changed, so next time the app runs (after a reboot that lost data)
the app will be oblivious that data was lost.

When persisting the settings we delay the write a bit to batch
multiple changes. If a change occurs we reschedule the write
but when a maximal delay occurs after the first non-persisted
change we write to disk no matter what. This prevents a malicious
app poking the settings all the time to prevent them being persisted.

The settings are persisted in separate XML files for each type of
setting per user. Specifically, they are in the user's system
directory and the files are named: settings_type_of_settings.xml.

Data migration is performed after the data base is upgraded to its
last version after which the global, system, and secure tables are
dropped.

The global, secure, and system settings now have the same version
and are upgraded as a whole per user to allow migration of settings
between these them. The upgrade steps should be added to the
SettingsProvider.UpgradeController and not in the DatabaseHelper.

Setting states are mapped to an integer key derived from the user
id and the setting type. Therefore, all setting states are in
a lookup table which makes all opertions very fast.

The code is a complete rewrite aiming for improved clarity and
increased maintainability as opposed to using minor optimizations.
Now setting and getting the changed setting takes around 10 ms. We
can optimize later if needed.

Now the code path through the call API and the one through the
content provider APIs end up being the same which fixes bugs where
some enterprise cases were not implemented in the content provider
code path.

Note that we are keeping the call code path as it is a bit faster
than the provider APIs with about 2 ms for setting and getting
a setting. The front-end settings APIs use the call method.

Further, we are restricting apps writing to the system settings.
If the app is targeting API higher than Lollipop MR1 we do not
let them have their settings in the system ones. Otherwise, we
warn that this will become an error. System apps like GMS core
can change anything like the system or shell or root.

Since old apps can add their settings, this can increase the
system memory footprint with no limit. Therefore, we limit the
amount of settings data an app can write to the system settings
before starting to reject new data.

Another problem with the system settings was that an app with a
permission to write there can put invalid values for the settings.
We now have validators for these settings that ensure only valid
values are accepted.

Since apps can put their settings in the system table, when the
app is uninstalled this data is stale in the sytem table without
ever being used. Now we keep the package that last changed the
setting and when the package is removed all settings it touched
that are not in the ones defined in the APIs are dropped.

Keeping in memory settings means that we cannot handle arbitrary
SQL operations, rather the supported operations are on a single
setting by name and all settings (querying). This should not be
a problem in practice but we have to verify it. For that reason,
we log unsupported SQL operations to the event log to do some
crunching and see what if any cases we should additionally support.

There are also tests for the settings provider in this change.

Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68
 2015-02-11 17:58:22 -08:00
Libin.Tang@motorola.com
0499bb5de4 IMS:change enhanced 4g setting to store in setting db. 
Change-Id: I2ec37478e2bef5b15b157e490f75d5dda5f97117
 2014-10-15 16:12:39 -07:00
Christopher Tate
ccbf84f44c Some system apps are more system than others 
"signatureOrSystem" permissions are no longer available to all apps
residing en the /system partition.  Instead, there is a new /system/priv-app
directory, and only apps whose APKs are in that directory are allowed
to use signatureOrSystem permissions without sharing the platform cert.
This will reduce the surface area for possible exploits of system-
bundled applications to try to gain access to permission-guarded
operations.

The ApplicationInfo.FLAG_SYSTEM flag continues to mean what it is
says in the documentation: it indicates that the application apk was
bundled on the /system partition.  A new hidden flag FLAG_PRIVILEGED
has been introduced that reflects the actual right to access these
permissions.

At some point the "system" permission category will be
renamed to "privileged".

Bug 8765951

Change-Id: I6f0fd9cdb9170e076dfc66d83ecea76f8dd7335d
 2013-06-17 12:47:35 -07:00
Wink Saville
a639b311e9 Create telephony-common and mms-common 
These have been created to reduce the size and complexity
of frameworks/base.

mms-common was created by moving all of
  frameworks/base/core/java/com/google/android/mms
to:
   frameworks/opt/mms

telephony-common was created by moving some of
   frameworks/base/telephony
to:
   frameworks/opt/telephony

Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
 2012-07-11 16:02:08 -07:00
Jean-Baptiste Queru
432bff01ec Do not use a user tag on apps, as it is ignored. 
The build system does not honor user tags on apps,
and setting it is misleading.

This removes the confusion by making the makefiles
behave like they read.

Change-Id: I7c5feba1c7d07f915b97dd098584f29938a4c885
 2010-01-06 08:53:44 -08:00
The Android Open Source Project
b2a3dd88a5 auto import from //branches/cupcake/...@137197 2009-03-09 11:52:12 -07:00
The Android Open Source Project
9066cfe988 auto import from //depot/cupcake/@135843 2009-03-03 19:31:44 -08:00
The Android Open Source Project
d83a98f4ce auto import from //depot/cupcake/@135843 2009-03-03 18:28:45 -08:00
The Android Open Source Project
54b6cfa9a9 Initial Contribution 2008-10-21 07:00:00 -07:00