Thursday, 31 July 2014

New Admob Installation:Google Play Services for Monetization

Recently Google announced that their Ad program for Android device Admob leaves old Admob SDK and moving to new Admob with Google Play Services package. Obsolete Admob publishers will not get impressions if don’t move to the new Admob with Play service. In this  tutorial I am going to unveil How to configure new Admob using Google Play services.

New Admob Installation


Problem:  Configure New Admob services for Android

Difficulty: Intermediate

Additional Requirements: copy of Google Play Services package, Admob Account, Admob publisher ID.

Step : 1 Create New Site/App

Note : You can skip this method if have an existing app if so save your Publisher ID for future enhancement.
1.  Go to
2. Click on Sites & Apps tab  and Click Add Site/App
3.  Select Android from List
4.  Enter you App Name (example Ad Revenue Calculator)
5.  Enter the Android Package URL (example market://details?id=<com.bigknol.adrevenue.calculator>) make sure that the id points to correct package name of your project.
6. Select your Application category (Example Productivity)
7:  Add your App description
8.  Select Keyword Target Ads
9. Press continue button.
10. You can download the AdMob SDK after completing the above steps. Copy the App publisher ID from the final step.
Note : GoogleAdMobAdsSdk-6.4.1.jar is obsolete, you don’t want to use it on your app. 

Step 2: Install Google Play Services to SDK

1. Before you getting started with new Admob service you must install Google Play Services package in SDK, It will be stored in <android sdk>/extras/google/ directory. Open up your Android SDK Manager from Window menu of Eclipse IDE. Move down and go to Extras tick Google Play services (If you are targeting Android Froyo users you need to tick Google Play services for Froyo also) Install all required packages from Android SDK Manager.
New Admob Installation Step 1
2. Copy the Google Play services package.
Many developers forget to move a copy of extras package to workspace for making a reference to project. So you should take a copy of Google play services from <android sdk>/extras/google/ and paste it on your workspace.
3. Linking Google Play services package to project
If you want to use any class of AdMob package you must reference it properly. Otherwise you may get errors like “Admob  Class Not found Exceptions”.  How to link it?  First you need to import the google-play-services_lib to current workspace.
File > Import > Android > Existing Android Code Into Workspace
Browse it from google_play_services/libproject/google-play-services_lib.
Warning: Don’t browse the original Google play services libproject from <android-sdk>/extras/google/google_play_services. Make sure that you have taken libproject from the copied version of Google play services in the workspace.

Step 3: Referencing to Current project

Right click on your project Select Properties

New Admob Installation Step 3

Click on Android, press Add button from Library then choose the google-play-services_lib as library. Click on Apply button then finally OK

Admob Installation Step 4

Now you can use methods and classes in your project.

Step 4:  Setting up Android Manifest File for New Admob SDK

Your android manifest file should have required permissions for executing AdMob. It includes INTERNET and ACCESS_NETWORK_STATE.
1. Add the following permissions (Before application Tag) to Manifest.xml

 <uses-permission android:name="android.permission.INTERNET" />
 <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

2. Add the meta tag to Manifest
You have to add a meta tag that tells you are using the version of google play. Add the following meta tag before closing the application tag.

<meta-data android:name=""

3. You must register an AdActivity to Manifest file. It will be appeared inside the application tag.

<activity android:name=""

4. Save your Manifest File.

Step 5: Configure Admob Views in XML layout

Assume your main layout file is ad_test.xml (Displaying Ads in this layout) you must implement an xmlns to your main layout it might be relative or linear.


<RelativeLayout xmlns:android=""

Next is to add a custom AdView to the ad_test layout.

<RelativeLayout xmlns:android=""
< android:id="@+id/MyAdView"

We have already copied the Publisher ID from the beginning of the tutorial; now replace the adUnitId XXXXXX using your on ID. Don’t forget to add adSize property.
You are done!

Step 6: Make Visible your Ads, and Test it on your Emulator, Device

Open your Main Activity File (example:

import android.os.Bundle;
public class MyAds extends Activity {
private AdView adView;
 protected void onCreate(Bundle savedInstanceState) {
 AdRequest adRequest=new AdRequest.Builder().build();
 public void onPause() {
 public void onResume() {
 public void onDestroy() {

You may have noticed that, An instance of AdRequest is instantiated finally build it and load from OnCreate Method.
Warning : I recommend test mode of AdMob when you try the above activity.
How to use Test Mode in Admob ?
You might know Google is very strict for preventing fraud clicks against ads they publish through various program like adsense, admob etc. Invalid impressions of Admob ads may cause your account instantly.
You can use test mode by modifying the above code.

  AdRequest adRequest=new AdRequest.Builder()

If you observe the above code, addTestDevice() method informs to request that you are using the ad test phase not the real ad serving phase. You may ask Where do I get the Device ID (7XXXXXXXXXXX) ?
You can capture it from your logcat when you test it on your emulator.

Admob Installation Step 5

Wednesday, 30 July 2014

Multiple APK Upload into Same Application in Google play


    Simultaneously publish different APKs for different device configurations
    You should publish multiple APKs only when it's not possible to support all desired devices with a single APK

Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations.
Each APK is a complete and independent version of your application, but they share the same application listing on Google Play and must share the same package name and be
signed with the same release key. This feature is useful for cases in which your application cannot reach all desired devices with a single APK.

Android-powered devices may differ in several ways and it's important to the success of your application that you make it available to as many devices as possible.
Android applications usually run on most compatible devices with a single APK, by supplying alternative resources for different configurations
(for example, different layouts for different screen sizes) and the Android system selects the appropriate resources for the device at runtime. In a few cases,
 however, a single APK is unable to support all device configurations, because alternative resources make the APK file too big (greater than 50MB)
or other technical challenges prevent a single APK from working on all devices.

Although we encourage you to develop and publish a single APK that supports as many device configurations as possible, doing so is sometimes not possible.
 To help you publish your application for as many devices as possible, Google Play allows you to publish multiple APKs under the same application listing.
Google Play then supplies each APK to the appropriate devices based on configuration support you've declared in the manifest file of each APK.

By publishing your application with multiple APKs, you can:

    Support different OpenGL texture compression formats with each APK.
    Support different screen sizes and densities with each APK.
    Support different device feature sets with each APK.
    Support different platform versions with each APK.
    Support different CPU architectures with each APK (such as for ARM, x86, and MIPS, when your app uses the Android NDK).

Active APKs:

Before you can publish your application (whether publishing one or multiple APKs), you must "activate" your APK(s) from the APK files tab.
When you activate an APK, it moves into the list of Active APKs. This list allows you to preview which APK(s) you're about to publish.

If there are no errors, any "active" APK will be published to Google Play when you click the Publish button
(if the application is unpublished) or when you click the Save button (if the application is already published).

Simple mode and advanced mode

The Google Play Developer Console provides two modes for managing the APKs associated with your application:
simple mode and advanced mode. You can switch between these by clicking the link at the top-right corner of the APK files tab.

Simple mode is the traditional way to publish an application, using one APK at a time. In simple mode,
only one APK can be activated at a time. If you upload a new APK to update the application,
 clicking "Activate" on the new APK deactivates the currently active APK (you must then click Save to publish the new APK).

Advanced mode allows you to activate and publish multiple APKs that are each designed for
a specific set of device configurations. However, there are several rules based on the manifest declarations in each APK that determine
whether you're allowed to activate each APK along with others. When you activate an APK and it violates one of the rules,
you will receive an error or warning message. If it's an error, you cannot publish until you resolve the problem;
if it's a warning, you can publish the activated APKs, but there might be unintended consequences as to whether
your application is available for different devices. These rules are discussed more below.

Rules for multiple APKs

All APKs you publish for the same application must have the same package name and be signed with the same certificate key.
Each APK must have a different version code, specified by the android:versionCode attribute.
Each APK must not exactly match the configuration support of another APK.

That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).

Usually, you will differentiate your APKs based on a specific characteristic
(such as the supported texture compression formats), and thus, each APK will declare support for different devices. However, it's OK to publish multiple APKs that
overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will
receive the APK with a higher version code (defined by android:versionCode).
You cannot activate a new APK that has a version code lower than that of the APK it's replacing. For example, say you have an active APK for
screen sizes small - normal with version code 0400, then try to replace it with an APK for the same screen sizes with version code 0300.
This raises an error, because it means users of the previous APK will not be able to update the application.
An APK that requires a higher API level must have a higher version code.

Using a version code scheme

This diagram is most important to understand first two digits are API Levels and next is screen size and last is App version please Look at the diagram.

 compatible screens: for manifest file include for different APK files one for Tab other for mobile
This is for tablet
        <screen android:screenSize="large" android:screenDensity="ldpi"/>
        <screen android:screenSize="large" android:screenDensity="mdpi"  />
        <screen android:screenSize="large" android:screenDensity="hdpi"/>
        <screen android:screenSize="large" android:screenDensity="xhdpi"  />
        <screen android:screenSize="xlarge" android:screenDensity="ldpi"/>
        <screen android:screenSize="xlarge" android:screenDensity="mdpi"  />
        <screen android:screenSize="xlarge" android:screenDensity="hdpi"/>
        <screen android:screenSize="xlarge" android:screenDensity="xhdpi"  />      

This is for Mobile

        <screen android:screenSize="small" android:screenDensity="ldpi"/>
        <screen android:screenSize="small" android:screenDensity="mdpi"  />
        <screen android:screenSize="small" android:screenDensity="hdpi"/>
        <screen android:screenSize="small" android:screenDensity="xhdpi"  />
        <screen android:screenSize="normal" android:screenDensity="ldpi"/>
        <screen android:screenSize="normal" android:screenDensity="mdpi"  />
        <screen android:screenSize="normal" android:screenDensity="hdpi"/>
        <screen android:screenSize="normal" android:screenDensity="xhdpi"  />

Android: startActivity and startActivityForResult

Here are some differences between startActivity and startActivityForResult

1. startActvity will start the activity you want to start without worrying about getting any result from new child activity started by startActivity to parent activity.

2. startAcitvityForResult() starts another activity from your activity and it expect to get some data from newly started child activity  by startAcitvityForResult()  and return that to parent activity.

Monday, 14 July 2014

Types of broadcast :Local,Normal,Ordered and Sticky

Normal Broadcast
:- use sendBroadcast()
:- asynchronous broadcast
:- any receiver receives broadcast not any particular order
Ordered Broadcast
:- use sendOrderedBroadcast()
:- synchronous broadcast
:- receiver receives broadcast in priority base
:- we can also simply abort broadcast in this type
Local Broadcast
:- use only when broadcast is used only inside application
Sticky Broadcast
:- normal broadcast intent is not available any more after is was send and processed by the system.
:- use sendStickyBroadcast(Intent)
:- the corresponding intent is sticky, meaning the intent you are sending stays around after the broadcast is complete.
:- because of this others can quickly retrieve that data through the return value of registerReceiver(BroadcastReceiver, IntentFilter).
:- apart from this same as sendBroadcast(Intent).

How To Use startActivityForResult() in android


The next logical step in learning the Android development is to look at how can you call or invoke one activity from another and get back data from the called activity back to the calling activity. For simplicity sake, let us name the first calling activity as parent activity and the invoked activity as the child activity.

For simplicity sake, I use an explicit intent for invoking the child activity. For simple invocation without expecting any data back, we use the method startActivity(). However, when we want a result to be returned by the child activity, we need to call it by the method startActivityForResult(). When the child activity finishes with the job, it should set the data in an intent and call the method setResult(resultcode, intent) to return the data through the intent.

The parent activity should have overridden the method onActivityResult(…) in order to be able to get the data and act upon it. 

NOTE: for successful execution of this sequence of events, the child activity should call finish() aftersetResult(..) in order to give back the handle to the parent activity.

In summary, here are the methods to implement in the parent activity:
  • 1.  startActivtyForResult(..)
  • 2.  onActivityResult(…)

The child Activity should complete the work as usual and finally call:
  • 1.  setResult(…)
  • 2.  finish()

The startActivity() is not only used for migration and it also can carry data within..,

Intent intent = new Intent(1stActivity.this, 2ndActivity.class);
//here putExtra() method is used for carry some data
intent.putExtra("data_name", actual_data);

Now directly we can forward the data from one activity to another activity.

But if you wants to redirect to the 1st activity from the 2nd activity with data of 2nd activity we can use number of technology in Android like

  • Preference,
  • with the help of Bean,
  • startActivityForResult()

The Best & Simple way is to use startActivityForResult() method

Step-1 :

(In your 1st Activity class)
Use the syntax below When you want to move from the 1st Activity to the 2nd Activity

 use startActivityForResult() instead of using startActivity()

Intent intent= new Intent(1stActivity.this, 2ndActivity.class);
startActivityForResult(intent, 1);

//here we are passing two arguments the 1st one is Intent & the 2nd one is integer value for specification.

Step-2 :

(In your 2nd Activity class)

Use the Syntax below When you want to pass your data to the 1st Activity from the 2nd Activity

Intent i=new Intent();
setResult(1, i);
//here we are passing two arguments the 1st one is Intent & the 2nd one is integer value for specification.

Step-3 :

(In your 1st Activity class)

// override the onActivityResult() method

protected void onActivityResult(int requestCode, int resultCode, Intent data) 
super.onActivityResult(requestCode, resultCode, data);
//check with the int code specification 
//(in above activity we are using the integer value of "1")
if (requestCode == 1) 
if (null != data) 
String lst_of_sr = data.getStringExtra("data_name");
Toast.makeText(getApplicationContext(), lst_of_sr  Toast.LENGTH_LONG).show();
 Now you can back to the 1st activity with the data of 2nd activity.

Saturday, 12 July 2014

Android: Screen Densities, Sizes, Configurations, and Icon Sizes

1. Definitions

  • resolution = number of pixels available in the display, scale-independent pixel = sp
  • density = how many pixels appear within a constant area of the display, dots per inch = dpi
  • size = amount of physical space available for displaying an interface, screen's diagonal, inch
  • density-independent pixel = virtual pixel that is independent of the screen density, dp

2. Density Classes

ClassNameDensityFactorDrawable FolderComment
ldpilow density120 dpisp = 3/4 * dpdrawable-ldpi
mdpimedium density160 dpisp = dpdrawable-mdpi OR drawablebaseline size, example: 320x480 (sp or dp)
hdpihigh density240 dpisp = 1.5 x dpdrawable-hdpiexample: 480x800 sp = 320x533 dp
xhdpiextra high density320 dpisp = 2 x dpdrawable-xhdpi
xxhdpiextra extra high density480 dpisp = 3 x dpdrawable-xxhdpi
xxxhdpiextra extra extra high density640 dpisp = 4 x dpdrawable-xxxhdpi

3. Icon Sizes (full / content)

DensityLauncherMenuAction BarStatus Bar and NotificationTabPop-up Dialog and List ViewSmall and Contextual
ldpi36x36 px36x36 / 24x24 px24x24 / 18x18 px18x18 / 16x16 px24x24 / 22x22 px24x24 px12x12 / 9x9 px
mdpi48x48 px48x48 / 32x32 px32x32 / 24x24 px24x24 / 22x22 px32x32 / 28x28 px32x32 px16x16 / 12x12 px
hdpi72x72 px72x72 / 48x48 px48x48 / 36x36 px36x36 / 33x33 px48x48 / 42x42 px48x48 px24x24 / 18x18 px
xhdpi96x96 px96x96 / 64x64 px64x64 / 48x48 px48x48 / 44x44 px64x64 / 56x56 px64x64 px32x32 / 24x24 px
xxhdpi144x144 px(1)(1)(1)(1)(1)(1)
xxxhdpi192x192 px(1)(1)(1)(1)(1)(1)
  • (1) Google documentation says: "Applications should not generally worry about this density; relying on XHIGH graphics being scaled up to it should be sufficient for almost all cases."
  • Launcher icons for Android Market: 512x512 px.

4. Screen Size Classes

ClassSize in dpLayout FolderExamplesComment
small426x320 dplayout-smalltypical phone screen (240x320 ldpi, 320x480 mdpi, etc.)
normal470x320 dplayout-normal OR layouttypical phone screen (480x800 hdpi)baseline size
large640x480 dplayout-largetweener tablet like the Streak (480x800 mdpi), 7" tablet (600x1024 mdpi)
xlarge960x720 dplayout-xlarge10" tablet (720x1280 mdpi, 800x1280 mdpi, etc.)

5. Example Screen Configurations

Screen SizeLow density (120), ldpiMedium density (160), mdpiHigh density (240), hdpiExtra high density (320), xhdpi
smallQVGA (240x320)
normalWQVGA400 (240x400)
WQVGA432 (240x432)
HVGA (320x480)WVGA800 (480x800)
WVGA854 (480x854)
largeWVGA800 (480x800)(2)
WVGA854 (480x854)(2)
WVGA800 (480x800)(1)
WVGA854 (480x854)(1)

xlarge1024x600WXGA (1280x800)(3)
  • (1) To emulate this configuration, specify a custom density of 160 when creating an Android Virtual Device that uses a WVGA800 or WVGA854 skin.
  • (2) To emulate this configuration, specify a custom density of 120 when creating an Android Virtual Device that uses a WVGA800 or WVGA854 skin.
  • (3) This skin is available with the Android 3.0 platform.

6. Screen Orientation

OrientationNameLayout Folder, Example
landlandscapelayout-land-normal OR layout-land

7. Best Practices

  1. Use wrap_content, match_parent, or dp units when specifying dimensions in an XML layout file.
    • except for defining text sizes: sp (scaling depends on user setting)
    • Note: fill_parent is deprecated since API level 8.
  2. Do not use hard coded pixel values in your application code.
  3. Do not use AbsoluteLayout.
    • deprecated since Android 1.5
    • alternative: RelativeLayout
  4. Supply alternative bitmap drawables for different screen densities.
  5. Provide a launcher icon for xxhdpi, but no other icons.