I have set the project to run QML with C++ having slots communication. Now I am stumbled with the message:
void QDeclarativeView::continueExecute()):
file:///data/data/org.qtproject.example.input/files/Input.qml: File not found
I searched around and checked a similar problem, thus I followed that suggestion, changing my project file as follows:
QT += qml quick sensors xml
QT += declarative
SOURCES += \
main.cpp
OTHER_FILES += \
Input.qml
HEADERS += \
Input.h
RESOURCES += \
Input.qrc
# Required for deployment (?) :
QML_FILES.source = qml
QML_FILES.target = .
DEPLOYMENTFOLDERS += QML_FILES
# Required for deployment too (?) :
include(qmlapplicationviewer/qmlapplicationviewer.pri)
qtcAddDeployment()
While adding this hack to the project file seems to work for Symbian and Harmattan, for Android the last two lines doesn't fix the problem, as the compiler gives the messages:
./input/qmlapplicationviewer/qmlapplicationviewer.pri:-1: error: No such file or directory
./input.pro:22: 'qtcAddDeployment' is not a recognized test function.
Even for Qt5 should we get worried about the target, even if when we defined the project we already set it for Android device?
So, could someone have any suggestion on how to get the QML deployed to Android device? Maybe some equivalent hack that will do the same magic that worked for Symbian but also could work for Android?
Try to downgrade your Android target from API 19 to 17. Apparently the API 19 is not working properly with Qt 5 for Android yet.
Using qtcAddDeployment and qmlapplicationviewer.pri might also solve your issue. But before going into that direction, you should have a close look in the article from Qt Blog on Android Deployment in Qt 5.2.
Related
Protobuf is a very widely used library, so I want to use it in Flutter's C++ code to serialize and deserialize my data. However, I find that compiling and linking the protobuf library is not a trivial task... I failed many times before finding out the correct solution, so I want to share it here using Q&A style.
Preparation
Firstly, of course, you need to generate your protobuf files. This is out the scope of this tutorial, so you can look at the official guide. Suppose you already have hello.pb.h and hello.pb.cc generated.
iOS
Add the following to your xxx.podspec, if you are developing a package/plugin that uses C++ code which needs protobuf. If it is your may code that needs protobuf, things are also similar.
Pod::Spec.new do |s|
...normal things...
s.pod_target_xcconfig = {
'HEADER_SEARCH_PATHS' => '$(SRCROOT)/Protobuf-C++/src',
}
s.dependency 'Protobuf-C++', '~> 3.18.0'
end
In addition, you need to add the following in your main project's Podfile. For example, if you are developing a package that is used by 10 projects, each of them needs to add the following section.
post_install do |installer|
...normal things...
installer.pods_project.targets.each do |target|
# print "target=", target, "\n"
if target.name == "Protobuf-C++"
target.build_configurations.each do |config|
config.build_settings['HEADER_SEARCH_PATHS'] = '$(SRCROOT)/Protobuf-C++/src'
end
end
end
end
Then clean and build the project and enjoy!
Remark: Why I need to hack the HEADER_SEARCH_PATHS: Originally it errors and says that protobuf headers cannot be found. This solution suggests that we add the paths manually by hand after each pod install. Moreover, this improved solution suggests that we can automate the process by adding a few lines of code. That is what we did above.
The alternative way
This link works pretty well basically. Although it is under the SDK tutorial of Cardboard, this webpage talks about almost nothing about Cardboard-specific things but only protobuf. Thus, feel free to follow it. After all steps except the last step ("copying files"), you will get: include/google/* and lib/libprotobuf-lite.a.
Before getting started, do not forget make distclean to clean everything (if you have already done something).
Remark 1: If you see errors when linking, saying "Undefined symbols" and "ld: warning: ignoring file", you may follow this link to solve it.
Remark 2: That tutorial only creates libprotobuf-lite.a. If you need libprotobuf.a, it can be done by analogy: lipo $build_dir/arch/arm64/lib/libprotobuf.a $build_dir/arch/armv7/lib/libprotobuf.a -create -output $build_dir/lib/libprotobuf.a.
Then, you can put the .a and the headers into your ios xcode project. I have not tried this yet, because I use the approach above.
Android
Get lib and headers
It is a little bit more complex than iOS.
Before getting started, do not forget make distclean to clean everything (if you have already done something).
Firstly, follow the same link as the approach to generating your own .a and headers in iOS to do git clone, git checkout, git submodule and ./autogen.sh, but stop there and do not continue.
Next, you need to follow this answer to hack the code a little bit - otherwise the compilation will fail. Please refer to the link to do a patch using ltmain.sh.patch. (As for the fuse-ld flag I already do it, so no need for you to do anything.)
Now comes the configure and compile, which goes as follows.
export NDKDIR=/Users/tom/Library/Android/sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/darwin-x86_64
export SYSROOT=$NDKDIR/sysroot
./configure \
--prefix=/Users/tom/RefCode/libprotobuf/android \
--host=arm-linux-androideabi \
--with-sysroot="${SYSROOT}" \
--enable-shared \
--enable-cross-compile \
--with-protoc=protoc \
"CC=$NDKDIR/bin/armv7a-linux-androideabi26-clang" \
CFLAGS="-fPIC -fuse-ld=bfd -march=armv7-a -D__ANDROID_API__=26" \
"CXX=$NDKDIR/bin/armv7a-linux-androideabi26-clang++" \
CXXFLAGS="-fPIC -fuse-ld=bfd -frtti -fexceptions -march=armv7-a -D__ANDROID_API__=26" \
"RANLIB=$NDKDIR/bin/x86_64-linux-android-ranlib" \
"C_COMPILER_RANLIB=$NDKDIR/bin/x86_64-linux-android-ranlib" \
"CXX_COMPILER_RANLIB=$NDKDIR/bin/x86_64-linux-android-ranlib" \
"AR=$NDKDIR/bin/x86_64-linux-android-ar" \
LIBS="-llog -lz -lc++_static";
make -j8 && make install
Remark: The commands above is similar but not equal to this post, because the NDK standalone toolchain used in that post is deprecated already. Of course, you may need to change your versions, such as the path to your own ndk, your ndk version, etc.
Remark: You may also need to know the naming conventions used above. For example, why sometimes it is llvm, why sometimes it is darwin, and why armv7a. They are described in detail in the official guide.
Remark: this link is also useful when you face problem of libprotobuf.a: no archive symbol table (run ranlib) when compiling your android app using Gradle.
Remark: Without -fPIC, errors like requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC will occur. So I followed this link to address it.
Remark: If you see errors such as error: undefined reference to 'stderr', you may need to make your minSdkVersion bigger, such as changing to 23. ref
Remark: After changing things, multiple cleaning may be needed. For example, gradle sync, gradle clean, make distclean, etc.
Similar to the guide, the next step is make -j8 and then make install. Then you are done and will see some libs like libprotobuf-lite.a as well as include headers.
Use it in your project
Add the following to CMakeLists.txt:
set(OPENCV_BASE_DIR "/some/absolute/path/to/your/base/dir/that/has/built/just/now")
message("PROTOBUF_BASE_DIR: ${PROTOBUF_BASE_DIR}")
set(PROTOBUF_INCLUDE_DIR "${PROTOBUF_BASE_DIR}/include/")
set(PROTOBUF_STATIC_LIB_DIR "${PROTOBUF_BASE_DIR}/lib")
if (NOT EXISTS ${PROTOBUF_INCLUDE_DIR})
message(FATAL_ERROR "PROTOBUF_INCLUDE_DIR=${PROTOBUF_INCLUDE_DIR} does not exist - have you provided the correct PROTOBUF_BASE_DIR=${PROTOBUF_BASE_DIR}")
endif ()
include_directories(${PROTOBUF_INCLUDE_DIR})
add_library(protobuf-lite STATIC IMPORTED)
set_target_properties(protobuf-lite PROPERTIES IMPORTED_LOCATION ${PROTOBUF_STATIC_LIB_DIR}/libprotobuf-lite.a)
add_library(protobuf STATIC IMPORTED)
set_target_properties(protobuf PROPERTIES IMPORTED_LOCATION ${PROTOBUF_STATIC_LIB_DIR}/libprotobuf.a)
target_link_libraries(yourapp
...others...
protobuf
)
Since I only build for armv7 instead of armv8 in the code above, we can add an abi filter as follows. Or, alternatively, you can also build for armv8 and merge them into a fat lib just like what we have done in ios.
build.gradle:
android {
defaultConfig {
externalNativeBuild {
cmake {
abiFilters 'armeabi-v7a'
}
}
}
}
Bonus: MacOS
Get lib and headers
What if you want to also use your C++ code (with protobuf) on your mac computer?
Before getting started, do not forget make distclean to clean everything (if you have already done something).
Similar to this link, you only need to change your ./configure to:
./configure CC=clang CXX="clang++ -std=c++11 -stdlib=libc++" CXXFLAGS="-O3" --disable-shared
and the other things are remained almost the same as the guide, such as downloading, configuring, make and finally sudo make install (notice you need sudo here).
You will see headers in your system's include directory and libs in your system's lib folder.
Use it in your project
If you are using CMake, it is mostly standard. Firstly, add path/to/your/hello.pb.cc into your add_executable. Secondly, add /usr/local/lib/libprotobuf.a to your target_link_libraries. Full example:
add_executable(app
./main.cpp
path/to/your/hello.pb.cc
... others ...
)
target_link_libraries(app
/usr/local/lib/libprotobuf.a
... others ...
)
Remark: libprotobuf-lite.a sometimes does not suffice, so you need to link with the big lib instead of the lite lib.
How do I compile and use Boost for the Android NDK? I've tried everything I've found online, from Boost for Android to compiling it myself with the bjam file. However, I do not succeed. When I try compiling it with bjam, I get the following error:
error: toolset gcc initialization:
error: version 'androidR10e' requested but 'g++-androidR10e' not found and version '4.2.1' of default 'g++' does not match
error: initialized from /path/to/android-ndk-r10e/sources/boost/tools/build/v2/user-config.jam:86
Has anyone successfully used Boost with Android NDK R10e?
And when I can compile it, how should I do to use it in my Android app project?
We managed to compile it for NDKr10d. It should be the same for NDKr10e.
The project-config.bjam should point to the gcc compiler from the NDK. Ours looks like this :
import option ;
using gcc : arm : D:\\android\\ndk\\toolchains\\arm-linux-androideabi-4.9\\prebuilt\\windows-x86_64\\bin\\arm-linux-androideabi-g++.exe ;
option.set keep-going : false ;
Then just compile with b2, telling paths to android includes :
b2 --reconfigure <your options>
toolset=gcc-arm
include=<ndk folder>\sources\cxx-stl\gnu-libstdc++\4.9\include
include=<ndk folder>\sources\cxx-stl\gnu-libstdc++\4.9\libs\<target platform>\include
include=<ndk folder>\platforms\<android api version>\arch-arm\usr\include
install --libdir=stage\lib\<target platform>
We're about to move to ndkr10e. Could you tell if boost still works with it ? :)
The simplest way would be to use CrystaX NDK, which contains already built and ready-to-use Boost libraries. And here are examples how to use Boost with CrystaX NDK: 1, 2
Following the boost directions, I was able to build boost 1.60 with NDKr10e on Ubuntu 12.04 (although I suspect very little depends on the host system). Here are my notes:
get and unpack boost source tarball (i used 1.60): boost_1_60_0.tar.bz2
moskewcz#maaya:/scratch/moskewcz/android/src$ ll
total 74M
drwx------ 10 moskewcz moskewcz 4.0K Mar 9 14:14 boost_1_60_0
-rw-rw-r-- 1 moskewcz moskewcz 74M Jan 5 11:15 boost_1_60_0.tar.bz2
follow boost instructions in getting started on unix "Build Custom Binaries" section
use a fresh, empty root to install b2 i.e. /scratch/boost-build-root; use usr as prefix; again following the boost instructions:
moskewcz#maaya:/scratch/moskewcz/android/src/boost_1_60_0/tools/build$ ./bootstrap.sh
moskewcz#maaya:/scratch/moskewcz/android/src/boost_1_60_0/tools/build$ ./b2 install --prefix=/scratch/moskewcz/android/boost-build-root/usr
put b2 in path (again as per instructions)
export PATH=/scratch/moskewcz/android/boost-build-root/usr/bin:$PATH
in some jamfile (i had no ~/user-config.jam, so i created one and used that, maybe there's a better choice of jamfile to create/edit) add some jam-code (?) to define a gcc version (toolset) pointing to a g++ from a standalone toolchain. note that this is a toolchain created with the NDK in the normal fashion following its 'create a standalone toolchain' directions. i am NOT pointing to a g++ inside the NDK itself (that may or may not work, i dunno):
import option ;
using gcc : arm_linux_android_4.9 : /scratch/android-stc/bin/aarch64-linux-android-g++ ;
option.set keep-going : false ;
go to boost project root and build, mostly as per directions. --build-dir may be optional? also added -j8 to do || build
moskewcz#maaya:/scratch/moskewcz/android/src/boost_1_60_0$ b2 -j8 --build-dir=bin.v2 toolset=gcc-arm_linux_android_4.9 stage
note that this tries to build both static and shared libs by default, but building shared libs fails due to android not having librt.so -- according to my research, people claim that under android (some of?) the functionality of librt.so is inside libc.so -- so it may be okay to simply remove -lrt from the linking steps in order to build shared libs for android. i did not attempt this. see:
https://code.google.com/p/android/issues/detail?id=5730
Building Boost for Android with error "cannot find -lrt"
I only managed to build with 10d. Cross compiling Linux->Android using Boost for Android worked straight away with that.
To download a slightly outdated ndk, as not all ndk are immediately supported by Boost for Android, you can use this guide: Where do I find old versions of Android NDK?
Note: I also wanted to specify the toolchain. I had to do it in 2 places:
In build-android.sh, just after the line mentioned here above:
TOOLCHAIN=${TOOLCHAIN:-arm-linux-androideabi-4.9}
In the command line
bash build-android.sh [ndk location] --toolchain=arm-linux-androideabi-4.9
In fact, it worked better when I specified exactly which boost components I wanted with --with-libraries=[comma separated list].
If instead I would build everything, I would get:
...failed updating 38 targets...
...skipped 6 targets...
...updated 10568 targets...
ERROR: Failed to build boost for android!
Done!
Here: http://silverglint.com/boost-for-android/ you can find a simple and painless new way to build a modern (eg 1.64.0) version of boost for android.
Works with clang and gcc.
Also included is a sample app that shows you how to use the boost binaries thus built.
I compiled the Cocos2d-js 'Hello World'-project for Android and try to run it on Genymotion (Android emulator on x86).
I already tried adding :
APP_ABI := armeabi armeabi-v7a x86
to Application.mk , which makes the apk 3 times bigger, but when I run the app in Genymotion it immediately says "HelloWorld has stopped".
The same apk runs fine on a real Android device.
Any ideas ?
UPDATE:
The sample JS-MoonWarriors runs fine on Genymotion (with ARM-translation installed), so I guess it has nothing to do with x86. The sample JS-Tests however does not work (same error '... has stopped').
Solved it with the help from the following link :
http://discuss.cocos2d-x.org/t/cocos2d-x-with-genymotion/9476/2
In the file Cocos2dxActivity.java is a function that checks if it runs on the default Android emulator.
Change this function to also include Genymotion (and Adobe VirtualBox) :
isEmulator = product.equals("sdk") ||
product.contains("_sdk") ||
product.contains("sdk_") ||
product.contains("vbox");
Also, you'll have to make sure that the ARM-translation package is installed in Genymotion, or use the APP_ABI trick in the question.
i Solved it too ... and there's two things you should do to make it work:
First search your cocos game project on a file named Cocos2dxActivity.java then open it with notepad and scroll down to the bottom of the file then you should find a static function with a line like this:
isEmulator = product.equals("sdk") || product.contains("_sdk") || product.contains("sdk_");
which needs to be changed to this:
isEmulator = product.equals("sdk") || product.contains("_sdk") || product.contains("sdk_") || product.contains("vbox");
Second search your cocos game project again for another file called Application.mk and like the usual open it with notepad and under these tow lines:
# Uncomment this line to compile to armeabi-v7a, your application will run faster but support less devices
#APP_ABI := armeabi-v7a
add another line just beneath them :
APP_ABI := armeabi x86
another thing you should consider is the line you just add should be exactly as i wrote it and if you just try this :
APP_ABI := Armeabi x86 (Wrong ... it wont work just because of the capital A)
and by the way i am using Cocos code IDE 1.2 to package my apk files with framework v3.7 and android-ndk-r10c And the SDK as the adt-bundle-windows-x86_64-20140702
and one more thing ... you have to install Genymotion-ARM-Translation in your emulator with Gapps in order for this to work.
PS: if you don't find any of the files then you need to recreate your project and with add native code to the project checked in.
I am trying to use boost library with Android ndk in Eclipse with Windows. I tried to follow this tutorial
I am stuck in the step with "bjam" command in cygwin.
bjam --without-python --without-serialization toolset=gcc-android4.4.3 link=static runtime-link=static target-os=linux --stagedir=android
Error: bjam command not found.
What is bjam? Also I used the boost 1.53 along ndk r8e. Can someone help me with this please?
Android NDK is no longer dependent on Cygwin, so you can build Boost with the NDK from within Windows command prompt (cmd).
In order to make Boost.Build find the NDK, edit boost\tools\build\v2\user-config.jam file and append the following text:
import os ;
androidNDKRoot = C:/android-ndk-r8e ; # put the relevant path
using gcc : android :
$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-g++ :
<compileflags>--sysroot=$(androidNDKRoot)/platforms/android-9/arch-arm
<compileflags>-mthumb
<compileflags>-Os
<compileflags>-fno-strict-aliasing
<compileflags>-O2
<compileflags>-DNDEBUG
<compileflags>-g
<compileflags>-lstdc++
<compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.7/include
<compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/include
<compileflags>-D__GLIBC__
<compileflags>-D_GLIBCXX__PTHREADS
<compileflags>-D__arm__
<compileflags>-D_REENTRANT
<archiver>$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-ar
<ranlib>$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-ranlib
;
Certainly, instead of c:/android-ndk-r8e you have to put the right location of the NDK on your PC.
Besides, you can select more recent platform API, instead of android-9.
Also note that the NDK supplies several tool-chains, and the above settings point to gcc-4.7. If you prefer to build boost with some other tool-chain, change arm-linux-androideabi-4.7 to the relevant path.
After you've put the configuration in user-config.jam, open cmd, cd to the directory where Boost resides, and invoke bootstrap. Then invoke b2 like this (for example):
b2 --without-python --without-serialization threading=multi link=static runtime-link=static toolset=gcc-android target-os=linux threadapi=pthread --stagedir=android stage
UPDATE: As of 11/2015, older NDK toolchains seem to have issues with the newer Boost versions, causing compiler crash, so consider using a more recent compiler. To do this, just change every 4.7 occurrence in the above script to 4.9. Also, it's worth compiling with a more recent Android API (eg. andoroid-9 -> andoroid-16 or so).
I've downloaded Android source code. Now I want to make it for my own device (LG GT540). I heard that you need to create some 'Device configuration' for that. Although several developers have already created device configurations for my device, but I want to create my own, just for learning.I saw a lot of files like BoardConfig.mk, AndroidProducts.mk, etc. But don't know what they do. Besides they contain a lot of configurations. Over that, there's not a good documentation for that.Can anyone experienced with Android porting and device configurations help me?
Right... So you want to build your own device tree, read on.
Disclaimer: this is by no means complete, and there will be omissions as have explained all this top of my head and copied pasted certain bits that I have here on my own device tree.
The device tree, for example, /device/lg/gt540would consist of the following make files:
Android.mk - this will tell the build system to include and to build sources specifically for your device. See below, for an example. This is dependant on the device and hardware, you could have libsensors, liblights, libcamera subdirectories under the example device tree, i.e. /device/lg/gt540/libsensors, /device/lg/gt540/liblights, /device/lg/gt540/libcamera etc.
AndroidBoard.mk - this is for the kernel, the build system uses that to drop the kernel image in place (more about this in a few minutes)
AndroidProducts.mk - specifies the appropriate device's make file, to use for building. i.e. /device/lg/gt540/device_gt540.mk, this is specific also.
device_xxxxx.mk - specifies the properties and extras to copy over into the final output, in this case, it could be for example, device_gt540.mk
BoardConfig.mk - This is the meat of it all, this is where compiler conditional flags are set, partition layouts, boot addresses, ramdisk size, and so on.
Lets peek into each of those to give a glance as to where it all fits in.
Android.mk:
ifeq ($(TARGET_BOOTLOADER_BOARD_NAME),xxxxx)
include $(call all-named-subdir-makefiles, recovery libsensors liblights libcamera ....)
endif
This is how the build will use that to build recovery, sensors, lights and camera (of course there will be more), its saying 'Yo Builder, go into each of the directories specified, and build the respective sources plskthxbai'
AndroidBoard.mk:
LOCAL_PATH := device/lg/gt540/
#
# Boot files
#
TARGET_PREBUILT_KERNEL := $(LOCAL_PATH)/kernel
file := $(INSTALLED_KERNEL_TARGET)
ALL_PREBUILT += $(file)
$(file): $(TARGET_PREBUILT_KERNEL) | $(ACP)
$(transform-prebuilt-to-target)
Now this, is telling the build system, to be able to drop this kernel into the out/target/product/lg/gt540 (notice the correlation with the device tree directory?)
AndroidProducts.mk:
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/device_gt540.mk
Its telling the build as in 'Yo Builder, read that device make file please and process it upon completion of build.'
*device_xxxxx.mk: (for this example, device_gt540.mk) *
PRODUCT_NAME := lg_gt540
PRODUCT_DEVICE := gt540
PRODUCT_MODEL := LG GT 540
PRODUCT_COPY_FILES += \
... specific ...
PRODUCT_PROPERTY_OVERRIDES := \
ro.com.android.dateformat=dd-MM-yyyy \
... more stuff ...
This is where all the specifics for the device such as drivers, proprietary libraries, supporting scripts specifically for the device, gets copied over to out/target/product/lg/gt540/system/ in this case. Notice how the overrides for the properties, these end up in the build.prop found in the root of the /system of the Android ROM.
BoardConfig.mk:
LOCAL_PATH:= $(call my-dir)
TARGET_NO_BOOTLOADER := true
TARGET_PREBUILT_KERNEL := device/lg/gt540/kernel
TARGET_PREBUILT_RECOVERY_KERNEL := device/lg/gt540/recovery_kernel
# This will vary from device!
TARGET_BOARD_PLATFORM := msm7k
TARGET_ARCH_VARIANT := armv6-vfp
TARGET_CPU_ABI := armeabi
TARGET_CPU_ABI := armeabi-v6l
TARGET_CPU_ABI2 := armeabi
# OpenGL drivers config file path
BOARD_EGL_CFG := device/lg/gt540/egl.cfg
# Dependant, not to be taken literally!
BOARD_GLOBAL_CFLAGS += -DHAVE_FM_RADIO
# Dependant, not to be taken literally!
BOARD_KERNEL_BASE := 0x02600000
# this will be device specific, and by doing cat /proc/mtd will give you the correct sizes
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00480000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00480000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x0cf80000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x0d020000
BOARD_FLASH_BLOCK_SIZE := 131072
That is an excerpt, notice how we specify kernel's base address, this is how the boot.img gets generated after compilation is done and yet again, gets dropped into out/target/product/lg/gt540/boot.img. Also, more importantly, we're telling the build system to use the target platform for cross-compiling the sources (*TARGET_BOARD_PLATFORM*/*TARGET_CPU_ABI*) There will be more information in there such as conditional flags to pass to the compiler, for an example. we specified the directive HAVE_FM_RADIO to tell it, when it comes to handling the source for the FM radio system, to conditionally compile parts of the source. Again, this is hardware specific and mileage will vary, also this applies to the address for boot. In a nutshell, this is saying 'Yo Builder, read the damn variables and remember them and apply them when cross-compiling those source files!'
Now that the internals of each of those Android build make-files are shown.
Now, onto the vendor/ part of it, in AOSP, simply, once again, correlation and corresponds with the device/ tree, as in continuing with this example, vendor/lg/gt540/ which gets picked up by the lunch. There's more make files in there but the general consensus is there's a directory called proprietary which contains the proprietary libs (due to close-source etc) that gets copied over. The copying over of the libraries gets specified in the file device-vendor-blobs.mk, in this case, gt540-vendor-blobs.mk.
When the magic happens by doing the following:
. build/envsetup.sh
This is reading in the entire entries found in each of the device/ subdirectories and "remembers them", so the build system knows what type of target is used etc.
When the . lunch gets invoked, a menu appears prompting to pick the device that is required to build. Now the last and final step to do the build...
make -j5 > buildlog.log 2>&1
I run multitail on another terminal and monitor the buildlog.log file to check and make sure its building.
This last step will depend on how many cores you have (n cores + 1 as a rule) and it takes a while to build, GB build takes 40mins on my laptop running Arch Linux 64bit, ICS build takes about 2hrs 30 mins. So mileage will vary on what type of horsepower your machine has.
When the build is done, a little bell goes off and at the bottom of the said log file, I see this:
Combining NOTICE files: out/target/product/xxxxx/obj/NOTICE.html
Target system fs image: out/target/product/xxxxx/obj/PACKAGING/systemimage_intermediates/system.img
Install system fs image: out/target/product/xxxxx/system.img
out/target/product/xxxx/system.img+ total size is 108776448
As matter of interest JBQ (Jean Baptiste Queru - the 'boss' for managing/distributing the source from Google), his build step is this...
make -j32
Yup! 32 cores! That..... is pretty powerful.
There is some information here: http://elinux.org/Android_Device
An excellent resource for anyone building Android for a device is here:
http://com.odroid.com/sigong/nf_file_board/nfile_board_view.php?bid=98
(A Practical Real-World Approach To Android Platform Development In ODROID)
Though some of the stuff in there is particular to the ODROID board, it still offers great insight into the inner workings of Android and the necessary customization for a new board.
If you're looking to get into the hardware side of things probably the single most informative resource I've found has been:
http://source.android.com/compatibility/overview.html
Read through the documentation they wrote for manufacturers looking to build android devices, it's the most thorough/complete reference you will find.