| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: Iba15f82cb00d19217382c78d8ff37dda1e97ea59
|
| |
|
|
| |
Change-Id: Ic912fdd4b900f42ba6e406b27b911802b8337195
|
| |
|
|
|
|
|
|
|
| |
A simple unit test to display that an update is available.
This will get more complex later. The cache is mocked and
the whole test should be independant of the user's actual
settings and local cache, with no network access.
Change-Id: I58ff45895916a14a10f501a9bd664782d777ed42
|
| |
|
|
|
|
|
| |
Move stuff out of sdklib into common and ide_common.
Remove androidprefs and move the one class into common.
Change-Id: I71d126a13cf2ba413692e29616f4968a37d7b33a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move resources and com.android.util.Pair into layoutlib_api
where they belong since layoutlib depends on them and we need
to control the API.
Made a copy of Pair to stay in common.jar but moved it to
com.android.utils.Pair (the one in com.android.util.Pair is
marked as deprecated to prevent usage where applicable).
Also moved XmlUtil and PositionXmlParser to com.android.utils
to match Pair.
Change-Id: I21d7057d3f2ce604f86a3bb1fa3c130948c93b89
|
| |
|
|
|
|
|
|
|
|
| |
swt.jar must be found relative to the out/ dir
(as generated by create_all_symlinks.sh) to avoid
setting a platform-specific path.
swtmenubar was missing the new libs references.
Change-Id: I365cfa6e011ec831c4df87cb36b0df722caac2e4
|
| |
|
|
|
|
| |
This reverts commit f3d3fa912a10e20cadae813b80a66e538f77131d.
Change-Id: I72e28e21db3c7f959040c1fbb9df14e4d85d0df4
|
| |
|
|
|
|
|
| |
Don't use User Libraries. It's easier to just hardcode them with
a classpath variable.
Change-Id: If8c1236199dd6766d48cf9b553fa2a9ee0d236e6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that in the Android SDK tools, we ship:
- SWT in 32-bit with Carbon only.
- SWT in 64-bit with Cocoa only.
The previous implementation was carbon-only and the
menus were basically not 'macified' when running on
a recent Mac from the command-line. This missing
implementation fixes it.
After experimenting with various implementations of
the original SWT CocoaMenuEnhancer, I finally settled with
this one since it solely uses reflection and does not
import anything from the swt.cocoa namespace. This means
we can easily build this using the makefile which *only*
links with the 32-bit/carbon version of SWT.jar.
Note that on Windows/Linux, the src-darwin folder will
be ignored, which is why it is not mapped as a source
directory and which is why we can't build this directly
from Eclipse.
Change-Id: I53859d3b15bc7026d6bd4f77e048a0c4b4eeb02c
|
| |
|
|
|
|
| |
This is experimental and not completely hooked up.
Change-Id: I4f4892be64f5592d909496e3c9e69c76002397d0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
emulators.
This is a first (and largest) patch in a series of patches over the next month to extend the
AVD and ADT eclipse plugin to support processor-specific platform images and emulators. This
patch is intended to co-exist with patches to create x86 emulator environments and overall
SDK support.
There is an overall expectation that the sdk building process will be updated to meet the
following expectations... It is not in the scope of these UI patches to change the overall
sdk building structure.
expectation #1:
tools/emulator[.exe] -- ARM
tools/emulator-x86[.exe] -- x86
tools/emulator-foo[.exe] -- an arbitrary additional architecture (extensible)
expectation #2:
platforms/android-XXX/images/arm - location of kernel/images for ARM
platforms/android-XXX/images/x86 - location of kernel/images for x86
platforms/android-XXX/images/foo - location of kernel/images for arbitrary architecture
expectation #3
In the event that add-ons are in the SDK,
add-ons/addon_XXX/images/arm - location of kernel/images for ARM
add-ons/addon_XXX/images/x86 - location of kernel/images for x86
add-ons/addon_XXX/images/foo - location of kernel/images for arbitrary architecture
NOTE: For "earlier"/legacy api levels, it is assumed that it is ARM only and the images will
be in platforms/android-XXX/images and add-ons/addon_XXX/images
When an API level is chosen in AVD, it scans the appropriate API directories and determines
if the image directory is "legacy" or if it has subdirectories. In the latter case, it
populates the list of potential processors using these directory names (and some
prettyprinting for well known architectures)
tested using "android" command line to start AVD on linux and windows
tested using Eclipse plugin AVD integration on linux and windows
REMINDER: You need to change the directory layout of images and add the right
emulator-XXX[.exe] to test it
If one uses the "android" command line to create an AVD from the command line, the
processor type is assumed to be arm today. A future patch will be needed to add
command line processor type selectivity
Change-Id: Ifd7c39bf93c6e926f62407bfed024d2789efb41a
|
| |
|
|
| |
Change-Id: I9ec9175e0734a5b07fa5b3879cdf7b1ef0056d27
|
| |
|
|
|
|
|
|
| |
This adds or changes no functionality.
It just exhibits the bug from issue 14393 which will
be fixed in the next CL.
Change-Id: Icff2023120014b422c002efde8f20175ff52e266
|
| |
|
|
|
|
| |
SDK BUG 2040986
Change-Id: Ica46d14939bb3a9bf499899a0bf571456d4c6017
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Created a permanent SdkManager in UpdaterData (alongside a new AvdManager).
Pages can request a reload (for example on install/delete of a local package),
and other pages are notified of SDK changes to update their display (local
packages, local AVDs, available packages, etc...)
Removed references to UpdaterWindow from the pages (moved some actions
like installArchives and refreshSources into UpdaterData).
Added a new page for the AVDs. Pretty basic for now (only the current AVD
display).
Clicking refresh on the Local pages causes a reload which triggers a
refresh of the listeners pages which properly reloads the AVD page.
|
| |
|
|
| |
The window is shown when the "android" tool is invoked with no parameter.
|
| | |
|
| | |
|
| |
|
