We introduced changes to the Endpoint lifecycle.
Modified the AIDL compiler to take into account the
changes. Just affected the constructor, which needs
now an extra parameter: placeInfo
We need to pass an RpcContext with information
such as the caller's certificate. I also modified
the compiler so it does not use Container anymore
and uses Context
The SDK build system does not provide an output file
and instead uses the -o<FOLDER> option and lets aidl figure
out the intermediary folders that represents the packages,
and the filename based on the input file (and its package).
Because of this the -d<FILE> option to generate a dependency
file is not convenient.
Instead the new option, -a (no parameters), automatically generate
a dependency files next to the output file.
Also, when compiling parcelable aidl files, without the -b option,
a dependency file is still generated. This is used by the SDK build
system since it cannot parse the file separately and instead tries
to compile every .aidl file.
The generation of this dependency file (which shows no output) allows
to know when any type of aidl file has been compiled.
Change-Id: If81dc7e1e0a780592c94d1850a1d1b094d6e7908
Merge commit '9d71860e8cbaf16ddae3cd5d06ede8e6cfc7675a' into gingerbread
* commit '9d71860e8cbaf16ddae3cd5d06ede8e6cfc7675a':
The aapt and aidl tools are prebuilt when we're doing an apps-only build, so don't try to build them.
Otherwise printf is undeclared. These files worked with earlier versions
of gcc because either cstdio or stdio.h was being included by some other
header file. But this was not guaranteed behavior, so with GCC 4.4 there
are errors. The fix is backwards compatible with earlier versions of GCC.
This change includes either <cstdio> or <stdio.h> whichever looks more
appropriate given the other headers included by the given source file.
Note, I'm using "GCC" to mean Gnu Compile Collection, as this problem is
specific to C++ source files. (Presumably a C++-specific header file
changed to no longer include cstdio.)
AIDL generates unnecessary "import" statements. These cause warnings
within Eclipse when the default Eclipse warnings settings are used.
This is inconvenient since the generated .java files are not
editable. Some pesky organisations have a zero-warnings policy
too, so there's no option but to fiddle with the Eclipse settings.
This patch ensures that all usages of class names within the
generated code are fully-qualified. In practice, they were nearly
all fully-qualified already. And this patch also removes the
generation of the import statements, since they are redundant
if we're using fully-qualified names everywhere.
This should fix issue 43 in the Google Code Android issues tracker.
http://code.google.com/p/android/issues/detail?id=43
I would appreciate if somebody who knows exactly how 'aidl'
works could confirm that there's no reason 'import' statements
would have been necessary except for the bits I've fixed. (I think
unqualified names were used much more frequently in early versions
of aidl, which might explain why import statements are generated
so eagerly).
