This question is related to this other one. I have recompiled Android framework and generated a new image. I need to add some classes to the original framework and did it by adding new jars that go into /system/framework. I modified BOOTCLASSPATH to take into account these new jars.
Building the image and flashing to the device does not work. Some optimizations must be run prior to that, but I do not know how that process is.
What building steps should I execute before generating the image or what other alternatives do I have so the extended framework classes are accesible from applications?
I also changed the bootclasspath by changing one of the .mk files, adding my jar to a line that looks like this:
PRODUCT_BOOT_JARS += myjar
Then you just have to make the build and flash to the device just like what you said.
Sometimes it might not be enough and you'd have to erase this file:
./obj/ETC/init.environ.rc_intermediates/init.environ.rc
and then make again.
Hope that helps.
Related
Im not sure what it is called but ill do my best to explain it. I did search here on stack exchange and found this answer for an allias for path but i dont want to set a variable for it and i already know that. create alias for path
What I need is and its been along time since I seen it but its used with a % or $ or something that when the program runs from the directory it knows where the directory for the game files are. It didn't matter what the directory the program is in as long as the directory 'gameFiles' is in that directory it will work.
Here's my path:
"/storage/emulated/0/MyGame/MyHackGame/jni/gameFiles/oscom.txt"
I think its something like:
"%or$/gameFiles/oscom.txt"
The main problem is I have a project on source forge and don't want my developers to have to change these paths like 100 times to run the program and then I'll have to change them back.
Also iam using aide for android to make the program and using the standard c++ libaray do this might be difficult to do. I'm not even sure if I can add libarays with aide and native code or how to do it.
Use symlinks as Eugene has suggested or modify build scripts to generate user specific paths into binaries or spearate files at build time. These are ignored by version tracking, so no more double mills. Another way might be checking env variables at runtime.
I have a small Android application that uses different sets of files (a couple of images, a small SQLite DB and a couple of XML files) depending on the specific task at hand.
I know I can include my files into the main application APK using resources or assets but I would be happy to distribute them in a separated APK.
How can I create a data-only APK file?
How can I distribute it? In particular, do I have to do anything special for a data-only package (for example for associating it to the main application package in some way)?
(I'm intentioned to give the user a link to the data package and ask him to install it. No automatic installation required.)
How can I install my files into the internal or into the external storage area of my application? Is it possible at all to install files into the internal storage area created by the main application installer? Do I have to set any particular permission for this?
My approach to this would be to create a wrapper app that's nothing but a content-provider and serves up the files per request by your main app. This would allow you to supply different data packages for the user -- you could even have your main app select between those relatively easily.
It looks like that the commonly accepted way to have the same application with different contents (or styles, or configurations) is to use an Android Library Project for the common code (that is: the whole application, the "engine", the "app framework") and a standard Android Application Project for the contents (that is: an application that actually contains just data). A little bit confusing, just because the "library" here is actually the whole "app", but this seems to be the way to go.
More in detail:
Create an Android Library Application and put into it as much code as you can (all of the non-changing stuff). Please note that this library cannot be launched and cannot be distributed alone. It must be included in a hosting application.
Create a standard Android Application. Include your library into this project. Put in /res and in /asset all of your data (files, XML, etc.).
Compile everything and distribute.
Repeat this cycle every time you need a different version. Different because of data, style, configuration or anything else. Publish the resulting app with a new name.
For what regards me, I'm not completely satisfied by this approach.
A possible alternative is preprocessing the source code with Ruby, Python, Perl, GIT, bash, Ant, Maven, Rake or any other tool that is able to read a file from here, make some change here and there, and write the file there.
The general outline is something like this:
Make a "template" application. Leave your /res and /assset empty.
Run a custom-made script. The script reads a configuration file, copy the /res and /asset files from your repository into the project /res and /asset directories, changes some Java source file and creates/changes some XML file.
Compile and distribute (with a new name, of course).
Using GIT or other SCMs, you just make a new branch for every new version and compile it. Not very elegant (because it can strongly interfere with the normal use of the SCM) but...
There are a few example of these approaches on the web. I'm not completely satisfied by them, either.
Frankly, what the Android ecosystem should offer to solve this problem is some kind of "in-app package manager". Something like the Eclipse Update Manager. This would allow us to use the same application framework to handle different scenarios.
As an alternative, a solid, officially-supported, template-based code-generation mechanism would be nice. Something in the spirit of "Software Production Line": https://en.wikipedia.org/wiki/Software_production_line . Have a look at fw4spl, for example: http://code.google.com/p/fw4spl/ .
I am developing Android application for which I want to ship several different apks for different languages in the market (every language includes a huge bundle of files and I want to avoid creating one huge apk with all language bundles).
So what I need is to customize a bit the Manifest file for each language: e.g. the package of the application and possibly the application version etc. I know how I can template the manifest so that I can manually insert my values in certain points in the file (see this post). The problem is that I use ant for preparing my production apks, but otherwise I develop using Eclipse and so I need my project working in the IDE too. Eclipse requires complete Manifest file and will not understand of the templating I will use for the ant builds as far as I know (please somebody prove me wrong).
My problem is that I want to avoid maintaining two manifest files that are identical in large part (one templated and one complete for Eclipse). Currently I can think of two possible approaches, but I do not know how to accomplish them:
Use some kind of definition injection in the manifest file: if I am able to inject certain xml file in the body of AndroidManifest file, I can keep the identical part in one xml part and customize only the points of difference
If it is possible to configure Eclipse to use some sequence of ant tasks to build Android projects instead of the prebuild routines I might be able to integrate the way I build my production apks in the IDE.
Please if there is anyone who knows how to accomplish any of the above two, or has any other idea how can I solve my issue: help!
Take a look on ant replace task:
<replace file="${build.out}/src/config.prop" token="###" value="${build.version}-${build.type}"/>
But again you should be careful with values that they are unique.
You could also replace your eclipse manifest with generated manifest by echoxml task.
Or you could reuse this nice task about xml manipulation.
At the company I work for, we pretty much use the approach given by Eugen to automate the build process of apps that e.g. should simply be branded differently by exchanging certain assets, styles, strings and configurations. We tend to set up the project and build process as follows:
Create the Android project and set it up such that it works for a specific branding. This will make sure that you can still build and run from Eclipse. Assuming that the codebase does not change between differently branded releases, that should be fine.
Create an ant build configuration that:
copies any files that are going to be changed to a backup directory
modifies the project files according to a configuration file (see below)
compiles the project sources and signs it with a release key (if making a release build)
copies back the files from step 1, overwriting any changes and returning the project to its original state
Create configuration files for every 'branding', or language specific release in your scenario.
Basically these steps will allow you to create branded/partner/language specific builds by simply providing the appropriate configuration with the ant build command. In our case it looks somewhat like this:
ant partner-release -Dpartner=stackoverflow
where 'stackoverflow' will point to a configuration with the same name. In our case these configuration files are small xml files that contain all the parameters that are to be replaced for that specific build. It could contain strings, but might as well point to other files (e.g. logo images) that should be copied into the assets/resources. For example:
<config>
<version_name>1.00</version_name>
<version_code>1</version_code>
...
</config>
Some more pointers:
We use xmltask to modify any xml files in the project; e.g. the manifest and resources.
Since the aforementioned task is really easy to use, our build configuration files are also set up as xml files, as illustrated above. It's quite human readable and easy and straightforward to change.
You can also use replace and ReplaceRegExp tasks to change configuration-dependent variables in almost any file. The latter can be especially convenient to make build-time changes to source code.
I have been working for one of the project where I am required to do the following.
Current Status: I have developed an Android app for which we are currently distributing apk files to the users. But the problem is, if users want to alter any designs etc, we have to take that pain, instead, we want to make sure the view files are available to them, but the core logic is in the jar file. Now, creating jar file is not an issue, but we still want to secure the source code. So, I found ProGuard http://proguard.sourceforge.net/index.html#manual/introduction.html
Now, the examples there shows that apk file which will be generate will have obfuscated codes. But I just want my classes under the jar files to be obfuscated.
Any help will be appreciation.
You can limit which classes should be left original and which ones should be obfuscated.
For example you may not want to obfuscate Activities or Services or Android will not be able to find them anymore ;-)
Reference: http://developer.android.com/tools/help/proguard.html#configuring
You can also use proguard on its own and pre-obfuscate your jar file before using it in the app itself.
Say I want to add a CustomizedAlarmManagerService class on top of what is already there in AOSP or CyanogenMod, and put it into a new package 'com.myandroid.server'.
What are the steps I need to take in order for the build to be successful?
Currently if I just add the file, reference the class somewhere, and build the whole project, I will get error "Package (com.myandroid.server) does not exist".
Thanks!
Check the appropriate Android.mk file and add your new file to the list of sources.
Since I lasted asked the question, there are now quite a lot of docs online detailing how Android Build system works.
For example, a blog post like this explains things pretty well.
Yes it has something to do with Android.mk file, but no, it's not just adding the files.
Basically for any new module you are creating, you need to create a new Android.mk file, give it a module name (by setting LOCAL_MODULE), then make sure places where this module is referenced has their respective Android.mk files include the pointer to the module (e.g. setting LOCAL_STATIC_LIBRARIES).
Oh, and remember the build orders in Android.