why some configuration in AndroidManifest goes inside "application" section and some not? - android

While writing Android manifest some configuration I must put inside "application" section (eg. list of activities) and some outside it (eg. uses-sdk). Why? Is there any general rule what goes inside "application" section and what outside? Or was it pure random arbitrary decision by Android creators?

Not really a programming question. If you follow commit history of AOSP you might get an answer. Or track down Andy Rubin and ask him :)
With the current layout, you could theoretically have multiple applications inside the same APK. Stuff that is common to all applications will got at the highest level (uses-sdk, etc.), everything else inside the corresponding <application>.

Definitely it is not a random decision.
The Format is something like you have define the configurations pertaining to any application such as its activities and services inside tag because ofcourse they are related to your application.
And General libraries you use and Permissions outside of the tag which complement your application.
Take a note of the structure of the manifest file here

To get concept in detail try here.

Related

Can I package Activity/ies in an aar library

I have a working android app. The client wants to expose part of it as an "SDK" (actually library) to other developers. The idea is that other developers should be able to start a workflow from this so called "SDK" which spans through a few activities.
So my question is: Can I package an Activity (or more Activities) in an aar, which the end developer can use?
If yes: Does she have to do anything else, besides listing the Activity/Activities within their own Manifest, or are they merged automatically?
If no: How can I expose an Activity to other developers (without Intents, because there is no guarantee my App is installed on the end device)
yes you can do.
If i recall correctly, you may need to tools:replace="android:allowBackup,android:icon,android:label" amongst others in the manifest of the apk-activity, or you will get some warnings from the manifest merger.
And I believe you need to declare an parentActivity, that (or one of its members) will be able to launch the activity from the aar via Intent.
Manifest of the apk:
<activity
android:name="com.somepackage.LibraryActivity"
android:parentActivityName="com.someotherpackage.UsingActivity"/>

Multiple applications with different names for the same code base

Reading this article, thought having the same problem - One code base, two applications on Android
I have created an application testApp that has items like topics, splash screens, logos, charts, rules, statuses and/or events.
Now, I want different applications (testApp_USA, testApp_Canada, testApp_Australia)from the same code base and put them on Google Play Store so that if user downloads the application, say, testApp_USA, then only the specific items to that region should be shown like splash Screen of USA, USA logos, etc..
So I want to configure multiple applications according to countries and then set the items as defaults according to which application the user has downloaded.
Presently, I have a single application which is for all regions and I am imposing multiple conditions to distinguish or change the items according to the regions.
For example:
(In many Java files, I used)
if(rule.contains("USA"))
{
//Show splash screen of USA
}
(Similarly, In many Java files, I used)
if(rule.contains("Australia"))
{
//Show splash screen of Australia
}
This is just a one item out of many repeated throughout code. Considering all, it will be lot more.
There should be a better way to create multiple applications in android with different names and settings.
I know, iOS allows me to easily change the application name and profile to allow multiple apps to be created. But I don't know or this is not easy to do on the Android code.
My question:
Is it possible to create different applications with the same source code in android with different settings of items and publish them to Google Play Store ? If YES, How to set such configuration ?
UPDATE:
Read this Post - multiple-android-application-package-apk-files-from-single-source-code
Then I came up with the same idea -
1) Taking some string variable that holds values about which application type you want to create.
public static final String app_Name = "testApp_CANADA" ;
2) Have multiple AndroidManifest.xml files for multiple apps you need to create .apk for.
3) Create corresponding launcher activities for each manifest.
But then how to have multiple AndroidManifest.xml files in a single app ?
UPDATE:
My first AndroidManifest.xml is in main project folder (application root folder) as usual that we have. Consider this for testApp_USA.
My second AndroidManifest.xml is in separate package under main project. Consider this for testApp_CANADA.
Both AndroidManifest.xml have different launcher activities with corresponding splash screens, icons defined. The package names are given different in both so that they will create different .apk files as per requirement.
Now, how to switch code between testApp_USA/testApp_CANADA provided my main app has setting:
public static final String app_Name = "testApp_CANADA" ;
OR
More clearly,
How to call a particular AndroidManifest.xml according to the value of app_Name ?
With the current setup that I have, only first AndroidManifest.xml is called always.
I had similar problem with putting project to different markets - Google Play, Samsung, Amazon. All code base is the same, difference only in billing code.
The best solution I found is creating separate project for each market and pushing common code into library project.
In more detail, you need to leave common code in main project, make it library project and enable manifest merger for library and child projects.
Add following lines to project.properties of main project:
android.library=true
manifestmerger.enabled=true
and this to project.properties of every child project:
android.library.reference.1=../testApp //absolute or relative path to your main project
manifestmerger.enabled=true
Also you need to attach main project as library in ADT plugin (in Eclipse - project properties -> Android) to all child projects.
Main project manifest should not contain any launcher activity, it will be ignored, same thing with appWidget xml's and config activities, if you have some.
In child projects you can configure whatever you want and use main code by extending or just using needed classes as normal Java library. Also, you can use main project activities, services, broadcast receivers, etc just as they are in your child project without any duplication of manifest of child projects.
After all configured, you can just build needed project for needed country as usual single project and you would have different apk's for different countries, as you want.
Here is more detail description of manifest merging http://www.platoevolved.com/blog/programming/android/merging-android-manifest-files/
Note, this feature was added in ADT version 20 preview 3.
Hope this helps.
I had this same question. Maybe you have found the answer at this point, but some searching finally led me to this website, which explains Gradle.
It seems to explain all the basics really well. For the answer to your specific question, look for the section Product Flavors under Build Variants.
As the website explains, part of the purpose behind this design was to make it more dynamic and more easily allow multiple APKs to be created with essentially the same code, which sounds exactly like what you're doing.
I probably didn't explain it the best, but that website does a pretty good job.
The way to have multiple apps from a common code base is to have the common code as a library project, and have each app use the library project (see http://developer.android.com/tools/projects/index.html).
Each project can override strings.xml, and the common come can check the package id.
In your case it seems that this is against the Google Play policy (cookie cutter apps), so it may be better to create one app and let the user choose a country.
For this you have to use App Localization concept. For this you have to create different resources, durables. Let say You want to run your application in japan, you have to create drawable folder like "res/drawable-ja". This is same as you create different layouts to support tablet and small devices.
here is reference link:
http://developer.android.com/guide/topics/resources/localization.html
http://developer.android.com/distribute/googleplay/publish/localizing.html
I am not sure what you want exactly. But at my point of level, you can able to get the geo location, there you can find-out where you app currently running out, or in more easier get the location from locale, once you find the locale or geo-location, you can navigate the source according to that.

how to setup details about an android app?

i have used eclipse, android sdk and phonegap to create a small application. I give it a test and create a test.apk package.
What i ma wondering is where can i set up some details about this app, like who made it, the app name, the version, an icon maybe, any other things i might need to setup.
I have a AndroidManifest.xml file and when i open it i get a nice gui but i don't know what to modify there
Im not sure what i need to set up and even if i need to.
A good tutorial is much appreciated. Thanks
You can set most of those things in the manifest file. If you want to include this information in your code, add license headers in all your classes, use java-doc etc.
If you want this information to be accessible in your app like from 'About' button, you have to handle it yourself.
Take a look at this example.
This details are to be filled when you upload it to android market. I dont think you set them in AndroidManifest.xml ! you can see the xml code , by clicking on the "source code" tab just below the UI .
Here's a tutorial that describes managing AndroidManifest.xml, the app name and icons from our AppLaud Eclipse plugin for PhoneGap Android.

Should I use Log.d in my app?

I wonder if it is a "good coding" to use log.d very often in my app?
Should I include a checkbox to manually activate logging or is it okay to do it everytime the app starts? I know the normal user doesn't see it, but I guess as it is not stored in a file (or is it?) no write cycles would be wasted.
What would you say?
Thanks for helping...
Read this.
Or quote:
Before you consider your application ready for release:
1. Test your
application extensively on an actual device
2. Consider adding an End
User License Agreement in your application
3.Consider adding licensing
support
4. Specify an icon and label in the application's manifest
5. Turn
off logging and debugging and clean up data/files
I agree with the point you have mentioned. As a developer its good to have log for application.
My suggestion would to have some logic to remove log related lines on compilation i.e Tag.
what`s your view on this.

In an AndroidManfiest.xml file, what is the impact of renaming/moving/removing activities?

Many/most of the settings in AndroidManifest.xml have a public impact. Changing the package name changes the identity of the app in the store. Changing uses-permission changes the list of permissions and may prevent automatic updates, etc.
What is the impact of removing or renaming a non-MAIN activity? For that matter, what is the impact of renaming the MAIN activity? Given that the intent-filter is used to mark it main I'm not sure why changes to the name or package of the MAIN activity would matter.
It's apparently necessary that all activity classes be declared here, so I want to know if I'll cause some sort of public effect simply by refactoring an activity so it has a different name or package.
The developer page for AndroidManifest.xml doesn't get into public consequences of changes. Can someone point me to a page describing the impacts of various changes to this file?
You can take a look at an official blog post by the Android team here: Things That Cannot Change.
If you refactor the name of your refactor the name of some Activity, either in the Manifest or in your class, obviously both the manifest and the class have to match, otherwise you'll get errors. But, in terms of your app in the Marketplace, refactor class names has zero effect.

Categories

Resources