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
