I am newer to android development. I have a couple apps I've made with appinventor. I would like to be able to take a completed and packaged .apk that is saved on my computer that was made with appinventor and open to edit it in eclipse. Mainly I want to see how a working app Ive made is actually written. This is for my own educational purposes only, no pirating or other illegal uses.
generally it is not possible to convert an App Inventor project into Java. However there are projects which have this goal, see the App Inventor-Java translation project and the Java Bridge project.
Check the android-apktool. I have no experience with the tool and as I see it will not show you the sources but it seems to be the best way to 'unpack' apk files.
I doubt this is possible, how are you going to bring the dex code back to your java code, even then, AppInventor makes for horrible APKs, two apps that do the exact same thing will differ greatly in size if made with the SDK vs AppInventor.
You should just read a couple of books, or search for information online, instead of trying to unpack an APK.
It's absolutely possible using dex2jar which involves a little time to set up and run but it give you a .jar that you can open with a java decompiler. As for getting the source files into eclipse, there are probably some decompilers that do this but probably cost money. You can use the one listed to copy/paste the code out but it will not provide you with an eclipse project.
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.
I have been working on a project for both native iOS and Android apps. Now that my parent projects are done, I need to run clones for them. These clones will use more or less the same code but with different languages, resources and possibly XIB files as well. I have been using GIT for code management and I google the best way to handle this and the suggested technique was with Forking which was no good because it started creating issues with different Package IDs in the projects.
Now, you know the problem that I am facing. I am looking for expert opinion to handle this scenario.
Don't know how about Android, but for iOS you can use targets and then set which files should be used by selected target. Each target may have its own Info.plist file, different graphic assets and more.
Start with duplicating an existing target:
You will notice Info-copy.plist file, which is a setting file for the new target.
Then use a proper scheme to run your new target:
If it's not there, go to "Manage schemes" and press "Autocreate schemes now"
The android source code has an "external" folder where there are many libraries such as jmonkeyengine. I am wondering if I can access those libraries? There are two scenarios that I am interested in:
If I am just developing an app for the app store, could I somehow use those library (i.e., not including those library in my apk and let my app access them directly from the android system somehow). My initial experiment seems to suggest a "No", I basically compile an apk that use jmonkeyengine library - but I exclude the library from the apk. The app would crash immediately when launched because my activity refereed to a jmonkey class.
If I am developing an "internal app" for an android device (as in compile the whole android source code with my app in the "app" folder in the source code), will I be able to access these library by default?) I have not try anything here yet.
Thanks in advance.
Well, after working on it for a while, I think I have the answers:
The answer for the first question, from my experience (as oppose to reading some references...), is NO.
The answer for the second questions is also NO. By default you will not get access to it. You get access to it by changing the build files instructing android to link your app to the library. At this point this sounds very obvious to me, but at the time I wrote the question that is not very clear
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.
I'm producing an application for multiple clients. Each of these apps only slightly differs (in the ui presentation) from the others and almost all of the other code is identical.
In the best case scenario I would brand something like a boot-strap app for each client so they could have their logo on a separate app in the market. Once a user installed a client's app it would download the core functionality, set some prefs and launch as if it had come from a single download. This way I could get the benefit of updating for bug fixes once rather than for each application (slated for 20-30 by end of year.) I've read that this isn't possible because of security measures though (and additional visits to the market place for the second download or having to allow installation from unknown sources isn't acceptable.)
I'm thinking that worst-case/only-case might be to include this shared code in each application and create some batch build and deploy once updates are ready.
I'm looking for a .dll like approach for economy of effort and safety.
I'd appreciate any input on this.
Thanks!
The java equivalent of a dll is a jar file. You can extract all of your shared functionality into a library project that compiles into a jar and then include that as a library in your other projects.