As apparently Samsung devices don't have it. The new algorithm
is:
- If it is a 64 bit device
- Either pull /system/bin/app_process64 (64bit process)
- or pull /system/bin/app_process32 (32bit process)
- If it is a 32 bit device
- First try /system/bin/app_process32
- If that doesn't exist try /system/bin/app_process
The old code did a symlink resolution on one of app_process[32|64|],
but I believe the symlink resolution was only needed for a symlink
from app_process to app_process32, which is covered by this code.
Change-Id: Iedeeb247c3059931e1ddf6d01e8b2aab13156470
Task-number: QTCREATORBUG-15006
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
On an 64 bit Android, libc.so for 64 bit apps is located in /system/lib64/.
Change-Id: I93f0e4658e552c9a32822706bab3e503642a8c59
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
On arm64 devices /system/bin/app_process is a symlink to /system/bin/
app_process64, the problem is that we are pulling it also for 32bit
apps, which will make the debugging impossible because arm-linux-
androideabi-gdb 32bit can't mix the architectures.
Change-Id: I37e071456fb89051b0433ee2e7635085257616ea
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
We used to only identify the avd by api level and abi. That was
obviously incorrect, but at the time I didn't know how to get
the actual avd name from a running emulator.
Turns out this is reasonable easy via telnet on the emulator port.
Change-Id: I387901a5294674f44399c0726abcc9feea221e8d
Task-number: QTCREATORBUG-13095
Reviewed-by: BogDan Vatra <bogdan@kde.org>
/system/bin/app_process can be a link to e.g. /system/bin/app_process32,
which we resolve first via "adb shell" before calling "adb pull".
Task-number: QTCREATORBUG-14201
Change-Id: Ic133cf0bcec3234839680584ff4807f443161e6c
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
On Qt < 5.4 androiddeployqt can't be used to only install the package
(and qt libs if the debug deployment was chose).
Change-Id: Ia7939e7988163ec04bdc7a927fd3a89e4d824782
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
- Split up androiddeployqt into two steps: One building the apk,
and one deploying it to the device.
- The build apk step base class AndroidBuildApkStep is ihneritaged by
the qmake specific class QmakeAndroidBuildApkStep.
- The deployment step is still called androiddeployqt
- Move all qmake specific code to the qmakeprojectmanager plguin
- Flip the depencency between the android and qmake plugin, now
the qmake plugin depends on the android plugin, implementing
a interface the android plugin provides.
- Note: This removes the debug deployment for now.
Change-Id: I1c386640159ed14b637668abde8eb3b9009ab803
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Another follow up fix for 93304df038 .
Change-Id: I39c98ed2e769a048c00931bd3b850d4d50310d99
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
Since we copy the java files to the build directory, we need to adjust
the path that the java compiler emits for error messages.
For that the JavaParser needs to know the source directory, which is
the android package source dir and the build directory. The
AndroidDeployQtStep thus needs more information then just the
input json file and now stores the path to the .pro file to both
retrieve the input file and the android package source directory.
Task-number: QTCREATORBUG-10904
Change-Id: Ib5141b35b610bc2eee568a096fc5e930f9eb2e47
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Fixes the inconsistent state from
Task-number: QTCREATORBUG-10710
Change-Id: Ifabb1eef4b81e6d33244fd7af8becc453dd66669
Reviewed-by: Daniel Teske <daniel.teske@digia.com>