Develop Reference

Cocos2d-js: projects need to be that huge?

I'm trying out cocos2d-js (version 3.0) and even the simplest 'Hello World' project is over 1 gigabyte in size when it is created.
Is this normal? (I have a habit of creating dozens of demo-projects when trying out a new platform, but it looks like I need to get myself a bigger SSD, just for this!)
Also, the size of the apk, when compiled for Android, is about 9 MB. Any ways to reduce this size?

Sadly, yes. I've mentioned this in the community a couple of times to no avail. I believe this files should be referenced/cached in a common location for all projects, but the dev team seems to have other priorities at present.
If you wish to keep your projects you'll be better off heading to their frameworks directory and deleting all folders except cocos2d-html5 (this one should be 5MB only) in there. -
An alternative would be to also delete the cocos2d-html5 folder, place it in a common dir (or use the copy in your install folder) and reference the path properly in your projetc's config file. Keep in mind this option may break code suggesstion/autocomplete in some editors, and throw errors in your webserver when you try to run the project.-
This way, you'll be able to run any of those projects in the browser, and then only add the files neccessary for native compilation in projects you wish to test in the emulator or your device (or compile for publishing). This will sadly take a lot of time to copy and re-generate the files, of course.
As for reducing the size of the .apks... I don't know a way. I know efforts are being made to optimize the binder, and there may be a way to explicitly avoid packaging unused stuff, but I don't know about it.

You can reduce the app size in Cocos2d-js v3.2 released in January. It allows you to exclude the unused modules. Refer to the upgrade guide for more details on how to do this. The minimum apk size for Android is 4.4mb .

Debug Android Native located in dependent eclipse project

(ADK 21, NDK r8d, Eclipse Juno)
[I've built several Android apps so decent experience using ADK/NDK etc]
Eclipse project setup:
- AppProject (android, java, no jni)
- LibProject (android, java, Yes jni)
Previously, all of it was in one project - builds fine, runs fine, and native debugging worked great.
Then I split off the "reusable" portion to make a library of common code to use with multiple "AppProject" application front ends. (Everything still builds, links, packs, and runs okay)
However, when I run "AppProject", I can no longer debug the native library.
What is the solution?
Possible option #1:
- Modify "LibProject" Android.mk to export a PreBuilt that is used by AppProject?
- (I would have all the debug symbols so I'm thinking that would work okay)
Would I need to cnature the AppProject as well? In other words, so it has an Android.mk to import the output .so from LibProject
Possible option #2
- http://stackoverflow.com/a/14344377/735533
- that workaround uses ndk-gdb
- I'm hoping for a solution where I can debug LibProject in Eclipse directly when running AppProject
Is there a better way to debug the native code located in the dependent project "LibProject" when running the main application "AppProject"?
Tia

For those curious ...
I tried prebuilts ...
And it definitely seems the be the way to go (test project setup worked)
But the structure of my codebase is a bit heavy on the native/non-native crosstalk and didn't want to take the time (yet) to do a proper reorganization at the moment.
However, restructuring as a prebuilt is on my "Important ToDo" list now
Anywhere, here is my solution.
On Linux (unix flavors) ... use links - the sources are linked into each AppProject from LibProject.
Basically the "LibProject" becomes a sort of "template" during development - it is not built or used as a library directly. Rather, each AppProject becomes self-sufficient, standalone, application with the contents of the library project embedded in its own code tree. Best part is native debugging works like a charm again.
Although it sort of defeats the point of making, there are benefits - one common codebase for the "library" portion ... which is really what I desire for the time being.
Also, conversion to use as a true Library dependency by the Application projects for, say, eventual release builds is an easy switch. Once debugged and ready, the Library can be built separately, packed normally with the application "front ends", and upgraded independently of the applications.

Android.mk for LibXtract

Can somebody help me write Android.mk for LibXtract or point me in correct directoin?
Here is source for lib - https://github.com/jamiebullock/LibXtract.git
Or mayby there is a way to use linux generated shared objects in Android?

Especially for bigger established projects, crafting Android.mk files is quite an effort. More so, if you are not familiar with Android NDK build architecture whose understanding requires digging deep into the documentation and Android NDK make files. I would suggest trying to use existing make files by setting CC to point to your NDK tool chain, and CFLAGS += -sysroot $(SYSROOT) where SYSROOT=${NDK_INSTALL_DIR}/platforms/android-<level>/arch-<arch>/ (depending on targeted Android API version and architecture). Even without knowing about your library, I would bet you should have good chance of success this way. Android NDK documentation (${NDK_INSTALL_DIR}/doc/STANDALONE-TOOLCHAIN.html) details the use of independent tool chain and also instructs how to create a standalone tool chain that will not require the use of -sysroot argument to xxx-gcc.
If you decide to use Android.mk instead, you might check existing projects -CSipSimple comes to my mind (PJSIP converted from standard form GNU make files).
Important is to create the shared objects using Android tool chains. It is possible to build them outside of your application source tree, and then just copy the shared objects into the package source libs/<architecture>/ directory.
Integration with your build system depends on details that are not known (including how smooth you desire this whole integration to be e.g. because of other people working with the same project). If you are creating an application from command line, the easiest would be to have GNU make file or shell script in the package root directory ensure libXtract.so and your application package is up-to-date by calling libXtract make file and ant to build and pack your Java application. If you are using ant there should be a way to specify using make to take care of libXtract.so. I am not sure if eclipse is completely relying on ant for building an application to know if this would be enough for enabling complete build by clicking mouse buttons from within eclipse, too.

The answer to this question says you could use cmake script to build Android.mk files - I have not tried this approach.

How do I build the Android SDK with hidden and internal APIs available?

I want to rebuild the Android SDK (or rather only the android.jar) to include hidden and internal APIs.
I could not find any documentation or discussion doing on how to go about this. I have an Ubuntu CyanogenMod build environment already setup that is able to build cm7.
Now, I read that make SDK will build the SDK but I want to build an SDK that includes methods and fields that are marked as hidden using #hide. Is this possible?
What I want to do is make changes to an application that uses hidden API and in order to rebuild it I would like to use the modified SDK.

This is what I always do to use hidden api.
Build the repo or download jars from https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
copy out out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar (better to rename it as something like framework_all.jar)
config your project build path-->libraries --> add this external jars. In Order and Export, move it up and before android.jar

I have done some investigating into this, and my conclusion is simply: This cannot be done without quite a bit of work. Read the rest of this answer for details on what I have found.
android.jar is actually comprised of the "public api" of framework.jar and core.jar which is found in system/frameworks/ on the device. android.jar is a kind of what I would call Java library header, all implementation in the actual byte code are just a throw new RuntimeException("stub");, this allows you to build against android.jar (e.g. in Eclipse), but execution has to be performed on a device or emulator.
The public API of the Android SDK is defined by classes/methods/fields that are not prefixed with the #{hide} javadoc annotation. I.e. everything that is not annotated is included in the SDK.
android.jar is built from the sources located in out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediates which itself is generated by the tool DroidDoc located in build/tools/droiddoc.
DroidDoc is the tool (probably adapted from javadoc, or using javadoc) that generate the actual Android SDK documentation. As a side-effect, and probably because it is already parsing all the javadoc, it also spews out the android stubs which are then compiled into the android.jar which is distributed in the SDK.
So to include the stuff that is hidden you could, if you only want to include specific parts, just remove the #hide annotation and rebuild the SDK.
However if you want to include all the hidden parts things get a lot more complicated. You can modify DroidDoc (the relevant source is in build/tools/droiddoc/src/Stubs.java) such that nothing is detected as hidden. This is quite trivial and I have tried this, however the stubs that is then generated does not compile at all.
My conclusion by now is that this is simply not feasible. The stubs generated if you remove the part of DroidDoc that detect hidden annotations, is simply not compilable, and would require quite a bit of work to compile correctly.
So my answer to your questions is: No, this cannot be done, without doing a lot of work. Sorry.
A side note about the mkstubs tool. mkstubs are used when you build a SDK addon, i.e. the addons you can find in the Android SDK manager from vendors, e.g. Samsung providing you with an additional API for stuff specific to Samsung phones. mkstubs does much the same as the DroidDoc stubs generation process, however it does not use #hide annotations, it uses a .defs file describing which packages/classes/fields to include or exclude from your SDK addon.
However this is all irrelevant to the question, as the Android SDK build does not use the mkstubs tool. (Unfortunately.)

We could reconstruct the *.jar files from the Android platform.
First, connect ADB to your device. Then run:
adb pull /system/framework/core.jar .
adb pull /system/framework/framework.jar .
The core.jar contain the standard Java libraries (java.*) and the framework.jar contain the Android libraries (android.*). This is not usable yet, as the actual files are in DEX format, not JAR format.
We could convert these DEX-formatted *.jars into real JARs using tools such as dex2jar:
dex2jar core.jar
dex2jar framework.jar
Then pull in these jars using "Add External JARs..." (assuming you're using Eclipse ADT)
right click on Project → Properties → Java Build Path → Libraries → Add External JARs... → (Choose the core-dex2jar.jar and framework-dex2jar.jar from above).
This will enable you to use the internal and some Java 7 APIs. (The generated APK, as far as I can see, does not contain any actual code from the JARs.)

You can download the modified android.jar to be used as hidden APIs from this repository. Follow the instructions there.

For Lollipop the flow is little different:
Get /system/framework/arm/boot.oat from lollipop device
Use 'java -jar oat2dex.jar boot boot.oat'
You will get two folders: dex and odex. Go to dex and make 'java -jar dex2jar.jar framework.dex'
Rename resulting framework.jar to .zip, extract and find classes you need
Go to [sdk_path]/platforms/[target_platform] and extract android.jar (first rename it to zip).
Copy files from extracted framework to extracted android.jar. Then compress to zip and rename to .jar :)
ps: probably you need repeat steps 4-6 for 'framework_classes2.dex'

DroidCon 2011
Here Erik Hellman from Sony Ericson explains how to access the hidden Android API's:
http://vimeo.com/30180393
(Hmm link doesn't appear to work).
Goto the DroidCon webpage Day 2 scroll down to Using Hidden APIs 10:15 and you can watch it there.
Links are dieing!
I've found this one: http://skillsmatter.com/podcast/os-mobile-server/hidden-api I don't know, how long it'll be up.
The official APIs in the Android SDK is usually sufficient for most normal applications. However, there are sometimes situations where a developer needs access to the internal system services, APIs and resources that are not published in the official APIs. Fortunately, these APIs are still available through some clever tricks and can often be useful when developing new and innovative solution on top of Android. In this session you will learn how to access and use these hidden and protected APIs, the limitations of their usage and some tips'n'trick on how to use them in a safe and control manner across multiple vendors devices and Android versions. The audience will see several advanced demos that you normally cannot do with Android. Expect a fairly advanced session with lots of insights in the internals of the Android platform.

Try to look at this:
The ultimate target of these articles is to give developers the power of Internal and Hidden APIs without using reflection. If you complete all the steps described in next several parts you will be able to use Internal and Hidden APIs as if they were public open APIs. There will be no need for reflection.
But if you’re using these non-public APIs then you should be aware that your application is at great risk. Basically there are no guarantees that APIs will not be broken with next update to Android OS. There are even no guarantees about consistent behavior across devices from different vendors. You are completely on your own.
There are three scenarios you may want to follow:
Enable both internal and hidden APIs (scenario A)
Enable only hidden API (scenario B)
Enable only internal API (scenario C)
Scenario A is a sum of B and C. Scenario B is the easiest one (requires no eclipse ADT plugin modifications).
Scenario A: read parts 1, 2, 3, 4, 5
Scenario B: read parts 1, 2, 3, 5
Scenario C: read parts 1, 2, 3, 4, 5

I once wrote some Groovy scripts for extracting the java files from a repo checkout from http://source.android.com/ and then compiling them without the need for a full toolchain for compiling all the android sources, including the needed other steps (packaging, generating resources etc).
They can be found here:
https://github.com/thoutbeckers/CollectAndroid
But for sure this will need updating for anything after Gingerbread, mostly by setting the correct directories in "rootdirs" in the config file (CollectConfig.groovy).
At the time I regularly used this for development with all of the hidden API and sources (also problematic at the time) available.
As mentioned elsewhere com/android/internal/** will still be hidden in recent versions of ADT due to the access rule aded.

Long's answer worked for me, but I was still missing some classes I needed, in particular android.provider.Telephony. I was able to add it like this:
Extract the framework.jar file
mkdir /tmp/framework
cp framework.jar /tmp
cd /tmp/framework
jar xvf ../framework.jar
mv android classes
Build the Android repo, which will create the out/target/common/obj/JAVA_LIBRARIES directory
Find where the missing classes are
$ cd /path/to/out/target/common/obj/JAVA_LIBRARIES
$ find . | grep "/Telephony.class"
./telephony-common_intermediates/classes/android/provider/Telephony.class
./android_stubs_current_intermediates/classes/android/provider/Telephony.class
Add the new classes and rebuild the framework JAR file
cd /tmp/framework
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes .
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/telephony-common_intermediates/classes .
cd classes
jar cvf ../framework.jar .
Or you can just be lazy and include all of the classes into one giant jar file:
cd /tmp/framework
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/*/classes .
cd classes
jar cvf ../framework.jar .

I can't comment but this is basically a comment to #KennyTM's (https://stackoverflow.com/a/13550030/2923406) excellent answer:
If you find yourself with the following error in Eclipse:
The type com.android.internal.util.Predicate cannot be resolved. It is indirectly referenced from required .class files
(that is, android.internal.* is not available)
Then one possible solution is to apply the same method for /system/framework/framework2.jar. Using the Android Emulator for SDK19 I have this extra jar. On my HTC One there is even a framework3.jar.

How to integrate Scala into core Android platform?

I am interested in integrating Scala (or some other non-Java JVM-language) into the android platform. I am not referring to writing an android application with Scala, that I did early early on, but actually hooking into the build process that builds the android platform source tree. I imagine this will be a matter of hooking into the makefiles and such. Does anyone have insight into this?
What I have so far:
The platform source treefrom git://android.git.kernel.org/platform/manifest.git built in its virgin form, guided by "[Download and build the Google Android][1]"
build/core/combo/scalac.mk # Configures scala compiler related variables, included by config.mk
Added definitions in build/core/definitions.mk for an all-subdir-scala-files and an all-scala-files-under
Added definition in definitions.mk to build scala files such that they are included in the package
What's left:
Include scala-library.jar
Ensure changes to -bootclasspath has not broken anything
Figure out how to handle case where scala classes depend on java classes and visa versa
Major cleanup of code
Testing!
Figure out what to do (other than just posting them here) with the changes I've made
Looks like I'm almost there!!!
Some notes from the past
Latest: I have found where the Java source files are compiled! In definitions.mk, see 'define transform-java-to-classes.jar'. The latest idea is to write a transform-scala-to-classes definition and then have it store those classes in the directly that gets packaged. I will call transform-scala-to-class right before this step in transform-java-to-classes.jar. Support for eclipse and cygwin will for now be dropped as it clutters up the code with workarounds and therefore increases my chances of failure.
The build process starts out by the root Makefile running build/core/main.mk
build/core/main.mk includes build/core/config.mk which includes build/core/combo/javac.mk which sets HOST_JAVAC, TARGET_JAVAC, and COMMON_JAVAC. COMMON_JAVAC is the "Java compiler command with common arguments," by the look of it the other two variables get these values by default, unless in a special environment (openjdk or eclipse). COMMON_JAVAC is not used outside this file. The other two are only used in build/core/definitions.mk.
build/core/java_library.mk (included by config.mk) seems to only be concerned with building jars. This is out of the scope of us caring. Any interaction with jars presupposes class files which presuppose that we were already successful in building our scala files.
There are checks in main.mk regarding the version of java. We will ignore these and assume that our version of scala is compatible. Right now (in combo/scalac.mk) I am using the same --target arg used in javac.mk. This should perhaps be stored in a variable.
main.mk also includes build/core/definitions.mk which in turns defines some useful functions. The one we care about here is all-java-files-under and all-subdir-java-files. The latter is used in Android.mk files to find java files. The former is used in the implementation of the latter. I will write Scala equivalents of them.
To figure out how the build process works, I am now running make with -n and others. I got this idea from the stackoverflow article "[Tool for debugging makefiles][2]". I am also investigating debugging with remake.
build/core/{config.mk, definitions.mk} gives us light as to which make files/commands are used to do what.
As a possible way of hacking in support on a per project bases, additional code could most likely be added to the project's Android.mk file. From platform/build/core/build-system.html we read "Android.mk is the standard name for the makefile fragments that control the building of a given module. Only the top directory should have a file named "Makefile"." You could create a new target like "scala-build" and run that (make PackageName scala-build) before the final make. One could perhaps also hide it sneakily in a variable assignment, mitigating the need for a target to be called explicitly.
Another way (far far more hackish) is to hijack the command being used for javac. This is set in build/core/combo/javac.mk. Your project's Android.mk will have to include *.scala files in LOCAL_SRC_FILES along with the *.java files.

Guys on reddit say, there's a tutorial on integration Scala into Android with ant here.