Somewhat slimmer interface on the user code side and follows
existing practice.
Change-Id: I20ed8f5a00591265d32ea9ce93e1f1bbc76d2437
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This adds workaround to reduce the load added by the update of the
Android device list, which currently happens in a polling style. Skip
an update if (*):
- The current open project is configured with a non-Android kit
- No project is open
- the current project target is null
To summarize the timeline of the timer used here:
- AndroidDeviceManager::setupDevicesWatcher() is called when Creator
is started or when settings are changed. The setup makes the connections
for the timeout and for AVD list future watcher. This will be done once.
If the timer is active it won't be done again, so no duplicate
connections.
- In the setup, the list of devices in updated once.
- On timer timeout, we attempt to update the list, however with
conditions listed in (*) as well as only when an Android adb path is
found.
Fixes: QTCREATORBUG-26547
Change-Id: I13312c4b507ce4e4064adb1c1342f4648f915394
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Since the config can be expected to modify configuration values
(e.g. setEmulatorArgs()) it shouldn't be const, but can be set
to const whenever creating a reference that is not meant for
modifying the config.
Change-Id: I8c816a5422d4d57afa158c723d908e3a9a9a0db8
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Keep it only Android Device since this title is used in many places
around Qt Creator in different contexts it is better to make it
"Android Device" to not give any unintentional hint that only virtual
devices are covered. Such cases are the project creation wizard and the
kit target device settings.
Task-number: QTCREATORBUG-26477
Change-Id: I8c7224243aec6b8f5b5bf95db8d23b9aecbafca6
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This is not really needed anymore, it was mainly used for physical
devices to report whether they need user authorization to be used
via adb. This is now handled by IDevice::DeviceState, where a
Connected device is unauthorized, otherwise any physical device is
ReadyToUse if authorization is good.
Change-Id: If5c1e49b98063eabe4205cd8adb5b11515e1e1de
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
No need to have these enums which are now only a duplication of
IDevice::MachineType and IDevice::DeviceState.
Change-Id: Icc3f112f2670c7354bb282b36fad0f0631b9e047
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: hjk <hjk@qt.io>
AVDs don't get a serial number until they are started, and avdmanager
don't make it easy to get their serial either, so we need to check
the running devices with adb "emu avd name" command and compare.
Change-Id: I3253d25a3461a36eb9918b3c796062bf9e82e0c6
Reviewed-by: hjk <hjk@qt.io>
Actions like start, erase, and avd arguments are specific to emulator
type devices, so make sure such actions are only in that case.
Task-number: QTCREATORBUG-23991
Change-Id: I9d5ffbd733c31540ab4e3d2a617cad54e70f8f8e
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Move some logic for avd creation to the AvdDialog, and some
refactoring and simplification.
Change-Id: Id65e586ab1c0e9e898a04f07d7707371f20da649
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Move AVD management and creation to Qt Creator's DeviceManager
facilities. This allows AVDs to be created from the Devices settings
page and their details and control/action buttons for starting/stopping,
etc. are added there as well. This makes the process similar to other
device types that Qt Creator supports, to get a similar experience.
Task-number: QTCREATORBUG-23991
Change-Id: I16c52b3cc73035e0ee12fd54ae9dad4595c8cda5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Add an AndroidDeviceWidget to handle showing details of detected
Android devices, things like name, serial number, api level,
and more specific info for AVDs.
Task-number: QTCREATORBUG-23991
Change-Id: I97637aa0ced78ebd34c37f2b874802914ce44578
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Currently, on deploy/debug steps on Android, an AndroidDeviceDialog
is popped up each time a deployement is done to select a device. This
can be avoidable by using Qt Creator DeviceKitAspect to have the list
of devices easily selectable from the project mini-menu.
This is better than the current way because it:
* reduces the time from deployment to running the app
* reduces the number of clicks
* avoids having to select the same device each time or
* if a default device is selected, this avoids having to go to project
settings to reset the default device to be able to deploy to a new
device.
* it looks cleaner and more compatible with Creator.
Task-number: QTCREATORBUG-23991
Change-Id: Ida4ab7245c1a3b0ca26c5ccdc9a21a072edf0725
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
WinRt is the odd one out.
Some were using setObjectName, but only used for debug reasons,
not really needed.
Change-Id: I4a370e4694443bc1c455fda4337ef3acfb9259b8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Productization of Qt Live preview for Android didn't happen.
Change-Id: Ie69d8193afec9b59d859bc65c45d36028247e2b9
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
This remove 4 failed adb calls if the qt_live_viewer.apk is missing
(which it always is).
Task-number: QTCREATORBUG-23313
Change-Id: I8dbf833b35a9386d8d87f72c043dd019c62b4467
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Except for the DesktopDevice, which is kind of special. Also try
a bit to make (and partially fail at doing so) naming and code
structure (#include, use of namespaces) more similar to each other.
Change-Id: I9fe266e706b72c14f59ff03ca1ae02dba3adcc71
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
They are not completely orthogonal, so use one function for
now.
This is the step towards streamlining the IDevice::ctor/create
lines of functions.
Change-Id: I1fe9144c45c7da0c9dcbda3bf424e976e0519cd6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Second step towards streamlining the IDevice::ctor/create lines
of functions.
Change-Id: I8b0f2270a9f6545ff9419ef8cf44b456c2233223
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
First step towards streamlining the IDevice::ctor/create lines
of functions.
Change-Id: I44226f8a05902cadd40c8820ab67752070d186c0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It turns out that one "Connection" per RunControl doesn't map
well to the uses we have. Instead, RunWorkers need to know
individually how to connect to the place where they can work,
but they are already specific enough to be able to use a
standard class (like QUrl) as their way to specify the needed
entry point.
In theory one could see a RunControl's connection as an
aggregation of its workers connection bits, but that does
not really seem to be needed in code.
As consequence, replace UrlConnection by a plain QUrl, and also
the HostName connection by a QUrl with hostName set.
Change-Id: I40c97e37779314ac0a77041e864a18eadb78f987
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
E.g. for easier construction of command lines in situations like
if (isLocal())
runnable.commandLineArguments = argumentString(Utils::HostOsInfo::hostOs());
else
runnable.commandLineArguments = argumentString(Utils::OsTypeLinux);
Change-Id: I5a35304e5d1b5a042952201f39f4134a5cd0ce24
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This adds the possibility to have an icon for a device type. Now,
a Kit can have a proper icon if just the device type but not device
is selected.
Change-Id: I2a382ffd5b46cbbf74cdd0b934b3d450d300bfff
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Enable devices to define their default themable icon.
Kit icons are now by default the Desktopdevice icon,
overridable by the device icon of the kit's device,
in turn overridable by an icon file path.
KitManagerConfigWidget: The browse button for the Kit
icon gets a "reset" action.
Change-Id: I6328ba7d640393aee2c324c592e76b4d5430586a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
dynamic_cast<> breaks in cross-library situations. In the past
the issue was witnessed on Mac, this time on FreeBSD in
various configurations.
The workaround deployed here is to manually create unique
type ids in form of (addresses of) global variables.
Task-id: QTCREATORBUG-16462
Change-Id: Ie28fbb3d31d06c1a722a3d9ea808831191298e71
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Ralf Nolden <nolden@kde.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The idea is to have a way for tools to specify what kind of
control channel they would like to use to communicate with
a device without making the choice explicit dependent on
the exact kind of tool to further decouple device and tool
implementations.
The 'hint' values are there to help the device implementation
to decide on which channel to use exactly in case there are
multiple choices. In any case, the tool is responsible to
check that the returned channel is suitable for its operation.
Currently the only choice is "QmlControlChannel" yielding
a simple wrapper around the former IDevice::qmlProfilerHost()
return value.
Other enum values may potentially be {Tcp,LocalSocket}ControlChannel
(to specify a type of transport) AdbChannel (to specify some
generic helper mechanism). It might also turn out that something
more complex than an enum will be needed, e.g. to express
a set of values with priorities or such, but I'd rather
avoid overengineering for now.
Change-Id: Id386425eb3dd2bb395065f0bdb6f67217cd40a71
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
