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.
Original author: raphael
Merged from: //branches/cupcake/...
Automated import of CL 145983
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
It's really time to let the hackish bash/sed version go away,
especially since it's really really slow, and provide a
better python version instead.
Original author: raphael
Merged from: //branches/cupcake/...
Automated import of CL 145487
It's really time to let the hackish bash/sed version go away,
especially since it's really really slow, and provide a
better python version instead.
Original author: raphael
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 145498
Issue: when the SDK gets (re)loaded, the uiRootNode changes
in the UiTreeBlock. However the TreeViewer is using a
content provider which root node was not updated. The fix is
to make the content provider dynamically ask for the root
node to the tree block. Instead of depending on the class
directly, a new interface is passed for this.
Original author: raphael
Merged from: //branches/cupcake/...
Automated import of CL 145402
Issue: when the SDK gets (re)loaded, the uiRootNode changes
in the UiTreeBlock. However the TreeViewer is using a
content provider which root node was not updated. The fix is
to make the content provider dynamically ask for the root
node to the tree block. Instead of depending on the class
directly, a new interface is passed for this.
Original author: raphael
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 145419
The fix is that a menu contribution should redefine the menu that it is
contributing too. In this case it seems the JDT is not yet loaded or at
least hasn't defined the menu that we're contributing too, so we need to
define it. This definition is extracted from the jdt.ui/plugin.xml from
3.4 in order to define the same group names in the same order.
Original author: raphael
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 145170
Also renamed the container for add-ons to include the base platform name (so that at least a version is displayed).
Original author: xav
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 145169
It's really time to let the hackish bash/sed version go away,
especially since it's really really slow, and provide a
better python version instead.
BUG=1761137
Automated import of CL 145204
The fix is that a menu contribution should redefine the menu that it is
contributing too. In this case it seems the JDT is not yet loaded or at
least hasn't defined the menu that we're contributing too, so we need to
define it. This definition is extracted from the jdt.ui/plugin.xml from
3.4 in order to define the same group names in the same order.
Original author: raphael
Merged from: //branches/cupcake/...
Automated import of CL 145099
Also renamed the container for add-ons to include the base platform name (so that at least a version is displayed).
Original author: xav
Merged from: //branches/cupcake/...
Automated import of CL 145098
Issue: when the SDK gets (re)loaded, the uiRootNode changes
in the UiTreeBlock. However the TreeViewer is using a
content provider which root node was not updated. The fix is
to make the content provider dynamically ask for the root
node to the tree block. Instead of depending on the class
directly, a new interface is passed for this.
BUG=1761064
Automated import of CL 145004
The fix is that a menu contribution should redefine the menu that it is
contributing too. In this case it seems the JDT is not yet loaded or at
least hasn't defined the menu that we're contributing too, so we need to
define it. This definition is extracted from the jdt.ui/plugin.xml from
3.4 in order to define the same group names in the same order.
BUG=1722971
Automated import of CL 144940
Also renamed the container for add-ons to include the base platform name (so that at least a version is displayed).
BUG=1775936
Automated import of CL 144938
ID when selecting a string reference.
Original author: raphael
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 144490
Activities that do not have an action, or that are set to not be exported cannot be launched from 'am start...' so they should not be considered when finding an activity to launch.
Original author: xav
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 144419
