Seeing as how there are no preprocessor directives (without jumping through some hurdles), I was wondering if there was an accepted way of doing the following:
Have an android app in the regular ol' android market that uses things like the camera, mic, etc.
Conditionally "swap out" certain features based on some build parameter.
Produce two APKs, one for each store
Ideally, I would want to keep the ANT gymnastics to a minimum ... and also ideally would not have to maintain two sets of files (ie. google_activity_layout.xml and amazon_activity_layout.xml).
edit: this answer looks interesting: https://stackoverflow.com/a/1813873/5416
I have been able to use XMLTask antlib to modify the AndroidManifest.xml as part of the -pre-build hook. I haven't used the mechanism you linked, but I would think that a combination of modifying the permissions and using the linked mechanism would achieve your goal. Since the permissions are checked at runtime vs. at compile time.
You can find the library here: http://www.oopsconsultancy.com/software/xmltask/
One thing to note, it will take some tinkering. My "ant monkey business" did take several hours of tinkering because of the way the apk is compiled together. If you are willing to run the full build a few times it should be less arduous and could probably just ad a completely new task to the beginning of the build.xml that is generated. Let me know if you have questions as I've been tinkering with this stuff a lot.
Related
For a project, I am changing certain ContentProvider-files in the Application Framework Layer of the Android System. As I am trying different things, I was wondering if it is necessary to build the Android Source for every change I make, or if there is a way to somehow emulate the system without the build?
I am not entirely sure what "building" means, as I cannot find a proper definition including Android as a context. I assume it is some kind of compiling?
Converting the source code into an executable program? In that case I do not think there is another way, is there?
But do I understand building correct in the first place? In that case, I would believe there is no other way than building the system every time and then see how it works out.
So I might have the solution right here, but I was hoping someone could assure me that it is right or maybe tell me why it is not?!
Any help is very much appreciated!
Building in this context means that all Android source files are re-compiled by the java compiler and a massive .jar file is produced. This is the Android.jar file that we see in the library dependencies of an Android application project.
Unfortunately, the short answer is that there is no way out for you except to re-compile the entire blob of the Android framework files each time you make a change. What I can advise you is to plan all your changes beforehand so you don't end up wasting a lot of time.
Yes, I saw that the similar question had been asked some years a go, but was unanswered, so I just had to give it another shot.
I am quite annoyed with the fact that the .apk file for the simple Android app I am building has 4MB in size.
When I analyse the .apk, i see that it contains not only unused classes (which can be stripped with ProGuard), but also all the graphic resources from HoloEverywhere.
I mean, even the drawables for the themes I am not using at all are in the apk.
This behaviour looks very illogical, or it just might be that I am doing something very wrong.
Finally, my question is: Is there a way to make the .APK contain only the needed data?
I mean, even the drawables for the themes I am not using at all are in the apk.
From the standpoint of the build tools, they have no good way of knowing that you are not using those drawables.
This behaviour looks very illogical
You are welcome to build a tool that can reliably detect unused resources and removes them from an APK. Call it ResGuard or something. Even the commercial DexGuard doesn't do this.
Is there a way to make the .APK contain only the needed data?
Delete the stuff that you are not using. You're the only one who knows what that is, and since HoloEverywhere appears to be no longer maintained, it's not like you will have updates to worry about.
Long-term, I understand that there's a plan to have Gradle for Android allow you to filter out resources as part of referencing an AAR. I'm not aware that this is in place just yet, and you'd still need to know what resources should be filtered this way. This would allow you to avoid modifying the original project, though.
I have a piece software that should delivered to many customers.
Each build should get a customized set of assets (icons , splash screen etc. ) and a bunch of config files, but also a different app id (eg. com.myself.myapp.customer1 ; com.myself.myapp.customer2 etc... )
Also I need builds for different OSes like Android, iOS , PlayBook.
The way I handled this up to now was:
I created a new Application.mxml for each customer, which opened the right locations and passed the files to the MainController.
This leaves it to me to pick the right assets, certificates and iOS-provisioning files to be packaged each time I need to compile, and I had to repeat this steps for each customer, which is very error-prone and , especially in case of iOS, extremely time-consuming.
So I need to get into automated building quickly...
I already downloaded and installed gradle/gradleFX, but I don't find the documentation very friendly to beginners in this subject.
Now the questions:
How do I have to convert the (Flash Builder- ) given project structure to conform the gradle conventions? Are there FB-plugins or tools I could use?
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a lot of issues with that I really like to circumvent.
Can an ipa be "signed" and packaged with assets after it's principle compilation, so I don't have to wait 15 mins for each compile?
Many thanks
How do I have to convert the (Flash Builder- ) given project structure
to conform the gradle conventions? Are there FB-plugins or tools I
could use?
There is nothing to convert. Unless your project structure is extremely exotic, you should be able to configure GradleFx to work with it.
Note that by default GradleFx uses some Maven-style conventions: for instance, the default source folder will be src/main/actionscript. If you want to configure a typical FlashBuilder project you'll have to explicitly declare the source folder:
srcDirs = ['src']
As for FB plugins: there are none. But you can use an "external build tool" instead of FB's built-in configuration. IntelliJ IDEA has Gradle support, but nothing specifically for GradleFx. GradleFx itself has a flashbuilder plugin, but its purpose is to generate an FB-compatible project from a build script - I don't think that's what you're looking for.
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a
lot of issues with that I really like to circumvent.
You can build a debug-enabled version of your application simply by setting the debug flag to true (as described in Adobe's mxmlc docs). GradleFx does not expose all compiler options in its API (there's just too many of them), however you can use the additionalCompilerOptions to define whatever additional compiler flags you require:
additionalCompilerOptions = ['-debug=true']
I don't know how you should tell FlashBuilder to hook up to the compiled swf for its debug session though :( Perhaps through the "external build tool" configuration.
Can an ipa be "signed" and packaged with assets after it's principle
compilation, so I don't have to wait 15 mins for each compile?
I know too little of mobile support to give you a meaningful answer here, but I can tell you that a major upgrade in this area is in the works right now and will be released soon. Perhaps you should ask this question on http://support.gradlefx.org/; #Slevinbe is very helpful and quick to answer.
I don't find the documentation very friendly to beginners in this
subject
If the docs don't work for you, perhaps the example projects might be more helpful. That said, you could help us make the docs better for beginners by telling us how we could improve them. Just start a discussion on support.gradlefx.org
Multiple outputs
One more thing: your main issue seems to be that you need to create multiple outputs from a single code base. This is one thing that GradleFx doesn't provide out-of-the-box (yet). However, there's a fairly unobtrusive workaround that I've described on my blog. If you find the basic concepts difficult to grasp, then I suggest you don't start with this part, but rather concentrate on getting a single project building first.
This is more of a fundamental question I suppose. I currently have in the market one app that I have separated in two projects. One project (with it's unique package name, obviously) does not have Google Ads and is not free. The other project has Google Ads and it's free.
Both projects are exactly the same. Same functionalities.
When I want to add a new functionality, I have to work on both projects, making then the release of my app slower, since I am basically control-c/control-v what I did in one project onto another. And sometimes I just forget something, so I have to fix the issues...
So, basically, I am wondering if there's a better way I have to manage that?
Maybe creating a rather intelligent script that will build the application depending on what I want (i.e: if it's ad based version, should use the AndroidManifest that declares the AdMob Activity)
Or maybe create a library? But I don't think this approach would work.
Looking forward for inputs.
Regards,
Felipe Caldas
Yes, a library project is exactly what you want. Put all the functionality in a library, and have two very thin shells for each of your app types that make calls into the library. As you noticed, duplicating the code is error prone and at best just extra work you shouldn't have to do.
See: Managing Projects for details. That page even mentions your exact scenario:
If you are creating an application that exists in both free and paid
versions. You move the part of the application that is common to both
versions into a library project. The two dependent projects, with
their different package names, will reference the library project and
provide only the difference between the two application versions.
I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.