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
