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
