all of the builds. Fix that.
We really need to get this generic_with_google product out of
build/target and into vendor/google, but that can come later.
BUG=1786404
Automated import of CL 146687
through the key map. Clarify the help for the -e option to
make clear this should happen.
(This change doesn't affect device code.)
Automated import of CL 146193
This is only a preliminary CL. More will follow but this is
a good start, with the following caveats:
What it does:
- take an input jar, a list of includes, a list of excludes.
- generate actual Java source for the filtered classes.
What it doesn't do yet:
- some more work on filtering inner elements (methods, etc.)
- properly generate inner classes.
- hide synthetic fields.
- some classes body are missing
- directly generate a stubbed bytecode/jar rather than source.
I'll likely want to keep the source generator for debugging
purposes or if we want to integrate with a build system instead.
- classpath will be changed in the final CL to refer to the external
ASM lib rather than the project. I need the source for debugging
rigth now.
- will review comments before submitting.
BUG=1778786
Automated import of CL 145911
Original change by joeo@abreu on 2009/04/06 19:54:13.
Implement SDK add-ons in the build system.
- Add an option to use the standard javadoc doclet instead
of droiddoc, since droiddocs non-sdk templates aren't
ready for prime time.
- Add the notion of a stubs for a library. It's only
implemented for java libraries, but when we do native
libraries in the NDK or sdk-addons, it will work there too.
Automated import of CL 145333
* changes:
Ensure that /system/etc/vold.conf is created in the "generic" product. This is necessary to let the emulator mount SD Card images properly through the "vold" mounting daemon
Fixes http://b.android.com/2308
This is not meant to be a permanent fix, but since everyone except
a handful of people need this, it's easier to set it for everyone
and have that handful of people unset is locally than to force
everyone to make a local tweak.
armv4 was only implemented on StrongArm and Arm8 (See http://en.wikipedia.org/wiki/ARM_architecture)
and will be more difficult to support since it does not support the bx instruction.
armv4t on the other hand is used in a wide range of cpu:s.
armv4 is also not supported by bionic or dalvik, but armv4t is.
Thumb-mode is not yet enabled since there are some unresolved abi-issues.