[JBoss JIRA] (ARQ-1581) Droidium does not work with remote emulators
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1581?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic edited comment on ARQ-1581 at 11/29/13 4:19 PM:
------------------------------------------------------------------
[~kpiwko]
https://code.google.com/p/android/issues/detail?id=60024
https://issues.jenkins-ci.org/browse/JENKINS-20819
was (Author: smikloso):
[~kpiwko]
https://issues.jenkins-ci.org/browse/JENKINS-20819
> Droidium does not work with remote emulators
> --------------------------------------------
>
> Key: ARQ-1581
> URL: https://issues.jboss.org/browse/ARQ-1581
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
>
> *When*:
> I use Android Jenkins Plugin to start the device
> *Then*:
> It starts the emulator using remote syntax, that is including --port port1,port2
> *Expect*:
> Drodium will connect to already running emulator.
> *Actual problem*:
> AndroidDevice and IDevice isEmulator() call is not able to parse the data retrieved from adb devices. This results into Droidium trying to start emulator with the same name, however this emulator is already started so event marking correct startup is never send and test fails.
> Output:
> {code}
> export ANDROID_ADB_SERVER_PORT=52892
> [tester@fedora19 ~]$ ANDROID_SDK_HOME=`pwd`/workspace/mobile-eap-test ./tools/android-sdk/platform-tools/adb devices
> List of devices attached
> localhost:46689 device
> {code}
> However, emulators are expected to be in format of emulator-XYZ.
> Drodium should be able to modify the behavior to handle this correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1581) Droidium does not work with remote emulators
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1581?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic commented on ARQ-1581:
----------------------------------------
[~kpiwko]
https://issues.jenkins-ci.org/browse/JENKINS-20819
> Droidium does not work with remote emulators
> --------------------------------------------
>
> Key: ARQ-1581
> URL: https://issues.jboss.org/browse/ARQ-1581
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
>
> *When*:
> I use Android Jenkins Plugin to start the device
> *Then*:
> It starts the emulator using remote syntax, that is including --port port1,port2
> *Expect*:
> Drodium will connect to already running emulator.
> *Actual problem*:
> AndroidDevice and IDevice isEmulator() call is not able to parse the data retrieved from adb devices. This results into Droidium trying to start emulator with the same name, however this emulator is already started so event marking correct startup is never send and test fails.
> Output:
> {code}
> export ANDROID_ADB_SERVER_PORT=52892
> [tester@fedora19 ~]$ ANDROID_SDK_HOME=`pwd`/workspace/mobile-eap-test ./tools/android-sdk/platform-tools/adb devices
> List of devices attached
> localhost:46689 device
> {code}
> However, emulators are expected to be in format of emulator-XYZ.
> Drodium should be able to modify the behavior to handle this correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1582) Honor ANDROID_SDK_HOME, deprecate generatedAvdPath
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1582?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1582:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha3
> Honor ANDROID_SDK_HOME, deprecate generatedAvdPath
> --------------------------------------------------
>
> Key: ARQ-1582
> URL: https://issues.jboss.org/browse/ARQ-1582
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
> Priority: Critical
> Fix For: droidium_1.0.0.Alpha3
>
>
> ANDROID_SDK_HOME represents a top level directory that is used to store metadata of AVDs. By default, this directory equals $HOME.
> However, various plugins and tools - such as Jenkins Android Plugin, allow to change ANDROID_SDK_HOME to better isolate jobs.
> Droidium should be able to:
> * pass androidSdkHome in arquillian.xml with default = user.home
> * honor this directoryand create generated AVDs there - this will limit write access to single location - e.g. pattern would be ${androidSdkHome}/.android/${avdName}.avd
> Then, *generatedAvdPath* can be dropped altogether - reasoning is that Android UI does not allow that neither and it does not make much sense to split metadata and AVD itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1582) Honor ANDROID_SDK_HOME, deprecate generatedAvdPath
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1582?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic resolved ARQ-1582.
------------------------------------
Resolution: Done
> Honor ANDROID_SDK_HOME, deprecate generatedAvdPath
> --------------------------------------------------
>
> Key: ARQ-1582
> URL: https://issues.jboss.org/browse/ARQ-1582
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
> Priority: Critical
> Fix For: droidium_1.0.0.Alpha3
>
>
> ANDROID_SDK_HOME represents a top level directory that is used to store metadata of AVDs. By default, this directory equals $HOME.
> However, various plugins and tools - such as Jenkins Android Plugin, allow to change ANDROID_SDK_HOME to better isolate jobs.
> Droidium should be able to:
> * pass androidSdkHome in arquillian.xml with default = user.home
> * honor this directoryand create generated AVDs there - this will limit write access to single location - e.g. pattern would be ${androidSdkHome}/.android/${avdName}.avd
> Then, *generatedAvdPath* can be dropped altogether - reasoning is that Android UI does not allow that neither and it does not make much sense to split metadata and AVD itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1585) Droidium does not figure out AVD is broken
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1585?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic resolved ARQ-1585.
------------------------------------
Resolution: Done
> Droidium does not figure out AVD is broken
> ------------------------------------------
>
> Key: ARQ-1585
> URL: https://issues.jboss.org/browse/ARQ-1585
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Priority: Blocker
> Fix For: droidium_1.0.0.Alpha3
>
>
> Current AVD name parsing is broken, it won't figure out that AVD is actually broken - for instance metadata point to AVD images that are no longer on filesystem. Even in such situations Drodium starts emulator, which is deemed to fail and Droidium waits up to all timeout to fail the test.
> Ideally, Droidium should handle such situation and figure out that metadata of broken device should be deleted if user requested that AVD by name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1585) Droidium does not figure out AVD is broken
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1585?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1585:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha3
> Droidium does not figure out AVD is broken
> ------------------------------------------
>
> Key: ARQ-1585
> URL: https://issues.jboss.org/browse/ARQ-1585
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Priority: Blocker
> Fix For: droidium_1.0.0.Alpha3
>
>
> Current AVD name parsing is broken, it won't figure out that AVD is actually broken - for instance metadata point to AVD images that are no longer on filesystem. Even in such situations Drodium starts emulator, which is deemed to fail and Droidium waits up to all timeout to fail the test.
> Ideally, Droidium should handle such situation and figure out that metadata of broken device should be deleted if user requested that AVD by name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1583) Emulator does not figure out process had died
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1583?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1583:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha3
> Emulator does not figure out process had died
> ---------------------------------------------
>
> Key: ARQ-1583
> URL: https://issues.jboss.org/browse/ARQ-1583
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Karel Piwko
> Priority: Critical
> Fix For: droidium_1.0.0.Alpha3
>
>
> *When*:
> I let Droidium start emulator.
> *Given*:
> Emulator command fails, for instance when DISPLAY is not set.
> *Then*:
> Droidium waits up to emulator start time, then fails.
> *Expected*:
> Droidium will figure out command had failed - emulator actually outputs *SDL init failure, reason is: No available video device* and let user know what happened wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQ-1583) Emulator does not figure out process had died
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1583?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1583:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Emulator does not figure out process had died
> ---------------------------------------------
>
> Key: ARQ-1583
> URL: https://issues.jboss.org/browse/ARQ-1583
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Karel Piwko
> Priority: Critical
>
> *When*:
> I let Droidium start emulator.
> *Given*:
> Emulator command fails, for instance when DISPLAY is not set.
> *Then*:
> Droidium waits up to emulator start time, then fails.
> *Expected*:
> Droidium will figure out command had failed - emulator actually outputs *SDL init failure, reason is: No available video device* and let user know what happened wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQGRA-410) NPE when calling Graphene#createPageFragment inside TestNG @BeforeMethod or @AfterMethod
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-410?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-410:
------------------------------
Sprint: (was: Graphene 2.0.1)
> NPE when calling Graphene#createPageFragment inside TestNG @BeforeMethod or @AfterMethod
> ----------------------------------------------------------------------------------------
>
> Key: ARQGRA-410
> URL: https://issues.jboss.org/browse/ARQGRA-410
> Project: Arquillian Graphene
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Reporter: Jiri Locker
> Assignee: Juraj Húska
> Fix For: 2.0-Tracking
>
>
> Stack trace:
> {noformat}
> org.jboss.arquillian.graphene.enricher.exception.PageFragmentInitializationException: java.lang.NullPointerException
> at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:171)
> at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.createPageFragment(DefaultGrapheneRuntime.java:116)
> at org.jboss.arquillian.graphene.Graphene.createPageFragment(Graphene.java:263)
> at org.jboss.qa.brms.workbench.AbstractPerspective.<init>(AbstractPerspective.java:56)
> at org.jboss.qa.brms.workbench.HomePerspective.<init>(HomePerspective.java:12)
> at org.jboss.qa.brms.DesignerTestWrapper.login(DesignerTestWrapper.java:65)
> at org.jboss.qa.brms.dashboard.DashboardsMenuTest.init(DashboardsMenuTest.java:20)
> Caused by: java.lang.NullPointerException
> at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68)
> at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:74)
> at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:156)
> ... 36 more
> ... Removed 30 stack frames
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ARQGRA-410) NPE when calling Graphene#createPageFragment inside TestNG @BeforeMethod or @AfterMethod
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-410?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-410:
------------------------------
Fix Version/s: 2.0-Tracking
(was: 2.0.1.Final)
> NPE when calling Graphene#createPageFragment inside TestNG @BeforeMethod or @AfterMethod
> ----------------------------------------------------------------------------------------
>
> Key: ARQGRA-410
> URL: https://issues.jboss.org/browse/ARQGRA-410
> Project: Arquillian Graphene
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Reporter: Jiri Locker
> Assignee: Juraj Húska
> Fix For: 2.0-Tracking
>
>
> Stack trace:
> {noformat}
> org.jboss.arquillian.graphene.enricher.exception.PageFragmentInitializationException: java.lang.NullPointerException
> at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:171)
> at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.createPageFragment(DefaultGrapheneRuntime.java:116)
> at org.jboss.arquillian.graphene.Graphene.createPageFragment(Graphene.java:263)
> at org.jboss.qa.brms.workbench.AbstractPerspective.<init>(AbstractPerspective.java:56)
> at org.jboss.qa.brms.workbench.HomePerspective.<init>(HomePerspective.java:12)
> at org.jboss.qa.brms.DesignerTestWrapper.login(DesignerTestWrapper.java:65)
> at org.jboss.qa.brms.dashboard.DashboardsMenuTest.init(DashboardsMenuTest.java:20)
> Caused by: java.lang.NullPointerException
> at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68)
> at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:74)
> at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:156)
> ... 36 more
> ... Removed 30 stack frames
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month