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.
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
