Develop Reference

Android Auto DHU - Waiting for phone

I'm trying to run desktop head unit on my pc. I set up everything exactly as this guide specifies: https://developer.android.com/training/cars/testing, (tried both 2.0 and 1.1 with the same result). It appears to connect correctly, but I can't get it do display anything other than "Waiting for phone". Console displays following:
Android Auto - Desktop Head Unit
Build: 2020-09-20-332761970
Version: 2.0-windows-beta
[W]: No configuration specified - using default values.
[E]: Could not load configuration from 'C:\Users\kkowalczyk\.android\headunit.ini'.
BoringSSL is the SSL implementation used in the receiver-lib.
Starting link. Requested protocol version: 1.6 (snapshot 314970161)
[I]: Connecting over ADB to localhost:5277...
[I]: connected.
> Phone reported protocol version 1.6
ssl state=TLS client read_server_hello -1
ssl state=TLS client process_change_cipher_spec -1
ssl state=SSL negotiation finished successfully 1
SSL version=TLSv1.2 Cipher name=ECDHE-RSA-AES128-GCM-SHA256
Verify returned: ok
I'm trying to connect to Pixel 5 (with most recent update), is there anything else I can try?

In my case, I also saw the same issue but resolve by following below steps:
Close the DHU emulator.
In the AA app, stop the HU server. Wait for a couple of seconds, start the HU server.
Stop the HU server again. Wait for a couple of seconds, start the HU server.
Start the DHU emulator.
The OOBE screen shows up on the AA app in phone. Complete the flow. While you are completing the flow, the emulator will be on the 'waiting for phone' screen.
Stop and start the emulator. It will start with the black screen with 'waiting for phone' message but after 2-3 seconds the emulator screen comes up.
Hope it can resolve your issue too.

I ran into the same issue (stuck on the "Waiting for phone..." screen) and was able to fix it by changing Application Mode to Developer on the Developer Settings screen of Android Auto.
Make sure to restart the head unit server on the phone after that in case it was already running, then reconnect/restart desktop-head-unit.

I ran into similar issues initially and for me the issue was that the "Accept terms" screen of the Android Auto App running on the device that is triggered on connecting to the Emulated HUD was not visible and noticed until I scanned through the recent apps in the Task Switcher.
This is mentioned in step 11 of the Test Android apps for cars - DHU setup instructions here
If this is the first time you are connecting the mobile device to the DHU, check the mobile device's screen to accept the terms of service and adjust permission settings as needed.
So just note that this screen may not be immediately visible to you unless you switch the relevant screen from the Task Switcher.

Try to test your phone on a real car to make sure phone actually works with Android Auto. I have two phones (Huawei p20 and Xiaomi Mi10): xiaomi works fine but p20 doesn't work with multiple settings and/or option neither in car or DHU, however both of them are considered as compatible with Android Auto.

How to Select a Andorid device from a list of connected Devices to open an application using Appium

I am Testing an android app on multiple real devices like the Samsung S6 and S7 and both are connected to the machine at the same time.
Using Appium library within Robot Framework; Open Application keyword always opens the application which comes first in the list of "adb devices".
Key word used :
Open Application ${APPIUM_SERVER_URL} alias=MyMv1 platformName=${PLATFORM_NAME} platformVersion=${PLATFORM_VERSION} deviceName=${DEVICE_NAME} appPackage=${app_package_name} appActivity=${activity} automationName=appium
It seems deviceName is not working, and I can give any value to it.
Library Version Used :
robotframework==3.0.2
robotframework-appiumlibrary==1.4.3

How to instantiate Appium Driver based on platform?

I am a beginner in automation testing. I am trying to write common test project for my android and ios app. Both the apps on ios and android have almost same UI and flow. I want to know how can I instantiate Appium driver for based on the platform.
As of now, I am thinking to have a boolean variable isAndroid which I would have to manually change in the code before running the tests.Based on isAndroid I instantiate AppiumDriver to AndroidDriver or IOSDriver and elements will be located as per #AndroidFindby or #IOSFindBy
When I start Appium from the terminal, I mention the parameter platformName, is there a way to fetch that information in my code so that I do not have to manually change isAndroid variable and exactly same test code runs on both platforms.

Are you able to try one platform, catch the exception and then try the other?
try:
driver = webdriver.Remote('http://localhost:4723/wd/hub', ios_caps)
run_iOS_tests(driver)
except selenium.common.exceptions.WebDriverException:
driver = webdriver.Remote('http://localhost:4723/wd/hub', android_caps)
run_android_tests(driver)
Otherwise you'll need to use some external method to see what devices are connected (android, ios).

AppiumDriver is unable to identify specific components/pageObjects ( button/image/label) on a android webView container

I am using a hybrid application which is having a native and a webView context. Using AppiumDriver, it is seen that some of the components are not being identified on specific devices or system even though the actual xPath or name is not getting changed when inspected.
Appium app Version: 1.4.13
Appium node Version: 1.4.16
Example:
appiumDriver.findElementByName("Demo_Name").click(); // Working in device 1 but not on Device 2
or
appiumDriver.findElementByName("//android.widget.Button[0][contains(#name,'Demo_Name')]").click(); // Working in device 2 but not on Device 1
And sometime nothings seems to be working. I did try context switching but still no luck.

Can I run Appium for mobile with no target app?

Since I'm working in a platform which works with many apps (rather than a single target app), I find the selection of a target app inefficient for my needs. I wondered if I could do something to avoid it.
I'd like to run freely, sending UI commands to iOS and Android real devices, including installing an app from another app (like Play Store, Apple Store, Test Flight, etc.)
Thanks for the help,
David.

The rule is: 1 Webdriver instance per application.
You can run Appium's server with no --app argument by making sure auto-launch is set to false, and not setting bundleId or app.
Then, in your client/test framework, you use several webdrivers, configured to use different desired capabilities, to tie it all together under a single test case/suite.
The solution:
You may have a test suite that sets desired_capabilities to launch the Safari app, then you install the app, then you quit the webdriver.
Then you change the desired_capabilities to point to the bundle_id of the new app, launch another webdriver instance, do your tests, quit the webdriver..
Then you change the desired_capabilities to point to (etc., etc.)
driver = webdriver.new(url, desired_capabilities)
// do some stuff
driver.quit()
desired_capabilities['app'] = 'company.app.com'
driver = webdriver.new(url, desired_capabilities)
// do some stuff
driver.quit()
desired_capabilities['app'] = '/path/to/application.app'
driver = webdriver.new(url, desired_capabilities)
// do some stuff
driver.quit()