The DexWrapper is legacy code from the original ADT plugins I
believe. Why they did it that way I don't know.
Dave
To get dex to work,
I had to apply the same approach as Gradle, which is to
launch a command shell and run "java
com.android.dx.command.Main --dex ...".
The good news is
that Build Tools version will probably not be an issue.
However, I would
like to know why the DexWrapper was employed in the first
place as the command shell approach is a natural choice.
I can now build,
install and run my test application targeting API 25 and
with the bug fix. The next thing to try is a Robolectric
test on the MainActivity class.
Andrew
Andrew, go ahead and make any change that needs to be made.
We probably also need to add a check to see what version of
the build tools is required, and put a warning dialog up that
can be dismissed, saying something to the affect that they
must upgrade to version 26 at least. We can also put this
out in a release document as well, when we do the release.
When the android sdk makes these types of changes we just
have to adapt with them.
Dave
On 10/18/2017 6:27 PM, Andrew
Bowley wrote:
I have
hit an important change to the build tools which needs
to be addressed. The Dex tool main class has changed
with version 26 from being totally static to just having
a static main method.
This
means the DexWrapper class is no longer needed and in
fact throws an NPE when dexing with version 26 dx.jar.
How
should I proceed? To jettison DexWrapper forces everyone
to use build tools version 26 and above.To leave it in
adds unwelcome complexity to Andmore.
Andrew
Dave
I have pressed on,
patching the code to avoid compilation errors, and one
issue needs to be resolved from this activity.
There is a class
named DeviceMenuListener in "adt" package
org.eclipse.andmore.internal.editors.layout.configuration
which has the following logic:
"Group the devices
by manufacturer, then put them in the menu. If we don't
have anything but Nexus devices, group them together
rather than make many manufacturer submenus."
I had to comment
out the Nexus code as it references objects in an
sdk-common helper class which have been removed. Maybe a
bug report needs to be raised so the design can be
reviewed.
I am now at the
stage of having set up a test environment to proove the
PR. I am hoping there are no big surprizes so I can
submit the PR shortly.
Andrew
Andrew, thanks. Can you put a pull request together that
contains all the fixes, and I'll try to get it going through
the simulataneous review process. This will allow us to
merge the change, while allowing the IP team to do their
review.
In this case, it would be better to have one commit with
all the changes, so it would be easier to back out if we
need to for any reason. If you follow the format of the
other commit messages, the PR will automatically be linked
back to bugzilla.
Thanks for the all the effort on this.
Dave
On 10/15/2017 4:50 PM, Andrew
Bowley wrote:
Please find attached file
containing information on dependency jars for the CQ
process.
The bug fix requires
Andriod SDK builder-2.3.3.jar which declares 34
dependencies. These include 7 other SDK artifacts
which I indicate are not expected to be deployed at
this time.
Andrew
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
