Proposal to speed up Android build: use Resources without copying files

I propose that the various sample and template proj.android files be fixed to use the Resources directory directly without copying it to the assets directory, thus, speeding up the build. I tried this on my machine for cocos2d-x 3.0 and it seemed to work for Eclipse and Ant builds. Here’s how to do this for samples\Cpp\HelloCpp\proj.android for example:

  1. Follow the instructions in README.md to create the HelloCpp project in Eclipse. Make sure that you can already build before making the following changes.
  2. Open the project in Eclipse and if there’s an assets directory in the Project Explorer, delete it. (Also delete the assets directory on disk to prevent any confusion.)
  3. Right-click the project and choose New -> Folder.
  4. Type assets for the Folder name.
  5. Click Advanced >>
  6. Select Link to alternate location (Linked Folder)
  7. Enter PARENT-1-PROJECT_LOC/Resources. The syntax of PARENT-1-<VariableName> goes to the parent directory of VariableName. This is mentioned here. This syntax is already in use in other Eclipse project files such as samples\Lua\HelloLua\proj.android\.project and samples\Lua\TestLua\proj.android\.project.
  8. Click Finish. Now when you build from Eclipse, the Eclipse ADT plugin will read the Resources directory and put it into an assets directory in the APK. You can verify this by running unzip -l bin\HelloCpp.apk and seeing that the assets files are there.
  9. Create an proj.android\ant.properties file with the following contents:<pre>asset.absolute.dir=…/Resources</pre>Now when you build from the command line with ant debug or ant release, the Resources directory will be used.
  10. Edit build_native.sh and build_native.cmd to no longer copy the Resources directory since the copying is no longer necessary.
  11. For Windows, in Eclipse, right-click the project, choose Properties, then edit C/C++ Build -> Build command to be ${ProjDirPath}\build_native.cmd. (I forgot to include this step when I originally posted this message.)

So in summary, I think this change works and it will improve the experience for everyone, so it would be great if someone could make this change in the official code. Thanks.

Overall this is would be a big negative for me. I would vote NO on this going into official codebase.

Just use a modification time aware copying method in your build scripts — I use XCopy, very fast.

Thanks for the feedback. To help me understand, could you explain why this is a big negative for you? The reason I made the proposal was so that everyone does not need to maintain their own custom build scripts to do modification-time-aware copying by avoiding the copying in the first place.

Thanks.

I’m not even the original designer of the approach — I’m sure she or he had their own set of logical arguments.

For me and the projects I have been working on, it comes down to a few things:

  1. If you are distributing on more than one market (Google Play, Android App Store, OUYA, etc) you will need multiple Android projects with different selection routines for the Resources folder.

  2. Your Resources folder contains files for Android, iPhone, WinPhone, OUYA, BlackBerry, Linux, Win32 … this means multiple GL texture formats, resolutions, music formats and so on.

  3. If you are using tools like Cocos Builder or TexturePacker you’ll want the ability to filter out project or uncompiled file types.

I’m sure if we really sat down and mapped it all out we’d find a bunch more reasons you want Resources to be a central repository and the projects to be filtered copies.

Thanks for the explanation, those are all excellent points that make a lot of sense.

Those points indeed make some sense, but currently build_native.sh just copies the whole ‘Resources’ directory into the ‘assets’ directory, it does not care whether you have different formats of audio-files for different platforms or your textures are made in both SD and HD. Thus if you require some sophisticated assets pipeline you have to plunge yourself into writing your own scripts. If not and you’re happy with the default pipeline provided by build_native.sh, then why waste the time for disk operations?
Kudos to Malcolm for the great tip.

If you look at build_native.sh you’ll see it has several allowances and considerations beyond being just a copy, like icons and

I agree — it was a good time and would work very well for some projects. Malcolm’s post is excellent, I was trying to respond to the comment about making it the default.

Thanks!

Malcolm Evershed wrote:

I propose that the various sample and template proj.android files be fixed to use the Resources directory directly without copying it to the assets directory, thus, speeding up the build. I tried this on my machine for cocos2d-x 3.0 and it seemed to work for Eclipse and Ant builds. Here’s how to do this for samplesCppHelloCppproj.android for example:
>
# Follow the instructions in README.md to create the HelloCpp project in Eclipse. Make sure that you can already build before making the following changes.
# Open the project in Eclipse and if there’s an assets directory in the Project Explorer, delete it. (Also delete the assets directory on disk to prevent any confusion.)
# Right-click the project and choose New -> Folder.
# Type assets for the Folder name.
# Click Advanced >>
# Select Link to alternate location (Linked Folder)
# Enter PARENT-1-PROJECT_LOC/Resources. The syntax of PARENT-1-<VariableName> goes to the parent directory of VariableName. This is mentioned here. This syntax is already in use in other Eclipse project files such as samplesLuaHelloLuaproj.android.project and samplesLuaTestLuaproj.android.project.
# Click Finish. Now when you build from Eclipse, the Eclipse ADT plugin will read the Resources directory and put it into an assets directory in the APK. You can verify this by running unzip -l binHelloCpp.apk and seeing that the assets files are there.
# Create an proj.androidant.properties file with the following contents:[…]Now when you build from the command line with ant debug or ant release, the Resources directory will be used.
# Edit build_native.sh and build_native.cmd to no longer copy the Resources directory since the copying is no longer necessary.
>
>
So in summary, I think this change works and it will improve the experience for everyone, so it would be great if someone could make this change in the official code. Thanks.

Does this works in Linux?

Vikas Patidar wrote:

Does this works in Linux?

I haven’t tried it in Linux, but I think it should probably work.

I have tried your method to test build time and it works faster because you have commented code section which performs copy operation in `build_native.sh`. But when you run your project then “Android Resource Manger” looks for all the files and folders inside “assets” and “res” folders and build a compressed file “resources.ap_” and it takes significant amount of time when building apk file. But still i think cygwin is a big headache for Windows environment. I have faced Permission denied issues many time and also when we build and run our project then bash program executes “build_native.sh” which runs in a emulated environment which is always slow. There fore I have tried modified build process which is faster and don’t require cygwin program on your windows system.
Check out the thread: http://www.cocos2d-x.org/forums/6/topics/35606

I should clarify a few things:

  1. cocos2d-x 3.0 has a build_native.cmd script for Windows. I used this and have never needed cygwin or mingw32 on my system.
  2. The build_native.cmd script can be edited to remove the copy operations.
  3. Eclipse should be configured to run build_native.cmd instead of build_native.sh.

Thanks.

Thanks Malcolm for the clarifications.

It’s indeed very good approach but still it require some customizations at user end. When you link to Resources then Eclipse add some configuration in .project xml file.

I think we can just edit .project file in cocos2d-root\cocos2dx\platform\android\java
directory which comes with eclipse project and add following lines of code under <projectDescription>........</projectDescription> tag :

        assets
        2
        $%7BPARENT-1-PROJECT_LOC%7D/Resources

Now if cocos2dx team pre-load this configured file with Android project then it’s easy for the end user and there is no need for copying inside build_native.sh or build_native.cmd files.

I would give my vote for this feature request.

Vikas Patidar wrote:

I think we can just edit .project file in cocos2d-root\cocos2dx\platform\android\java
directory which comes with eclipse project and add following lines of code under <projectDescription>........</projectDescription> tag :
>
[…]

I tried your suggestion, but it did not work on my machine.

I think the problem is that it is not sufficient to just edit cocos2d-root\cocos2dx\platform\android\java\.project. I think that each project’s .project file needs to be edited. That should work (and could be done by the cocos2dx team).

I investigated converting some of the other samples to use this technique and it does get a little bit more complicated because the other build_native.sh/cmd files do various ‘filtering’, somewhat like Cory’s real-world projects.

When you create an Android Project using create-android-project.bat then it does not copy .project file. Therefore we have to edit it, just find the following line

call "%_ANDROIDTOOLS%\android.bat" update project -l ../../cocos2dx/platform/android/java -p %_PROJECTDIR%\proj.android

Now add given below line

copy cocos2dx\platform\android\java\.project %_PROJECTDIR%\proj.android\.project

I have tested with cocos2d-x-2.1.5 on Windows 7 and it’s working fine.

create-android-project.bat has been deleted from cocos2d-x:

Okay then I have edited .project file inside cocos2d-x-3.0alpha0\template\multi-platform-cpp\proj.android directory and added given below lines of code under <linkedResources> tag it’s working fine.

    assets
    2
    PARENT-1-PROJECT_LOC/Resources

Yes, that is the change that I’m proposing. The steps in my first message just use the GUI to arrive at that same .project change. Thanks for confirming it.