| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I026347f1b81643eecd685e60cb5a35428aaaba62
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a "find_java.exe" that will be packages
in SDK/tools/lib. It will be used by android.bat
and the other launchers to locate the best version
of java to use for our tools (currently we have
a find_java.bat that uses DOS commands to achieve
something similar but more limited).
In addition this creates a static "findjavalib"
that is used by the NSIS installer to locate
java and get its version (to complain in case we
only find a Java 1.4 or lesser). The goal is for
the installer to use the same logic as the tools
will use to locate the java binary.
Change-Id: Ic2efb388135087bab9687c3332882047fd041b1c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also properly redirect command-line output
to the parent shell console.
This is experimental. This CL removes "android.exe"
from the Windows tools and only keeps android.bat.
However in a next CL android.bat will be changed
to use 'find_java' to locate the best Java exe around
(this is currently done in a bat script)
Change-Id: I6e5485fdf59fde9838cf929ff333e1c611ea7bb4
|
|
|
|
|
|
|
|
|
|
|
| |
2 issues:
- the code was still trying to look for the obsolete
"compatibility" export <path> instead of the new "support".
- the install filter did not support the <old-path> pkg attribute.
SDK Issue: 21488
Change-Id: Ie083b008d9ecdb9467a1b203c7602b5cc8c0580d
|
|\ |
|
| |
| |
| |
| | |
Change-Id: Iae9033f04654e03151c206b5dfb1fd8f47eea8f2
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When listing packages by "repository" (e.g. by source URL),
the name of external source isn't always set. It turns out
that when processing packages, we load local packages first
and only their source URL is known, not the "UI name" of the
source so this results in categories with no known UI name
*if* they have at least one local package installed.
This changes the package loader so that it will try to adjust
the label of a source even if it's loaded after the category
has been created.
Change-Id: I285fdefdae99c635d9fd139ca50d17706eea3ae6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset fixes issue
23747: i and İ character problem in turkish operating Systems...
and probably many other bugs in the Turkish locale.
Basically, we had a lot of String.toLowerCase() and
String.toUpperCase() calls. This performs locale sensitive
conversions, which in many cases is NOT what we want; for "machine
readable" conversions we should be using Locale.US which performs no
special cases.
For more, see
http://developer.android.com/reference/java/util/Locale.html#default_locale
Change-Id: I996b0e70fb377e8dae484c5811deb8bc9afb684c
|
|
|
|
|
|
|
|
|
| |
This allows the parser to process an input such as:
$ cmd verb --arg1 value1 --arg2 value2 value3 value4
or
$ cmd verb --arg1 value1 --arg2 value2 -- -value3 --value4
Change-Id: I7ea6c019c2bb4ee5003bdba1f0774f3c062322c2
|
|
|
|
| |
Change-Id: I4413efea2887436d167ce44db6f0cd711bdf8fdd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a new @NonNull annotation, to match our existing
@Nullable annotation, and it adds configuration settings for Eclipse
3.8 / Eclipse 4.2 which configures the new null analysis there to use
our own annotations. Note that the annotations only have source
retention so there is no extra size or class-loading overhead. (To use
findbugs you'll need to temporarily change retention to class-level.)
In upcoming CL's I'll use these annotations to clarify the Lint API
and other APIs.
Change-Id: I99096d8b8a7e25ef002624d592da7700195a5872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset makes the SDK codebase compile with source=1.6 (which
means it also requires JDK 6). This means that methods implementing an
interface requires @Override's. It also means we can start using APIs
like the ArrayDeque class and methods like String#isEmpty().
This changeset looks big but the change is trivial: it's basically
adding @Override in all the places that need it, along with some other
automatic Eclipse cleanup in certain files (such as reordering imports
where they were incorrectly ordered (because older versions of Eclipse
didn't always handle inner classes right)), as well as cleaning up
trailing whitespace and removing some $NON-NLS-1$ markers on lines
where there aren't any string literals anymore.
This changeset also sets the source and target JDK level to 6 in the
Eclipse compiler .settings file, and synchronizes this file to all the
other Eclipse SDK projects.
Change-Id: I6a9585aa44c3dee9a5c00739ab22fbdbcb9f8275
|
|
|
|
|
|
|
|
|
|
| |
This renames the list/update sdk --obsolete flag
to --all (-a shortcut) to better reflect what the
code actually does.
SDK Bug: 23004
Change-Id: Ide60f3de97767283e7574a92d4ec96b0e5d4fd86
|
|
|
|
|
|
| |
SDK Bug: 21312
Change-Id: I49462d9750c4f64f92372793dee65d28f23e94ab
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a user aborts a download in the SDK Manager,
we call the HttpClient InputStream.close().
It turns out this blocks till the download is complete.
Issuing the client shutdown first makes it really
close the connection, as indicated in the javadoc.
SDK Bug: 21167
Change-Id: Ie68a60d60f482a0f7abaea084ffbf6700a0a9a3d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the 'android list sdk' to output the system
images and source packages in the list. Since there are
no hard dependencies on them, they were not listed.
The behavior is changed to:
- 'android list sdk': display all potential and
mandatory updates and their dependencies.
- 'android list sdk --obsolete': display everything
compatible on the remote sources.
This allows users to install sources and system images
from the command line:
$ android list sdk -e -o
$ android update sdk -u -o -t source,system-image # all
$ android update sdk -u -o -t source-14,sysimg-14 # API14
Also, although system images are not mandatory (e.g. they
are not hard dependencies of platforms), the heuristic is
that if a platform doesn't have any system image of its
own we'll suggest any matching sys-image we can find for
either new platform or the currently highest installed one.
SDK Bug: 21880
Change-Id: I4c47c6e60d885ebeaf181288db743b382fdb1618
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Issue was a typo and the script was setting the
files as read-only (instead of clearing the r-o
attribute, it was setting it) before trying to
copy them.
Also reverted the code that hides the launched
app window so that the sdkmanager actually be
visible.
SDK Bug: 5683762
Change-Id: Id23302981f84b227361c6208fe6ef512e0ac2de3
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Change-Id: Ic8b2130a327d73c044c0931509385aed19f78a9e
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core issue was that source packages were not properly
zipped on the build server side, which made the unzip crash
with an EOFException. This simply adds a better verbose
message in case this happens again.
It seems the Java ZipFile bug listed in there is fixed
at least in the JVM I'm currently running (1.6 and 7)
but anyway I added the extra safeguard code as documented
in the reported bug (e.g. don't ask ZipFile to unzip more
than the actual size of the entry.) Can't hurt to have it.
Change-Id: Ib47530920474e320da69c35d9a695d931bed55c1
|
|
|
|
|
|
|
| |
android.exe is not ready for usage yet.
The local sdk parser can still detect both.
Change-Id: I597f9b5553628b55703aa12282b2808c0b6d1fb1
|
|
|
|
|
|
| |
This addresses CL feedback from Change I7275cfee
Change-Id: Ie86dc2efc0a26c783b63e45db32b9d388a6562b1
|
|
|
|
|
|
|
| |
This enables maintaining user input between multiple invocations
of the dialog during a single session.
Change-Id: Id391ce8e23d65ab20ceba117c89bc8b9c9e2240f
|
|
|
|
|
|
|
|
|
| |
This removes the SDK Manager 1 window implementation.
There are still a few odds and ends that require some
cleanup for later, e.g. the "update chooser dialog"
but it actually needs a revamp rather than just a cleanup.
Change-Id: Icb90fd1f5d9d8ca4b1ffeea72b8c20aed12cbe26
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I549340bdaaf78d6d314992ad2b91e9b45f97d2c2
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Change-Id: I7275cfeeec53511b1679c203a149b801e137b921
|
|\ \
| |/
|/| |
|
| |
| |
| |
| | |
Change-Id: Ia8375444bf99b33396616a57e781adb22d82175d
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes 2 issues:
- A bug in android.bat was that the bat+lib were
only copied if the arguments were 'update sdk'.
However since Tools R14 the sdkmanager doesn't
use these arguments anymore.
- Consequently when invoked as 'android sdk' it was
not copying itself in the temp folder and thus
was locking the tools folder, preventing updates.
- The new behavior is to always copy, like that we
don't care how the app is launched.
- The SDK Manager.exe was launching android.bat and
then waiting for it to finish, capturing its
stdout in care there's an error to display.
That locks SDK Manager.exe and thus prevent from
updating it too. So instead we just don't wait for
the bat to finish, don't capture/display its stdout.
If there's an error, the user can still use the
command line version to find out what's wrong.
SDK Bugs: 21212:SDK Setup.exe [keeps] an open file handle
SDK Bugs: 11989:SDK Manager.exe should be able to detach
(it doesn't do the part where the sdk manager could restart
itself after an update though. I'll file a different issue.)
Change-Id: Id473ce58d3f36d417b6c0ee5f07a039adbbe06c0
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I17d4eae699e55e41c26c6125175b893a3012699e
|
|\ \
| |/
|/| |
|
| |
| |
| |
| | |
Change-Id: Iad1576ec4ca03213679aabb97328bcf9c0f590eb
|
|/
|
|
| |
Change-Id: Id030c98501fd0b971a7377da95b452370dc7e1e7
|
|
|
|
|
|
|
|
| |
It can't be used at the same time as the new one
(the SDK_TEST_BASE_URL one) as it is confusing if
both are defined.
Change-Id: I5b3ab7bac5d58ab9b1e47e2aea43229156c30083
|
|
|
|
|
|
| |
SDK Bug: 5508174
Change-Id: I14ab4163e0f07824226cc78f72b538e2f82d7c5f
|
|
|
|
|
|
| |
SDK Bug: 5508174
Change-Id: I466ba63c7f6c4158be42df1151f540d26c63e342
|
|
|
|
| |
Change-Id: I15d0b46ef09791ea000724e571de63923f147b6d
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
SDK Bug 20535.
Doesn't seem reproducible, so just defend against
a potential NPE anyway.
Change-Id: Ieb6a0958c7585ea3c5cffbb640943263a14e4c60
|
| |
| |
| |
| |
| |
| | |
http://code.google.com/p/android/issues/detail?id=21006
Change-Id: Ice55f026e9d78922bfa359edad62630a8f7fb8ed
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
SDK Bug: 20963
Change-Id: I46b8e808f2eb0c008b60036631a4d061d02085c6
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
- Clearly states that a package is not compatible.
- Provides an env var to work around and install anyway:
$ export ANDROID_SDK_IGNORE_COMPAT=1
$ tools/android
Change-Id: I5d94fbe452c72572054b2aecb781acfe3519135c
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
Should have been in a3e43f30cf2278afd5dbc5864442529129b3a057
Change-Id: I9018f8b3b0e5bfb07b05acba9d1c6d4fae04181a
|
|/
|
|
|
|
|
|
|
|
| |
SDK Bug: 20939
Incidentally, this also fixes the fact that the window
for the SDK/AVD manager can't be resized at all on Windows
when started from ADT. SWT is quite magical.
Change-Id: I282ebdac3e42e39ee41247de5591cfcb61cd4ac8
|