Titanium should be using the latest stable Android SDK and NDK.
The Titanium environment seems to have some kind of implicit dependencies on building with the 2.2 SDK (API 8). The latest is 4.2.2 (API 17). I've been doing lots of fresh installs on Mac, Windows, and Linux recently. It seems that I am unable to build a simple Single Window template project without installing the 2.2 SDK. Also, using ant to build an Android Ti module, I am getting a complaint about 'No android-10' or 'android-2.3.3' in the Android SDK in the 'docgen' phase which I think is also coming from Titanium's build scripts.
"Best practices" for Android are to use/build the latest tools/SDK/NDK and set backwards compatibility targets to the lowest supported version you want to handle. This follows the Mac/iOS model which also expects you to build with the latest SDK and set minimum deployment versions independently.
While Android is quite terrible in their messaging about this, this is how things should be done. There are several key reasons that demonstrate why it needs to be done this way:
- For module writers (like myself), we need the latest APIs available which is a problem since Titanium's build process is automatically invoking the wrong SDK on my behalf. I understand it is my responsibility to handle/test backwards compatibility, but you do me no favors by locking me to the oldest SDK. For example, OpenSL ES is the only sane path forward on trying to get low-latency audio on Android. It is only available starting in API 9 (2.3), and newer APIs aren't available until API 11 or 14. But if I write everything against 2.2, I cannot give any newer devices better audio. Furthermore, there were actually bugs on 2.3 devices where if you used the legacy APIs, things broke.
- Android has dynamic launchtime/runtime behaviors based on how the apk's were compiled. In Android 4.0 for "Project Butter", GPU acceleration for native views is enabled by default, generally yielding better responsiveness for UI. However, if Android detects a legacy binary, it will avoid running this path of code and instead try to run with hardware acceleration off. By building against the 2.2 SDK, new projects look like legacy binaries to the system. I know from experience from the Apple/iOS side that legacy binaries on new versions of the OS are actually not the heavily tested path and I have first hand experienced very painful, hard-to-track down bugs that were solely introduced because of building against a legacy SDK and hitting special code paths that are not as well tested.
- Downloading the Android SDK (ADT bundle) now always includes the latest SDK. Links to the older NDKs cannot be found from the main Android page. Users are not really expected to have to download old versions of either.
- It is confusing for new users to know they have to download the 2.2 SDK (API 8). Why not the latest? Why not the oldest? Why not the market share dominate version (e.g. 2.3)?
- Since the latest is installed when you first download, it's also a lot of wasted disk space to download older ones. I like to set up virtual machines for build environments (automation). So it adds up after awhile.
Ideally, you would look for the latest SDK installed on a user's system and use it, unless they provide some hard override.
Slightly less ideally, you require users to be on the latest SDK if you can't deal with dynamic detection. (Apple does this. We got used to it. It's actually easier in many respects because you get to say 'no' instead of test every permutation.)