I recently downloaded the source code for Android. There are many folders starting from the root level and I was wondering if there is any resource on the web containing just an overview of the contents of different folders and where common libraries/framework classes reside.
Thanks.
The Android project is made by a bunch of smaller projects, all of them downloaded when you clone the Android repo (with repo init ...). I don't know if there's such a resource explaining what each project is and I wouldn't expect there is one.
Android framework classes are in their majority under frameworks/base/ directory, while apps like Settings, Browser and others can be found under packages/apps/. A really good way to navigate the sources is to use find + grep if you're under Linux. Another approach that goes SO independent is using Eclipse to navigate the sources. For this last approach, you can find the details here: http://blog.michael-forster.de/2008/12/view-android-source-code-in-eclipse.html
Note that classes in the framework that are not visible for application developers are not that well documented, so if you're planning on customizing Android be prepared to read a lot of code.
Sounds like you're after the javadocs?
Related
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"
I have multiple Android applications, and I've created a common Android library project, and a common Java library project (The Android library project compiles the java one). These libraries are filled with common components that I use for all my Android apps.
I'm using gradle as my build system.
I'm using git for versioning.
What would be the best way to link everything together? Keep in mind things are still being added / changed in the library, and I need a way to propagate changes to all the Android apps. Copy / Paste wouldn't be a great option. I've tried a few things, and they aren't working out very well, so I'd love some input.
EDIT: It's probably also worth mentioning that multiple people are working on these projects. It's not just me.
The current version of Android Studio has a limitation that all of its modules must be under the project's root directory in the filesystem, and this limitation hampers a lot of people in your situation, because frequently they want those common libraries to live someplace else. It seems like this is the case for you as well.
We're in the process of lifting this limitation in Android Studio, and soon you'll be able to have modules outside the project root. I think this might be the best solution for you -- you can pull your common libraries from wherever makes sense in source control, put them wherever makes sense in your filesystem, and link them up into whatever projects need them. However, this isn't available yet, but will show up in v0.5.0, which will hopefully go out this week. I haven't personally tested it in our dev builds and can't vouch for how well it works, but at any rate it should be coming along soon.
Some developers have worked around the limitations by adding script to their settings.gradle files to set different module root directories. They say it works, but I find it a little scary because the IDE just isn't expecting things to work that way, and I don't know for sure if there are problems with it.
If you read other answers to this question on Stack Overflow, they're written before this feature was implemented and will have different advice. If you don't want to wait for 0.5.0 or there are problems in it that prevent you from using it, you can follow that general advice, which is to have your common code compile to libraries that you publish to a Maven repository (which can be local to your machine or common to the developers in your group), and pick up those libraries with Maven-style dependency statements in the projects that need them. This has the disadvantage that you'll need to open up separate projects to edit the code in those libraries, along with a more complex build process, but it will work.
It's quite often that we see two versions of an android app: a paid version and a free version. I'm also developing an app that would like to release two versions. What is the best way to do this? Creating two projects and copying files in between does not seem to be the best way in my mind.
Use Library Project, as the official dev guide suggested:
If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
If you are developing multiple related applications that use some of the same components, you move the redundant components out of their respective application projects and create a single, reuseable set of the same components in a library project.
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.
Update: This method is really only good for compiling with Eclipse, since Android Studio supports build flavors which can achieve exactly this.
While #yorkw's and #Nate's answers are both good, this is the method I use due to its simplicity. From the article:
com.example.myapp – Android Project Library - This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
com.example.myapp.full - Android Application Project - This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
com.example.myapp.lite - Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.
I also keep a static variable IS_PRO in a library class which is set when the app launches. This should be used only for notifications, alerts, and so on (such as asking the user to upgrade to pro).
However, this method has one drawback: you must clean and rebuild any time the library or its resources are modified. Also be sure to read this post on sharing resources between a project and a library.
I would call this a FORK in development. Start a new App development, but have your common code coming from a common file location. Make your free based edits to the forked code, and try your best to keep that code completely separate.
I actually did this on an iPhone based app, I have a free version and 2 different payed versions (a single player only and a multi-player). I would do it the same way on Android.
U can use git for example.
Create branch "app_with_ads", and master will be your "paid" version.
Develop in master and merge periodically to another.
before publish u probably will have to change app package, or something else in Android\ Manifest.xml
Here's a little blog tutorial about doing this.
Basically a howto for building a Full and Lite version of the same app, using a library project to accomplish code reuse between the two versions.
I'm sure this has been asked before, but I'm having trouble finding the answer (overwhelmed with search hits).
Where can I find the source code to the default settings of the various built-in layouts and widgets?
Why? So I can see what they (the android developers) are doing so that I can emulate when I like, and change what I don't. There are hundreds, if not thousands of files in my API, so going through them one-by-one is...tedious at best.
Thanks in advance!
The source is in at the Android Git Repository at kernel.org in repository platform/frameworks/base.git. Clone this repository, as it is far less frustrating not waiting for it to load via the Internet. The View related code is a couple different packages, android.view, android.widget, and android.webkit. The the related XML resources are scattered a bit wider but to start take a look at values and drawable directories.
I'm fairly new to android and have only really been using eclipse for some basic Blackberry work so I was curious if I could pick a few expert's minds for any suggestions/pointers on the workspace/project setup you use for dual platform support projects in eclipse?
I've found about 80% of my code is common between Blackberry and Android so it's this 20% I'm needing to address.
My current thinking is to have one workspace with shared source in multiple projects via setting them in the source tree options.
Where platform specific features are used I'll tag the source name as *Android_???* and *Blackberry_???* respectively and have a generic class that both projects point to.
I.e. effectively one workspace holds both Android and Blackberry setups and in the workspace have one project for Blackberry and one for Android but each project shares the same filesystem with the appropritate other platform's source files excluded from the build.
If only there was an easy way of doing the #ifdef equivalent in java this would simplify this port but I guess we have to do it without.(I heard about using a c preprocessor to do this but sounds messy so unless it's highly recommended I'd rather not adopt this)
I'd heard about creating a shared library but have a feeling these are not compatible between android and blackberry so any advice on this approach is also welcome.
It's probably too late, but I'll still give you my thoughts on that.
I have a similar need. I have common code and Blackberry and Android specific parts. I have three separate Eclipse project for each part. The "specific" projects are the one actually run, and they both have a project dependancy (which I find cleaner than source inclusion) on the Common one.
Note that the Common project must be a Blackberry project (created using the plugin), since a Blackberry project cannot depend on a non-blackberry project.
It's working well for me!
For anyone else facing this issue I've found the solution that worked was by creating 3 directories on disk
Common
Blackberry
Android
The vast majority goes into Common however the classes that have platform specific calls go into the Blackberry/Android counterparts respectively and extend a common base class in the common directory.
E.g. a class called MyClass that needed platform specific versions would have a MyClassCommon in the common directory and in the Blackberry directory it has MyClass extends MyClassCommon definition and the same for Android.
In Eclipse the Common,Blackberry,Android src paths are individually added via a common variable (trunk) which is extened to the Common,Blackberry,Android paths for the 3 src root imports.
This seemed to be the only mechanism to ensure that the package name was consistent across platforms so not having a knock on effect that other dependent classes needed new package names.
I'm sure there is a more elegant/correct way of doing this but this appears to work well for now.