I am building an application for Android and iOS using Titanium SDK 3.2.2GA which is free. I am using Titanium.Media.AudioPlayer for the development of the stuff related to audio in my application but this audio player provided by titanium is kind of incomplete for example, duration is not available in iOS and Android but the property exists.
So in order to add the functionality which is not currently present in this library, I edited the Titanium SDK for iOS from the path (Library/Application\ Support/Titanium /mobilesdk/osx/3.2.2.GA /iphone/Classes) but I am stuck when it comes to Android because the Android folder contains the precompiled classes in the form of .class files.
So, I was just wondering if anyone has a solution for it. All I want is to implement the fix mentioned in the following commit, to my existing Titanium SDK but when I goto (Library/Application\ Support/Titanium /mobilesdk/osx/3.2.2.GA /android/modules/..) all the files inside it are pre-compiled .class files.
TIA.
The 3.2.2.GA version of Titanium SDK is very old. As Shoaib mentioned above you should use a more recent version, for instance: 5.2.2.GA or the current stable 5.3.1.GA. However, if you need to use the 3.2.2.GA version for some special requirement, you must download the source code of SDK version, make the changes (apply the commit) and compile it, instructions available in: https://wiki.appcelerator.org/display/guides2/Building+the+Titanium+SDK+From+Source
Related
First some premises:
Android applications make use of Android SDK API classes.
A class definition is some code or parts of code, which gets compiled into machine code/bytecode.
I assume that all (or most of) the classes/packages that make up Android SDK API are listed under:https://developer.android.com/reference/packages.html
https://developer.android.com/reference/classes.htmlWhich is a lot!
Now the question:
Where do these codes/data reside? Are they compiled along with the application code into the APK file or do they exist inside the Android OS on a device, in which case the application should dynamic-link to them?
If they're present on the device, then what difference does it make to compile the application with newer Android SDK versions (per compileSdkVersion in Android Studio for example)?
Let's say the "Android SDK Build-Tools" (which is not the same as "SDK Platform" (according to "SDK Manager" window!) and has its own versioning) takes care of compiling your code and therefore newer version mean better bytecode optimization and faster JAVA -> DEX translation!?
Does "SDK Platform" which you compile your android application against and set it's version with compileSdkVersion keyword, contain solely class declarations and reference-symbols?!
What about Google APIs (e.g. Google Maps API)?
What about Android Support Library?
The Android SDK code is baked into the device, and is not part of your apk.
Stuff you need to include via gradle compile gets into your apk (e.g. Support Library)
The Android core SDK classes are provided by the Android runtime instance that runs per App, you might call it the Android virtual machine if you will. When your App needs to load a specific Android framework class, a Classloader will load it for you in a process similar to dynamic-link as you mentioned.
There is not much you can do to change the version of the framework running on the device. However, the reason you need to specify the different minimumSdk and targetSdk, is for the lint/compiler tools to indicate you what functions/apis might not be present at runtime in specific framework versions. Based on this information you provide wrappers/adapters or simply if/else logic to provide an alternative functionality or simply to avoid a ClassNotDefinedException or MethodNotFoundException at runtime. It is basically a dev tool to help you visualize what could be wrong with other versions different from the one you are compiling against.
Certainly when you compile it, it produces references-symbols in a similar way as if reference an included library. The VM Classloader will resolve the actual file to load at runtime. Not quite sure how Google Apis work but it might be provided as well, in the case of the support library it gets included as far as I know.
I download the android source, changed the framework layer such that I added new methods to it.
I compiled the code ( using make command ), and compiled the sdk using: make sdk.
After that I followed google's instructions here here
and successfully build the zip file containing the eclipse plugins. I am lost know and dont know how to exactly continue.
My final goal is to create an android application which uses the new methods I added to the sdk.
I'm no expert in modifying the Android source itself, but if you're hoping to create an app that uses methods that you've added to the SDK, then at the very least beyond compiling the SDK and Eclipse plugins, you're going to have to:
Actually install the Eclipse plugins in Eclipse
Create a ROM for your device that uses your version of the SDK
Actually install that ROM on your device
Write and install your app
I've been using an eclipse plugin that allows me to view android source code for up to android 2.2. I recently cleared my eclipse folder and copied a fresh instance, thereby loosing the plug-in. I don't seem to remember what the plug-in was called and where I installed it from.
I'm not looking for downloading and building the entire source tree of android. This plug-in would allow me to step into android sources when I wanted.
Does anyone have a link to this plug-in location?
You probably mean adt-addons project. The direct link to plugin you're searching is: http://adt-addons.googlecode.com/svn/trunk/source/com.android.ide.eclipse.source.update/
In the properties of your android-ver.jar you can set the location of the sources. I think it is enough to download only frameworks project of the AOSP to attach it as a source of a android.jar library.
I need to edit the original Android Apps from packages
in terms make my own distro/mod..
I want to make changes to the In Call screen, lock screen, contacts, calendar etc..
I understand that for doing this I will have to build everything from
source,
however I need to edit the source and to do so I need to open the OS provided apps as
eclipse projects,
When I did I saw that there are
missing imports which are hidden in the SDK (or missing)
hidden parameters within the classes..
I don't want to use reflection since the whole code is here and
available, but how do you build a platform development kit..
or PDK ?:)
Can any one help?
You start by reading the documentation.
EDIT:
If you are trying to download some single project from AOSP and compile it using the SDK, odds are very strong that it will not work, and that you will encounter problems like the ones you cite. You do not build Android by building individual apps; you build Android ("my own distro/mod") by building the entire firmware. Most AOSP applications are not designed to be compiled by the SDK, but need the whole firmware.
Please check Using eclipse to browse and edit AOSP. You can atleast edit your code using eclipse, but you will have to use AOSP build system to build your distro.
You might also check Debugging Android Java Framework services as that would help debug your changes.
Just open Eclipse,
then go to "window" +"preferences" +"android"
there you will get sdk location,then give the appropriate path of the android sdk for proper run...
I did a git on the com.android.music app and then created a project in eclipse from existing code. I chose 2.1 as the sdk target but I am getting errors trying to compile.
Is the music app referencing code that is not part of the 2.1 sdk? Can someone list the steps for how to compile in eclipse?
Description Resource Path Location Type
ArrayListCursor cannot be resolved to a type PlaylistBrowserActivity.java Music/src/com/android/music line 529 Java Problem
MediaFile cannot be resolved AlbumBrowserActivity.java
Is the music app referencing code that
is not part of the 2.1 sdk?
Absolutely. Most of the built-in apps for Android were created before there was an SDK. You will not be able to build them in isolation from the rest of the firmware without substantial work. Work which, BTW, would be welcome contributions back to the Android open source project, if you were so inclined... :-)
Check the applications manifest file. It will contain an attribute stating which version of the SDK the application was built with.