Android - How to Kill the application on back button press.

The easiest way to do this is to clear all the top activities and call the finish() on the activities. The below code needs to be done by overriding the onBackPressed method.

    Intent intent = new Intent(this, LaunchActivity.class);
    intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    intent.putExtra("Exit", true);
    startActivity(intent);
    finish();

On the launch activity, now we need to have the below code at the end of onCreate, note that should not spin any new thread in the OnCreate method.

    if( getIntent().getBooleanExtra("Exit", false)){
        finish();
    }

In some cases, we may not want to have back traces left for specific activity on the activity stack. In such cases, we can just have the below code for each activity in the Android Manifest xml. for e.g. SplashScreen , Login Screen etc.

android:noHistory="true"

One another way is to have the homescreen shown while the app activity is not forcefully finished. The code below should be placed on OnBackPressed overriden method.

Intent a = new Intent(Intent.ACTION_MAIN);
a.addCategory(Intent.CATEGORY_HOME);
a.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(a);


references:
http://stackoverflow.com/questions/3226495/how-to-exit-from-the-application-and-show-the-home-screen

Over the Air Profile Delivery concepts

There are three phases involved in this:

1. authentication

2. enrollment

3. device configuration 

Authentication Phase (Phase 1):

Two main aims of this step are

1. Ensure the enrolment request is from valid entity 

2. It captures info about user’s device for use in the certificate enrolment process. 

The steps involved in this are: 

1. User visits the root URL and receives a welcome message. 

2. The user visits the certificate authority URL (/CA) to get the root cert. 

3. The user visits the enrolment URL (/enroll) to start the enrolment process. In this step, user is prompted to authenticate himself or herself using HTTP basic authentication or using existing directory services. 

4. The server’s enrolment handler determines whether the user is allowed to enrol the device. If allowed, server sends a profile service payload. The service payload (.mobileconfig) contains a request for additional device-specific information that device must provide in next step. The payload may include a Challenge token (optional) so that the server can associate the request with the original user. This allows one to customise the configuration process for each user, if desired. 

The device attributes that the service can request are the iOS version, WiFi device ID, product type, phone equipment ID, and SIM card Identifier.  

Certificate Enrolment (X.509 Identities and SCEP) - Phase 2

In the enrolment phase, device contacts the CA and obtains a signed X.509 identify cert, which is used for encryption. 

To acquire an identity, a device first generates an asymmetric key and stores it in its keychain. The secret in this keychain can be read only by that specific device

The device then sends it public key to CA and sends back the signed X.509 certificate. This certificate then combined with the private key on device forms the identify.

The above exchange is possible because iOS supports SCEP. SCEP is a communication protocol that provides a networked front end to a private certificate authority. Support for SCEP is provided by a number of CAs and there are complete open source software of certificate authorities with SCEP support. 

Below are the steps in enrolment phase

1. The user accepts the installation of the profile from phase 1 

2. The device looks up the requested attributes, adds the challenge response (if provided), signs the response using Apple’s built in identity and sends it back to the profile distribution service using POST .

3. The server’s profile request handler sends back a configuration profile that instructs the device to enrol using SCEP.

4. The device Enrolls using SCEP, resulting in a valid identity certificate installed on device. 

Device Configuration and Encrypted Profiles (Phase 3)

This is the phase where the actual profile itself is delivered. The profile that is delivered will be customised for the requested device. To provide protection, iOS allows to encrypt the profile so that they can be installed only on single device. 

An encrypted profile is just like a normal profile except the configuration profile is encrypted with the public key associated with the device’s X.509 identity. 

For encryption and and signing, iOS uses the Cryptographic Message Syntax (CMS) a standard that is also used in S/MIME. Payloads are encrypted using PKCS#7 enveloped data. Profiles are signed using PKCS#7 signed data. 

The steps in the device configuration phase are: 

1. The device sends a signed request for the /profile handler again to request the final profile. The request is signed with the identity certificate obtained in the previous step. 

2. The server profile handler sends the final encrypted profile to the device. 

references:

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1

Android, ImageView Does not fill the parent

Below needs to be done so that the ImageView scales appropriately. scaleXY is important 

<imageview android:id="@+id/image_tag&#8221; android:layout_width=" android:layout_height="wrap_content" android:layout_marginleft="20dp" android:layout_marginright="20dp" android:src="@drawable/bg_image&#8221; android:scaleType=" fill_parent="" fitxy=""> </imageview>

references:

http://stackoverflow.com/questions/11510804/imageview-wont-fill-parent