Pages Navigation Menu

Coding is much easier than you think

Conversion to dalvik format failed with error 1 : Android Error

Posted by on Apr 19, 2013 in Android | 0 comments


java.lang.IllegalArgumentException: already added: package/MyClassclass; [2011-01-19 14:54:05 – …]: Dx1 error; aborting [2011-01-19 14:54:05 – …] Conversion to Dalvik format failed with error 1


Go to Project » Properties » Java Build Path » Libraries and remove all except the “Android X.Y” (in my case Android 1.5). click OK. Go to Project » Clean » Clean projects selected below » select your project and click OK. That should work.

It is also possible that you have a JAR file located somewhere in your project folders (I had copied the Admob JAR file into my src folder) and THEN added it as a Java Path Library. It does not show up under the Package Explorer, so you don’t notice it, but it does get counted twice, causing the dreaded Dalvik error 1.
** UPDATE: Android Complete tutorial now available here.
Another possible reason could be package name conflicts. Suppose you have a package and a class named inside this package, and another library project (which is added to the dependency of this project) which contains the same, then you will be getting the exact same error. This means, you have multiple references to the same file and can’t properly build it.

Windows 7 Solution:

Confirmed the problem is caused by ProGuard command line in the file,

[Android SDK Installation Directory]toolsproguardbinproguard.bat

Edit the following line will solve the problem:

call %java_exe% -jar "%PROGUARD_HOME%"libproguard.jar %*


call %java_exe% -jar "%PROGUARD_HOME%"libproguard.jar %1 %2 %3 %4 %5 %6 %7 %8 %9

Here’s another scenario, and solution:

If you run into this problem recently after updating the ADT for Eclipse:

In your app project, check for any linked source folders pointing to your library projects (they have names in the form “LibraryName_src”).

Select all those projects, right-click, choose “Build Path”->”Remove from Build Path”. Choose “Also unlink the folder from the project”, and click “Yes”. Clean, rebuild and redeploy the project.

It seems the reason is that some previous version of ADT linked Library project source folders to the “child” projects, and the current ADT/Dex combination isn’t compatible with that solution anymore.


Read More

How do you enable a microphone input in the android emulator?

Posted by on Apr 19, 2013 in Android | 0 comments

If you are trying to get the audio from Android emulator, you can not be successful. You can try this with different ways like by writing a custom speech to text application, by trying to compile voice recognition sample at Android SDK or by using in-built Speech Recorder on a Google API supported android emulator.
** UPDATE: Android Complete tutorial now available here.
You would have given proper permission and you might have also selected Audio play back support in Hardware selection in creating new AVD (Android Virtual Device).

Actual Reason :You are not able to record sound and use MIC in emulator because the android emulator doesn€™t support it yet. The Android Emulator does not have the ability to capture audio, but actual devices are likely to provide these capabilities. Source Android Documentation

For the original path of this information follow this link :

Solution : Only possible solution is connect the real device to System , Check Developer option in phone , enable USB Debugging and use it as emulator .
Read More

How to call Android contacts list and Display his name and Phone Number after selection?

Posted by on Apr 19, 2013 in Android | 0 comments

There are three steps to this process.

1) Permissions

Add a permission to read contacts data to your application manifest.

2) Calling the Native Contact Picker

Android already has behavior built in to select contacts. This is used to select contacts for phone calls and other native apps. But it can also be used by apps like yours so you don’€™t have top build it yourself. Intents are a generic mechanism for invoking an action that the system can respond to. When the Android action code processed that Intent, it saw the reference to the Activity and invoked it directly. You don’€™t actually have to include a reference to an Activity in an Intent. You can also supply a Uri or a combination of Uri and an Action. And if you invoke the Intent, the Android action code looks for an Activity that responds to that Uri and invokes it.
** UPDATE: Android Complete tutorial now available here.
Within your Activity, create an Intent that asks the system to find an Activity that can perform a PICK action from the items in the Contacts URI.

Intent intent = new Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI);

Call startActivityForResult, passing in this Intent (and a request code integer, PICK_CONTACT in this example). This will cause Android to launch an Activity that’s registered to support ACTION_PICK on the People.CONTENT_URI, then return to this Activity when the selection is made (or canceled).

startActivityForResult(intent, PICK_CONTACT);

3) Listening for the Result

Also in your Activity, override the onActivityResult method to listen for the return from the ‘select a contact’ Activity you launched in step 2. You should check that the returned request code matches the value you’re expecting, and that the result code is RESULT_OK.

You can get the URI of the selected contact by calling getData() on the data Intent parameter.

When you print URI , it will be like this

08-10 15:44:52.131: DEBUG/Intent Data(355): content://

To get the name of the selected contact you need to use that URI to create a new query and extract the name from the returned cursor.


public void onActivityResult(int reqCode, int resultCode, Intent data) {

super.onActivityResult(reqCode, resultCode, data);

switch (reqCode) {


if (resultCode == Activity.RESULT_OK) {

Uri contactData = data.getData();

Cursor c =  managedQuery(contactData, null, null, null, null);

if (c.moveToFirst()) {

String name = c.getString(c.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME));

// TODO Whatever you want to do with the selected contact name.


4 ) Display Phone Number

There is two steps to get Phone Number :

First we will get id for the selected contact through ContentResolver passing URI .
Second we will query ContentResolver for all phone numbers using android constant “ContactsContract.CommonDataKinds.Phone.CONTENT_URI” and adding where class through previous got id.

public void onActivityResult(int reqCode, int resultCode, Intent data) {

super.onActivityResult(reqCode, resultCode, data);

switch (reqCode) {


if (resultCode == Activity.RESULT_OK) {

Uri contactData = data.getData();
		Cursor contactCursor = getContentResolver().query(uri,
				new String[] { ContactsContract.Contacts._ID }, null, null,
		String id = null;
		if (contactCursor.moveToFirst()) {
			id = contactCursor.getString(contactCursor
		String phoneNumber = null;
		Cursor phoneCursor = getContentResolver().query(
				new String[] { ContactsContract.CommonDataKinds.Phone.NUMBER },
				ContactsContract.CommonDataKinds.Phone.CONTACT_ID + "= ? ",
				new String[] { id }, null);
		if (phoneCursor.moveToFirst()) {
			phoneNumber = phoneCursor



Read More

To find list of permissions used by an installed application in android

Posted by on Apr 19, 2013 in Android | 0 comments

The below code not only retrieves the permission  , but will also retrieve services , receivers . Be  careful on PackageManager tags. This will only fetch you the corresponding information on specific packages .


PackageManager p = this.getPackageManager();
  final List < PackageInfo>; appinstall=p.getInstalledPackages(PackageManager.GET_PERMISSIONS|PackageManager.GET_RECEIVERS|

  for(PackageInfo pInfo:appinstall){
      //PermissionInfo[] permission=pInfo.permissions;
       String[] reqPermission=pInfo.requestedPermissions;
       ProviderInfo[] providers=pInfo.providers;

  int versionCode=pInfo.versionCode;
  Log.d("versionCode-package ",Integer.toString(versionCode));
  Log.d("Installed Applications", pInfo.applicationInfo
    for(int i=0;i < reqPermission.length;i++)
       Log.d("permission list",reqPermission[i]);


Read More

How to get a list of installed android applications in Android

Posted by on Apr 19, 2013 in Android | 0 comments

Starting from the your Activity context you can obtain an instance of PackageManager through the method called  getPackageManager(). Using that class is it possible to get a list of ApplicationInfo objects containing details about apps such as MetaData, Permissions, Services or Activities.

Flag are very import for PackageManager .For example  PackageManager.GET_META_DATA will retrieve only meta data for all packages .

Useful data are for example the name of the app, the packageName used to retrieve additional information with PackageManager methods and the publicSourceDir that represent a simple way to identify system or user applications.
** UPDATE: Android Complete tutorial now available here.
Method 1:

final Intent mainIntent = new Intent(Intent.ACTION_MAIN, null);
final List pkgAppsList = context.getPackageManager().queryIntentActivities( mainIntent, 0);

Method 2:

final PackageManager pm = getPackageManager();
//get a list of installed apps.
List packages = pm.getInstalledApplications(PackageManager.GET_META_DATA);

for (ApplicationInfo packageInfo : packages) {
    Log.d(TAG, "Installed package :" + packageInfo.packageName);
    Log.d(TAG, "Launch Activity :" + pm.getLaunchIntentForPackage(packageInfo.packageName)); 

Method 3:Using ResolveInfo

private List getInstalledComponentList()
            throws NameNotFoundException {
        final Intent mainIntent = new Intent(Intent.ACTION_MAIN, null);
        List ril = getPackageManager().queryIntentActivities(mainIntent, 0);
        List componentList = new ArrayList();
        String name = null;

        for (ResolveInfo ri : ril) {
            if (ri.activityInfo != null) {
                Resources res = getPackageManager().getResourcesForApplication(ri.activityInfo.applicationInfo);
                if (ri.activityInfo.labelRes != 0) {
                    name = res.getString(ri.activityInfo.labelRes);
                } else {
                    name = ri.activityInfo.applicationInfo.loadLabel(
        return componentList;
Read More

Difference between minsdkversion and targetsdkversion

Posted by on Apr 16, 2013 in Android | 0 comments



An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system’s API Level is lower than the value specified in this attribute. You should always declare this helps Google Play filter apps for the user based on their device. For instance, with minSdkVersion=”7″, someone browsing with a device that only supports 6 won’t see your app on Google Play, and thus won’t download it, find it doesn’t work, and leave a bad review :)



An integer designating the API Level that the application is targetting.

With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here. Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications. This does not mean that you can program different features for different versions of the platform €”it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.

android:targetSdkVersion is a signal to the device about which version of the API your app was tested against. New behaviors are often available by default with new versions of the platform, for applications that target at least that version of the platform. For instance, by setting your targetSdkVersion to 11 or higher, you get an overflow menu in the ActionBar (for Honeycomb and up devices) instead of the “legacy menu button of shame”. target is a signal to your local build system regarding which version of the platform you should be compiling your code against. Generally it’s best to just set this to whatever you have set for the targetSdkVersion.



An integer designating the maximum API Level on which the application is designed to run.

In Android 1.5, 1.6, 2.0, and 2.0.1, the system checks the value of this attribute when installing an application and when re-validating the application after a system update. In either case, if the application’s maxSdkVersion attribute is lower than the API Level used by the system itself, then the system will not allow the application to be installed. In the case of re-validation after system update, this effectively removes your application from the device.

To illustrate how this attribute can affect your application after system updates, consider the following example:

An application declaring maxSdkVersion="5" in its manifest is published on Google Play. A user whose device is running Android 1.6 (API Level 4) downloads and installs the app. After a few weeks, the user receives an over-the-air system update to Android 2.0 (API Level 5). After the update is installed, the system checks the application’s maxSdkVersion and successfully re-validates it. The application functions as normal. However, some time later, the device receives another system update, this time to Android 2.0.1 (API Level 6). After the update, the system can no longer re-validate the application because the system’s own API Level (6) is now higher than the maximum supported by the application (5). The system prevents the application from being visible to the user, in effect removing it from the device.

You have to maintain backward compactiblity through your code:

In short, here is the purpose to declaring a different targetSDK from the minSDK: It means you are using features from a higher level SDK than your minimum, but you have ensured backwards compatibility. In other words, imagine that you want to use a feature that was only recently introduced, but that isn’t critical to your application. You would then set the targetSDK to the version where this new feature was introduced and the minimum to something lower so that everyone could still use your app.

To give an example, let’s say you’re writing an app that makes extensive use of gesture detection. However, every command that can be recognised by a gesture can also be done by a button or from the menu. In this case, gestures are a ‘cool extra’ but aren’t required. Therefore you would set the target sdk to 7 (“Eclair” when the GestureDetection library was introduced), and the minimumSDK to level 3 (“Cupcake”) so that even people with really old phones could use your app. All you’d have to do is make sure that your app checked the version of Android it was running on before trying to use the gesture library, to avoid trying to use it if it didn’t exist. (Admittedly this is a dated example since hardly anyone still has a v1.5 phone, but there was a time when maintaining compatibility with v1.5 was really important.)

To give another example, you could use this if you wanted to use a feature from Gingerbread or Honeycomb. Some people will get the updates soon, but many others, particularly with older hardware, might stay stuck with Eclair until they buy a new device. This would let you use some of the cool new features, but without excluding part of your possible market

Read More