How can I install a debug build of Android 5.0 AOSP on my Nexus Device? Where do I get the debug build? I tried Googling but still can't find step-by-step instructions to download and install debug build.
You would need to pull down AOSP in source form and build it for the desired Nexus target (assuming it is supported). Start here:
http://source.android.com/source/requirements.html
Once you are setup, look into the details of building for a specific device, found here:
http://source.android.com/source/running.html
Note that if you load your device with a custom image you'll be voiding any warranty, etc. Also, you probably don't want a full debug build, it will be very large and most likely not loadable on the device. You'll want an "eng" build, which has a reasonable amount of debug capability in place, even for system processes and frameworks.
Good luck!
Related
Since it's now possible to execute an apk file on windows mobile, is there any way to check if the environment is emulated on windows or not? I want to be aware if the app is executed on windows platform.
Users cannot run arbitrary APKs on Windows. As a developer you will choose to package and publish your APK for Windows. It can call Windows Runtime API or compile in custom checks as needed.
For more information check out the Build session “PROJECT ASTORIA“: Build Great Windows Apps with Your Android Code. You can sign up for the for the Windows Bridge for Android (fka Project Astoria) developer preview at https://dev.windows.com/en-us/uwp-bridges/android
I found the way. You just need to read file /proc/cmdline and look for the hyperv string.
In the AOSP tree are basically 3 generic device types.
List is base path: PRODUCT_DEVICE, PRODUCT_NAME
device/generic/<arch>: <arch>, mini_<arch>
device/generic/qemu: generic_<arch>, qemu_<arch>
device/generic/mini-emulator-<arch>: mini-emulator-<arch>, mini_emulator_<arch>
What are the differences between and uses for mini_, qemu_ and mini_emulator_?
Edit:
After googling a bit I didn't find a detailed explanation, but this blog post pointed out, that there are three more 'products' which are neither specific devices nor generic products: full, aosp and sdk. What do these do exactly?
Edit 2:
Looking into envsetup.sh from different ROMs (aosp, cyanogenmod, aospa) it seems to be possible, to set TARGET_PRODUCT to something like aosp_<arch> or full_<arch>. Is this an alias to one of mini_, qemu_ or mini_emulator_ or does this something else?
So after digging through the android build system a bit more I think I got it now:
The following TARGET_PRODUCTs are allowed:
aosp_ is just an alias for full_. It accepts all architectures (arm, x86, mips, arm64, x86_64 and mips64) and is also used for devices (e.g. aosp_flounder)
full_ is, if no device is specified via aosp_, a full featured build for the emulator. It includes core_. (full without _arch deaults to arm)
sdk_ is just an alias for sdk_phone_. (sdk without _arch defaults to armv7)
sdk_phone_ builds the Android SDK for the specific architecture. It includes core_ too
generic_ is the basic Android platform not specialized for any board. It can build for arm (default if nothing specified), x86 and mips. I don't think this can boot on a device or an emulator.
core_ is the basic configuration for all communication-oriented android devices like phones and tablets.
mini_ somehow extends core_. It seems to be a emulator build using only the basic configuration instead of the full featured build. But I'm not sure with this one.
mini_emulator_ combine mini_ with goldfish and QEMU related files. It seems to be some basic emulator build too.
qemu_ is an absolutely minimal android build for qemu (not the android emulator). It just has the stuff necessary to boot and some command line utilities/libraries and adb.
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
I'm developping a android's aplication using some shared
libraries written by me and compiled with ndk-r5b. The application works,
y and the calls to the libraries works too, but I detected some errors,
segmentations faults, and I need to debug it, but, I don't know how debug
native code from android and I don't know if I can generate core dumps,
as in linux, for debug my libraries.
Any idea?
The ndk comes with ndk-gdb, which supposedly allows you to debug native applications. Also, if you download the whole andriod open source project, they also have some version of gdb used for debugging. Look in the docs/ folder of the ndk to learn about using it. This tutorial might also prove helpful: http://vilimpoc.org/blog/2010/09/23/hello-gdbserver-a-debuggable-jni-example-for-android/
However, as shown in a recent question I asked: Running ndk-gdb with package not found error on motorola phone I still can't get it to work.
Edit: You said in the comments you were using a Samsung Device: Samsung decide to wreck havoc on some of the crucial internals required for native debugging, but it's easily fixable if you have root access to the device. If you use the --verbose flag, you'll probably find that the error is different than that, a package unknown error. That's because it's looking in /data/system/packages.list, but samsung renamed that file to /dbdata/system/packages.list. So if you make a symlink to that file in /data/system/packages.list, (requires root access) it should work. Or at least so claims the ndk mailing list: http://osdir.com/ml/android-ndk/2011-03/msg00036.html