Eclipse Error : Using 1.7 requires using Android Build Tools version 19 or later; currently using 17.0.0 ?

The project shows this error when relevant build tool is not set for the Project.
First goto Eclipse-->Windows--->Android SDK Manager and installed the relevant build tool required by the application.After installation is completed close the SDK manager.

Then add the below line in "project.properties" file of then prject.Error will be resolved.

sdk.buildtools=19.1

Android Host Card Emulation(HCE) in 4.4 ?

 FAQ

Q> What is HCE?

A> Host-Based Card Emulation

Er... whats that??

Before we talk about HCE (Host-Based Card Emulation) we must understand what is CE (Card Emulation)

Card Emulation is as it says emulation of a card (CreditCard/ ID Card/ Loyalty Card / any card) over NFC interface of a mobile phone.

In this mode a mobile NFC can exchange APDU (Data) with the a POS (Payment Terminals) or any other Terminal (eg. Security Machine on Doors or a Time punching machine for your office )

Alright!! I understand NFC but whats Card Emulation?

A card in this refers to a an environment which is created with the help of secure element, and applets.

Woaahhh 2 NEW TERMS!!!

Secure Element:  In simplest words.. Its a memory + processor + Mini OS which is out of phone OS, is highly restricted for access and is believed to be non-hackable!

Applets: Nothing more than small Java Programs which can run on this Mini OS of Secure Element. Which communicates based on Hexadecimal Commands also known as APDU.

So when you use your credit card or even a sim card remember "YOU GOT THE POWER" of secure element in your hands. Yeah that a freaking complete Operating system which is super secure in your hand.

Ok.. so??

So Card Emulation basically says that in order to communicate with this Card (Secure Element + Applets) the Phone NFC will accept the commands, will send these commands to Card residing somewhere in the phone and then will forward the responses generated from this Card over NFC interface back to the terminal.(See Dig.2)

Now to ease things up Card can be present in 3 of these location

1. Embedded Secure Element

2. SDCard based Secure Element

3. UICC (SIM Card)

Kool!! then why do we need HCE?

The biggest advantage is also the biggest disadvantage for Secure Element, being highly restricted, any addition of deletion of data needs heck of approvals from the provider of these.

For example: In case of UICC based Secure Element, only the MNO (mobile Network Operator) who owns a SIM card is authorised to put your CreditCard data inside the secure element, BUT, the CreditCard belongs to a Issuer (Bank) therefore in-order to put one simple CreditCard inside a secure element you need Bank and MNO to come together and work together. No wonder you don't see many application which uses any of these technologies.

Now with HCE, there is no need for Secure Element, I mean you can work even without them.

Now the data can directly be sent and received by an application, your own phone application.(See Dig.3)

Overview on Host Card Emulation (HCE)

HCE is an open architecture that allows mobile applications to emulate a contactless smartcard. Unlike traditional NFC transactions that rely an embedded or SIM card Secure Element (SE), HCE is a purely software-based solution. This new approach is significant for the industry because: 1) it takes control away from mobile network operators (MNOs) who control access to a mobile device’s SE and, 2) it creates new possibilities for using a phone’s NFC feature.

Host Card Emulation (HCE) as an exciting development for the NFC market because it provides an additional means by which to perform NFC transactions. With HCE, transactions take place using credentials stored in the cloud or on the host processor of the NFC-enabled mobile device rather than a tamper resistant Secure Element, such as an embedded security chip, SIM, or microSD card.

HCE works by storing payment credentials on a remote cloud rather than the SE (see Figure 1). Conceptually, a mobile application could be programed to send requests to allow access to these credentials via a secure token. This token would then be passed via the phone’s NFC antennae to another contactless reader to complete a payment transaction. A key requirement is ensuring that the token is recognized by the reader as a valid payment credential.

Dig.1

This development may prove troubling to some mobile wallets, like the Mobile Network Operator-led Isis, which relies on the SE approach.Isis currently requires card issuers to integrate with a Trusted Service Manager (TSM) to facilitate access to a device’s SE.HCE provides an alternative to TSM integration, which can be expensive and time consuming. To date, only a few European banks have explored HCE deployment, but there are service providers that are prepared to enable similar solutions in the U.S. market. Visa and MasterCard have also independently announced their intentions to provide software development kits (SDKs) that would allow issuers and other potential wallet providers to write HCE applications that conform to the existing contactless payment specifications.

Host Card Emulation (HCE) as an exciting development for the NFC market because it provides an additional means by which to perform NFC transactions. With HCE, transactions take place using credentials stored in the cloud or on the host processor of the NFC-enabled mobile device rather than a tamper resistant Secure Element, such as an embedded security chip, SIM, or microSD card.As the definition suggests, it is an emulation of a contactless smart card. What is the capability of a contactless smart card? Mainly payment, identification and transportation. What happens when one of these cards, say your id card, which you use for entering your office building is just an app on your mobile phone? Or your contactless credit/debit card? Sounds intriguing.

Before HCE, contactless smart card was being emulated by a hardware chip and software (mobile app) was needed for the hardware to be activated. Hardware component was either a chip embedded on the phone or the SIM card. Either way, a few more parties other than the owner of the handset itself was involved in the game and it was quite complicated to activate and use the NFC app. Now with the HCE, smart card is still being emulated but this time it is software rather than the hardware.

In the hardware mode, contactless (NFC) reader was working with the secure element.

 Dig.2

Now with the HCE, hardware component -SE or the embedded chip is not needed. Android itself emulates the hardware. Apps will use the interface provided by the operating system again but this time there is no hardware below the API.

Dig.3

How to Load Apps or Apk on Google Glass ?

For this tutorial we will show you how install Google Sky (also known as stardroid) without rooting your Glass or swapping roms. This is the same basic procedure you would go through to manually load an app on an Android phone, but since Google Glass has a limited amount of input, the specific app you install matters. 

Before we begin it is important that you already have the Android SDK, most importantly you need ADB (android debug bridge). You also need to be somewhat familiar with opening a new terminal window. We will work for Linux and might need a little modification for Windows. We also assume you download files to your home Download directory, but you can change this as needed. (~/Downloads)

Download and Install the Android SDK (http://developer.android.com/sdk/index.html). We find it helpful to have adb in your PATH so you can call it from anywhere (you may want to add it to your .bashrc or whatever you are using).

export PATH=$PATH:~/Downloads/adt-bundle-mac-x86_64-20130514/sdk/platform-tools

First things first, Put your Glass in “Debug Mode” in the settings on the Glass itself. Locate the device info and scroll right to turn Debug Mode on. Then plug your Glass into your computer using the USB micro cable.

Now grab a version of Google Sky that you want to install (this is the same for any Android .apk file).

wget http://file.appsapk.com/wp-content/uploads/apps-2/Google%20Sky%20Map.apk

Simply load the .apk file onto the Glass with adb.

adb install ~/Downloads/Google\ Sky\ Map.apk

After the .apk is loaded onto Glass you now need to use adb shell to run it. The trick here is that you need to figure out what Activity to run. You can use the adb command dumpsys to discover a plethora of information about your Glass. You can figure out the main activity for the .apk with a little help from grep, and since it was the last thing loaded we can also narrow this information down with a tail command.

adb shell dumpsys | grep android.intent.action.MAIN | tail -n 2

This might take some time depending on your system, but it will eventually return something similar to this:

intent={act=android.intent.action.MAIN flg=0×10000000 cmp=com.google.android.stardroid/.activities.SplashScreenActivity}

android.intent.action.MAIN:

You now have the right information to start the app on Glass. We use the am command to start the app on Glass. Simply reformat the Activity call to follow the same format as the stardroid example call below:

adb shell am start -a android.intent.action.MAIN -n com.google.android.stardroid/com.google.android.stardroid.activities.SplashScreenActivity

At this point tap your Glass on and the app should be running. You will need to “down swipe” on your glass to cancel the agreement window. If you see the app running, disconnect, go outside, and check this out at nighttime! Warning: you may feel like a terminator with some kind of super power.

Note: this is not part of the Official Glass Mirror API that is displayed on your timeline and running apps full time like this is a drain on the battery, which is not in Google’s application design guidelines. It merely demonstrates how to sideload an app on Glass in your terminal without voiding your warranty.

How to get SHA certificate in Windows ?

C:\Program Files (x86)\Java\jdk1.6.0_06\bin>keytool -v -list -keystore C:\Users\sshukla\.android\debug.keystore -alias androiddebugkey -storepass android -keypass android
Alias name: androiddebugkey
Creation date: Apr 18, 2013
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Android Debug, O=Android, C=US
Issuer: CN=Android Debug, O=Android, C=US
Serial number: 64bbfdff
Valid from: Thu Apr 18 14:56:16 IST 2013 until: Sat Apr 11 14:56:16 IST 2043
Certificate fingerprints:
         MD5:  75:73:CC:22:4C:C0:EB:04:6A:C5:63:89:57:66:DC:DB
         SHA1: 8A:C7:3A:96:2E:4E:D2:F0:C6:B0:AB:1D:A2:FE:DA:6E:E2:71:8F:CD
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EF 85 F0 F3 11 65 7A D3   C7 66 10 21 BE 85 DB 69  .....ez..f.!...i
0010: 8B 9A 7A 07                                        ..z.
]
]


C:\Program Files (x86)\Java\jdk1.6.0_06\bin>

APNS SSL Error - javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure?

1. Created certificates from mac machine
2. in tomcat server application using JavaPNS to send the notification
Used Push.alert(...) used .p12 file


javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

I finally find the problem is due to the p12 certificate. We should not use the private key p12 file, instead we
should generate a p12 from your private key and the cert download from Apple.

Please execute the following OpenSSL command to get the correct p12 file

developer_identity.cer <= download from Apple
mykey.p12 <= Your private key

1) openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM
- developer_identity.cer = the .cer file obtained from developer.apple.com site.
- developer_identity.pem = the "PEM" output file name.

2) openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem.
- mykey.p12 = the (.p12) file obtained initially from exporting (.cer) file.
- mykey.pem = the "PEM" output file name.

3) openssl pkcs12 -export -inkey mykey.pem -in developer_identity.pem -out iphone_dev.p12
- mykey.pem = the "PEM" file obtained in step (2).
- developer_identity.pem = the "PEM" file obtained in step (1).
- iphone_dev.p12 = the final (.p12) file, to be used at backend server side.

After that, you should use iphone_dev.p12 to communicate with apple server.

Convert Seconds into HH:MM:SS in java?

Below are the methods to convert seconds into minute seconds format...


int day = (int)TimeUnit.SECONDS.toDays(seconds);      
long hours = TimeUnit.SECONDS.toHours(seconds) - (day *24);
long minute = TimeUnit.SECONDS.toMinutes(seconds) - (TimeUnit.SECONDS.toHours(seconds)* 60);
long second = TimeUnit.SECONDS.toSeconds(seconds) - (TimeUnit.SECONDS.toMinutes(seconds) *60);
 System.out.println("Random Element "+minute+":"+second);

OR 

public static void calculateTime(long seconds) {
   int day = (int) TimeUnit.SECONDS.toDays(seconds);
   long hours = TimeUnit.SECONDS.toHours(seconds) -
                TimeUnit.DAYS.toHours(day);
   long minute = TimeUnit.SECONDS.toMinutes(seconds) -
                 TimeUnit.DAYS.toMinutes(day) -
                 TimeUnit.HOURS.toMinutes(hours);
   long second = TimeUnit.SECONDS.toSeconds(seconds) -
                 TimeUnit.DAYS.toSeconds(day) -
                 TimeUnit.HOURS.toSeconds(hours) -
                 TimeUnit.MINUTES.toSeconds(minute);
   System.out.println("Day " + day + " Hour " + hours + " Minute " + minute + " Seconds " + second);
}

Android serialization of Objects ?

We can also see below links...
http://www.dreamincode.net/forums/topic/248522-serialization-in-android/

I'm going to go through the process of serializing and deserializing an object.

What this means is that we're going to convert an object into an array of bytes, which can easily be moved around or stored (for later use). And for deserialization we just take those bytes and convert them back into an Object.

The first one we have below is the serialization method, which just takes in a generic Object.


  public static byte[] serializeObject(Object o) {
    ByteArrayOutputStream bos = new ByteArrayOutputStream();

    try {
      ObjectOutput out = new ObjectOutputStream(bos);
      out.writeObject(o);
      out.close();

      // Get the bytes of the serialized object
      byte[] buf = bos.toByteArray();

      return buf;
    } catch(IOException ioe) {
      Log.e("serializeObject", "error", ioe);

      return null;
    }
  }

The second one is the deserialization method, which takes in an array of bytes;


  public static Object deserializeObject(byte[] b) {
    try {
      ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(b));
      Object object = in.readObject();
      in.close();

      return object;
    } catch(ClassNotFoundException cnfe) {
      Log.e("deserializeObject", "class not found error", cnfe);

      return null;
    } catch(IOException ioe) {
      Log.e("deserializeObject", "io error", ioe);

      return null;
    }
  }

If you're wondering how to use these, well here is an example.


  public class Bla implements Serializable {
    public String blaDate;
    public String blaText;
  }
 
  Bla bla = new Bla();
 
  // assuming that both those serialize and deserialize methods are under the SerializerClass
  byte[] blaBytes = SerializerClass.serializeObject(bla);
 
  Bla deserializedBla = (Bla) SerializerClass.deserializeObject(blaBytes);

You've probably noticed that I implemented Serializable - you need this in order to serialize an object. Some of the built in objects already have this implemented - for example the ArrayList object.

When deserializing you need to cast it back to what the object was, since it's returning it as a generic Object - hence the (Bla).
Anyways, hope this helped someone, and if you noticed any mistakes, please let me know.