There's LLDB coming into play, and debugServer is what we use on
BareMetal and RemoteLinux, too.
Change-Id: I77f8545ebbe6685708215ac579789f7d4990b7be
Task-number: QTCREATORBUG-23260
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
PIDs on Android (also on linux) are int64 not int
Change-Id: I6611361d4f7ab66018b3174e8fe64a41fa111350
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The gdbserver is not uploaded to device for armv7 as lib symlink
is available and we can use the gdbserver packaged with the apk
Task-number: QTCREATORBUG-21317
Change-Id: I263eb48bbf3cf05b969db934a928185dba10373b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Since Qt 5.12.0 we don't use qmljsdebugger extra intent param anymore
and we need to pass qmljsdebugger to the application arguments.
Fixes: QTBUG-72132
Change-Id: Icefb75e94027b145832c114fd90579bd10bcb898
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Refactor the code to use adb from AndroidManager, do cleanup
and improve logging
Change-Id: I77b682d37c9328e6aa978eaf05b3b5c131907f09
Reviewed-by: hjk <hjk@qt.io>
On Android 64, there is no lib/ symlink anymore, so we need to upload
gdbserver from QtCreator.
Change-Id: Ib6f6d9b623dc61b72dd434ce1b3b409e880bdeaa
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
That was the only remaining field of the AndroidRunnable, passing
the packageName as single string is sufficient.
Change-Id: I73333e58a0719df09d6905eb212007ce421f600e
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
We have nowadays two ways to pass data from run configurations to
tool that do not require intimate knowledge of the sender:
1. Using RunConfigurationAspects, accessible for all workers in a
RunControl
2. Using RunWorker::recordData for an individual worker.
This removes the need to use specific fields in a runnable and
means that a tool plugin can be better separated from target plugins.
The approaches are not mutually exclusive, both use an string-ish
id, I chose here to use the same string when using both.
This patch here uses approach 2. for the GammaRay/Android combo.
It also fixes a (harmless) typo (s/POSTSTART/POSTFINISH).
Change-Id: I4048693ca73b17253a39bfcacc9e1880ecf25736
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The RunWorker will carry the amPreStart/amPostFinish commands later,
and the run control is still accessible via worker->runControl().
Change-Id: Ieac1a1d2a5a8689025a7707b218df44ef2485b16
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It was only set up in AndroidRunner from the run configuration
and passed to AndroidRunnerWorker, instead get in in the
AndroidRunnerWorker from the run configuration directly.
Change-Id: I52fc793f07ca766a80a1b06f216f850da0b563ed
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It was only uses to pass the intent from the Runner to the RunnerWorker,
use a normal stand-alone QString member and setter instead.
Change-Id: I0fde87b0177d4ed013f9599600929070362ea09c
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The difference was the selection of findProcessPID vs
findProcessPIDPreNougat functions, done by a flag now
passed to and used inside a combined findProcessPID function.
Change-Id: I738cdac1a81302c2207f9bc3c74c7cf916ca4089
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The idea was actually to make AndroidRunnable and "everything else",
i.e. StandardRunnable more similar over time to lessen the impact
of the "matrix" problem. The two removed items are avoidable.
Change-Id: I8ef011d76e2ad0154194ff5141ef8eb92cf235f3
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It's nothing that can be chosen freely, rather a feature of
the current setup/device.
Change-Id: I39460e22dab56adcce9da44f61a895923fb8c2a0
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
This also avoid a spurious(?) code model warning about
"function 'deleter' is not needed and will not be emitted"
Change-Id: I76372866ec1a51b3adc350d83b8efcd497b02cb5
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The new way is much reliable and now we can debug all the libs from very
first start, including static constructors, JNI_OnLoad, etc.
The downside is that the startup is a little bit slower then before.
On a Ryzen 1700X is 2 to 5 seconds slower.
Task-number: QTCREATORBUG-19081
Change-Id: Iacedf7b8aa84de5026f9c81eeca35dd377cf4640
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
