Manifest Assurance: Security and Android Permissions for Flash

Exclusive offer: get 50% off this eBook here
Flash Development for Android Cookbook

Flash Development for Android Cookbook — Save 50%

Over 90 recipes to build exciting Android applications with Flash, Flex, and AIR

$29.99    $15.00
by Joseph Labrecque | June 2011 | Cookbooks

Android has in place a very specific permissions and security system based around manifest file declarations which allow or restrict applications from accessing various device capabilities. This article by Joseph Labrecque, author of Flash Development for Android Cookbook, will detail how to enable your Flash Platform applications to correctly identify the permissions needed to take advantage of the Android Market filtering, apply local application database encryption, and other useful tidbits!

This article will cover the following recipes:

  • Setting application permissions with the Android Manifest file
  • Preventing the device screen from dimming
  • Establishing Android Custom URI Schemes
  • Anticipating Android Compatibility Filtering
  • Instructing an Application to be installed to Device SDCard
  • Encrypting a Local SQLite Database

 

Flash Development for Android Cookbook

Flash Development for Android Cookbook

Over 90 recipes to build exciting Android applications with Flash, Flex, and AIR

        Read more about this book      

(For more resources on this subject, see here.)

Setting application permissions with the Android Manifest file

When users choose to install an application on Android, they are always presented with a warning about which permissions the application will have within their particular system. From Internet access to full Geolocation, Camera, or External Storage permissions; the user is explicitly told what rights the application will have on their system. If it seems as though the application is asking for more permissions than necessary, the user will usually refuse the install and look for another application to perform the task they need. It is very important to only require the permissions your application truly needs, or else users might be suspicious of you and the applications you make available.

How to do it...

There are three ways in which we can modify the Android Manifest file to set application permissions for compiling our application with Adobe AIR.

Using Flash Professional:

Within an AIR for Android project, open the Properties panel and click the little wrench icon next to Player selection:

Android Manifest Assurance for Flash Development

The AIR for Android Settings dialog window will appear. You will be presented with a list of permissions to either enable or disable for your application. Check only the ones your application will need and click OK when finished.

Android Manifest Assurance for Flash Development

Using Flash Builder:

  1. When first setting up your AIR for Android project in Flash Builder, define everything required in the Project Location area, and click Next.
  2. You are now in the Mobile Settings area of the New Flex Mobile Project dialog. Click the Permissions tab, making sure that Google Android is the selected platform. You will be presented with a list of permissions to either enable or disable for your application. Check only the ones your application will need and continue along with your project setup:

    Android Manifest Assurance for Flash Development

  3. To modify any of these permissions after you've begun developing the application, simply open the AIR descriptor file and edit it as is detailed in the following sections.

Using a simple text editor:

  1. Find the AIR Descriptor File in your project. It is normally named something like {MyProject}-app.xml as it resides at the project root.
  2. Browse the file for a node named <android> within this node will be another called <manifestAdditions> which holds a child node called <manifest>. This section of the document contains everything we need to set permissions for our Android application.
  3. All we need to do is either comment out or remove those particular permissions that our application does not require. For instance, this application needs Internet, External Storage, and Camera access. Every other permission node is commented out using the standard XML comment syntax of <!-- <comment here> -->:

    <uses-permission name="android.permission.INTERNET"/>
    <uses-permission name="android.permission.WRITE_EXTERNAL_
    STORAGE"/>
    <!--<uses-permission name="android.permission.READ_PHONE_
    STATE"/>-->
    <!--<uses-permission name="android.permission.ACCESS_FINE_
    LOCATION"/>-->
    <!--<uses-permission name="android.permission.DISABLE_
    KEYGUARD"/>-->
    <!--<uses-permission name="android.permission.WAKE_LOCK"/>--
    >
    <uses-permission name="android.permission.CAMERA"/>
    <!--<uses-permission name="android.permission.RECORD_
    AUDIO"/>-->
    <!--<uses-permission name="android.permission.ACCESS_
    NETWORK_STATE"/>-->
    <!--<uses-permission name="android.permission.ACCESS_WIFI_
    STATE"/>-->

How it works...

The permissions you define within the AIR descriptor file will be used to create an Android Manifest file to be packaged within the .apk produced by the tool used to compile the project. These permissions restrict and enable the application, once installed on a user's device, and also alert the user as to which activities and resources the application will be given access to prior to installation. It is very important to provide only the permissions necessary for an application to perform the expected tasks once installed upon a device.

The following is a list of the possible permissions for the Android manifest document:

  • ACCESS_COARSE_LOCATION: Allows the Geoloctaion class to access WIFI and triangulated cell tower location data.
  • ACCESS_FINE_LOCATION: Allows the Geolocation class to make use of the device GPS sensor.
  • ACCESS_NETWORK_STATE: Allows an application to access the network state through the NetworkInfo class.
  • ACCESS_WIFI_STATE: Allows and application to access the WIFI state through the NetworkInfo class.
  • CAMERA: Allows an application to access the device camera.
  • INTERNET: Allows the application to access the Internet and perform data transfer requests.
  • READ_PHONE_STATE: Allows the application to mute audio when a phone call is in effect.
  • RECORD_AUDIO: Allows microphone access to the application to record or monitor audio data.
  • WAKE_LOCK: Allows the application to prevent the device from going to sleep using the SystemIdleMode class. (Must be used alongside DISABLE_KEYGUARD.)
  • DISABLE_KEYGUARD: Allows the application to prevent the device from going to sleep using the SystemIdleMode class. (Must be used alongside WAKE_LOCK.)
  • WRITE_EXTERNAL_STORAGE: Allows the application to write to external memory. This memory is normally stored as a device SD card.

Preventing the device screen from dimming

The Android operating system will dim, and eventually turn off the device screen after a certain amount of time has passed. It does this to preserve battery life, as the display is the primary power drain on a device. For most applications, if a user is interacting with the interface, that interaction will prevent the screen from dimming. However, if your application does not involve user interaction for lengthy periods of time, yet the user is looking at or reading something upon the display, it would make sense to prevent the screen from dimming.

How to do it...

There are two settings in the AIR descriptor file that can be changed to ensure the screen does not dim. We will also modify properties of our application to complete this recipe:

  1. Find the AIR descriptor file in your project. It is normally named something like {MyProject}-app.xml as it resides at the project root.
  2. Browse the file for a node named <android> within this node will be another called <manifestAdditions>, which holds a child node called <manifest>. This section of the document contains everything we need to set permissions for our Android application.
  3. All we need to do is make sure the following two nodes are present within this section of the descriptor file. Note that enabling both of these permissions is required to allow application control over the system through the SystemIdleMode class. Uncomment them if necessary.

    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.DISABLE_
    KEYGUARD" />

  4. Within our application, we will import the following classes:

    import flash.desktop.NativeApplication;
    import flash.desktop.SystemIdleMode;
    import flash.display.Sprite;
    import flash.display.StageAlign;
    import flash.display.StageScaleMode;
    import flash.text.TextField;
    import flash.text.TextFormat;

  5. Declare a TextField and TextFormat pair to trace out messages to the user:

    private var traceField:TextField;
    private var traceFormat:TextFormat;

  6. Now, we will set the system idle mode for our application by assigning the SystemIdleMode.KEEP_AWAKE constant to the NativeApplication.nativeApplication.systemIdleMode property:

    protected function setIdleMode():void {
    NativeApplication.nativeApplication.systemIdleMode =
    SystemIdleMode.KEEP_AWAKE;
    }

  7. We will, at this point, continue to set up our TextField, apply a TextFormat, and add it to the DisplayList. Here, we create a method to perform all of these actions for us:

    protected function setupTraceField():void {
    traceFormat = new TextFormat();
    traceFormat.bold = true;
    traceFormat.font = "_sans";
    traceFormat.size = 24;
    traceFormat.align = "left";
    traceFormat.color = 0xCCCCCC;
    traceField = new TextField();
    traceField.defaultTextFormat = traceFormat;
    traceField.selectable = false;
    traceField.multiline = true;
    traceField.wordWrap = true;
    traceField.mouseEnabled = false;
    traceField.x = 20;
    traceField.y = 20
    traceField.width = stage.stageWidth-40;
    traceField.height = stage.stageHeight - traceField.y;
    addChild(traceField);
    }

  8. Here, we simply output the currently assigned system idle mode String to our TextField, letting the user know that the device will not be going to sleep:

    protected function checkIdleMode():void {
    traceField.text = "System Idle Mode: " + NativeApplication.
    nativeApplication.systemIdleMode;
    }

  9. When the application is run on a device, the System Idle Mode will be set and the results traced out to our display. The user can leave the device unattended for as long as necessary and the screen will not dim or lock. In the following example, this application was allowed to run for five minutes without user intervention:

    Android Manifest Assurance for Flash Development

How it works...

There are two things that must be done in order to get this to work correctly and both are absolutely necessary. First, we have to be sure the application has correct permissions through the Android Manifest file. Allowing the application permissions for WAKE_LOCK and DISABLE_KEYGUARD within the AIR descriptor file will do this for us. The second part involves setting the NativeApplication.systemIdleMode property to keepAwake. This is best accomplished through use of the SystemIdleMode.KEEP_AWAKE constant. Ensuring that these conditions are met will enable the application to keep the device display lit and prevent Android from locking the device after it has been idle.

Flash Development for Android Cookbook Over 90 recipes to build exciting Android applications with Flash, Flex, and AIR
Published: June 2011
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on this subject, see here.)

Establishing Android custom URI schemes

Android exposes a number of useful URI protocols to AIR for standard operations such as mapping, sms, and telephone. Defining a custom URI for our application allows it to be invoked from anywhere on the system: through the web browser, email, or even a native application. Custom URIs provides an alternative method of invoking an AIR application.

How to do it...

We will create an application that can be opened from the device web browser using a custom URI. We define the URI intent settings through modification of the AIR descriptor file:

  1. Find the AIR descriptor file in your project. It is normally named something like {MyProject}-app.xml as it resides at the project root.
  2. Browse the file for a node named <android>; within this node will be another called <manifestAdditions>, which holds a child node called <manifest>. This section of the document contains everything we need to set permissions for our Android application.
  3. We will now add the highlighted <intent-filter> node to our descriptor file. The portion of the intent which defines our URI is <data android:scheme="fvm"/>. This will enable our application to use the fvm:// URI. Note that "fvm" is being used for this example; when authoring an application based on such an example, we are free to change this value to whatever is suited to a particular application:

    <application android:enabled="true">
    <activity android:excludeFromRecents="false">
    <intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
    <intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <data android:scheme="fvm"/>
    </intent-filter>
    </activity>
    </application>

  4. Within our application, we will import the following classes:

    import flash.desktop.NativeApplication;
    import flash.display.Sprite;
    import flash.display.StageAlign;
    import flash.display.StageScaleMode;
    import flash.events.InvokeEvent;
    import flash.text.TextField;
    import flash.text.TextFormat;

  5. Declare a TextField and TextFormat pair to trace out messages to the user:

    private var traceField:TextField;
    private var traceFormat:TextFormat;

  6. We will, at this point, continue to set up our TextField, apply a TextFormat, and add it to the DisplayList. Here, we create a method to perform all of these actions for us:

    protected function setupTraceField():void {
    traceFormat = new TextFormat();
    traceFormat.bold = true;
    traceFormat.font = "_sans";
    traceFormat.size = 24;
    traceFormat.align = "left";
    traceFormat.color = 0xCCCCCC;
    traceField = new TextField();
    traceField.defaultTextFormat = traceFormat;
    traceField.selectable = false;
    traceField.multiline = true;
    traceField.wordWrap = true;
    traceField.mouseEnabled = false;
    traceField.x = 20;
    traceField.y = 40;
    traceField.width = stage.stageWidth-40;
    traceField.height =stage.stageHeight - traceField.y;
    addChild(traceField);
    }

  7. Register an event listener of type InvokeEvent.INVOKE upon the NativeApplication. This will detect any application invocation events initiated by the user employing our defined URI:

    protected function registerListeners():void {
    NativeApplication.nativeApplication.
    addEventListener(InvokeEvent.INVOKE, onInvoke);
    }

  8. When the application is opened from our URI, the following method will be processed. We can gather a certain amount of information from our invoke event, such as the reason property. This property will have a value of either "login" or "standard". If the application is launched automatically at system login, the value will read "login". In the case of URI invocation, it will read "standard". We can also access the currentDirectory. The app may have been invoked from within the file system, or access any arguments passed through the URI. Note that in the case of a URI invocation from a web browser, as we have here, the arguments property will only contain the full URL from the selected link. This is a way in which we can pass in data to our application at launch.

    protected function onInvoke(e:InvokeEvent):void {
    traceField.text = "";
    traceField.text = "Invoke Reason: " + e.reason + "\n";
    traceField.appendText("Directory URL: " + e.currentDirectory.
    url + "\n\n");
    var args:Array = e.arguments;
    if (arguments.length > 0) {
    traceField.appendText("Message: " + args.toString() + "\n");
    }
    }

  9. For this example, let us set up a simple web page which includes a link with our defined fvm:// URI:<a href="fvm://arg1=Hello&arg2=AIRAndroid">O pen AIR Android App!</a>. If a user has the application already installed and clicks this link, the application should open as our URI intent is registered on the device:

    Android Manifest Assurance for Flash Development

  10. Once the user clicks upon the link which uses our defined URI, the AIR application will open and detect an InvokeEvent, which displays the following information upon the device display. We can see here that the directory URL is empty, as the application was not invoked from within the device file system:

    Android Manifest Assurance for Flash Development

How it works...

When we define the URI intent within our application descriptor file, this gets compiled into the Android manifest file along with our application. Installing this application on a device informs the operating system of the URI intent we have defined. This makes the OS aware of that specific URI and instructs it to open the application when that URI is encountered. We can place the URI in a number of different locations, including native Android applications upon the system. This allows native applications to open AIR for Android applications. In the earlier example, we embed the URI within HTML and use the Android web browser to open our application.

Anticipating Android Compatibility Filtering

Depending upon which APIs is used in a particular application, some Android devices may not be able to provide access to expected sensors or hardware hooks. If a user downloads an application which does not work as expected, that user will become frustrated and will most likely provide us with a poor rating and perhaps even a nasty comment. Luckily, there is a bit of filtering that the Android Market can perform, on our behalf, to ensure that only devices which support our application will be served the option to download and install it.

How to do it...

Modify the Android Manifest file to specify which particular features are required by our application:

  1. Find the AIR descriptor file in your project. It is normally named something like {MyProject}-app.xml as it resides at the project root.
  2. Browse the file for a node named <android>; within this node will be another called <manifestAdditions>, which holds a child node called <manifest>. This section of the document will contain everything we need to declare compatibility for our Android application.
  3. We will add certain tags based upon our needs. See the following information layout to determine what you should add within the manifest node for a particular feature dependency. Setting android:required="false" makes a feature optional.

When using features of the Android camera:

<uses-feature android:name="android.hardware.camera"
android:required="false"/>

<uses-feature android:name="android.hardware.camera.autofocus"
android:required="false"/>

<uses-feature android:name="android.hardware.camera.flash"
android:required="false"/>

When using features of the Android microphone:

<uses-feature android:name="android.hardware.microphone"
android:required="false"/>

When using the Geolocation Sensor:

<uses-feature android:name="android.hardware.location"
android:required="false"/>
<uses-feature android:name="android.hardware.location.network"
android:required="false"/>
<uses-feature android:name="android.hardware.location.gps"
android:required="false"/>

When using the Accelerometer Sensor:

<uses-feature android:name="android.hardware.accelerometer"
android:required="false"/>

How it works...

By specifying certain required or optional features of the camera and microphone, we can ensure that only users whose devices meet these specific requirements will be presented with the option to download and install our application. We make these specifications known through the modification of the Android manifest file through additions to our AIR description file as demonstrated in this recipe. Compiling our application with these modifications will ensure that these specifications are encoded along with our .APK and exposed through the Android Market once our application is published.

Flash Development for Android Cookbook Over 90 recipes to build exciting Android applications with Flash, Flex, and AIR
Published: June 2011
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on this subject, see here.)

Instructing an application to be installed to Device SDCard

By slightly modifying the Android manifest instructions within our AIR application descriptor file, we can inform the device operating system that our application should, if possible, be installed on the external SD card rather than internal storage. This will help reserve internal device storage for the operating system and associated files.

How to do it...

Modify the Android Manifest file to determine installation location options:

  1. Find the AIR Descriptor File in your project. It is normally named something like {MyProject}-app.xml and resides at the project root.
  2. Browse the file for a node named <android>; within this node will be another called <manifestAdditions>, which holds a child node called <manifest>.
  3. We will add the installLocation attribute to our <manifest> node. To set the application to install at the discretion of Android:

    <manifest android:installLocation="auto"/>

  4. To set the application to prefer the device SD card:

    <manifest android:installLocation="preferExternal"/>

There is no guarantee that setting installLocation="preferExternal will actually install the application to the device SD card.

The user can also move the application, if allowed, via the following steps:

  1. First, navigate to the application management screen on the device where our AIR application is installed. The location of this screen on most Android devices is Settings | Applications | Manage Applications. Now choose an AIR application you have created from this screen.
  2. To move the application to the device SD card, simply click the button labeled Move to SD card:

    Android Manifest Assurance for Flash Development

How it works...

It is a good idea to allow the user some degree of choice as to where they can install their application. On Android, there are only two options: the device storage area or external SD card. Taking into consideration that most devices have a lot more storage on the SD card than internal; it is probably best to prefer the SD card by setting android:installLocation="preferExternal" on our manifest node within the AIR descriptor file. While there is no guarantee that Android will use the external SD card when installing our application, this will at least let the system know that location is preferred. Whether or not Android is able to install applications to external storage has mostly to do with the operating system version. Generally, if the device can install and run the AIR for Android runtime, it should have the capability to do this.

As we've seen earlier, the user can always move the application from internal storage to external storage and back again if they wish. Also of note: the application storage directory, local shared objects, and any temporary files are still written to internal storage even when the application is installed on the device SD card. If we intend to save lots of data with our application, then we will use File.documents directory or File.user directory to store this data onto the external SD card.

Encrypting a local SQLite database

Normally, a local SQLite database does not require any security or encryption. However, if our application contains sensitive data stored within the local application database files, we would want to ensure that an intruder or thief cannot access this information. Thankfully, we can encrypt the databases available to us on AIR for Android to ensure that even if a user's device is lost or stolen, their private information remains secure.

Getting ready...

In order to properly encrypt a database file, we will need to use an encryption library. In this example, we will use the as3crypto package available at http://code.google.com/p/as3crypto/. Download the .SWC to follow along with this example.

We need to make the .SWC available within our project. Depending upon the tool being used, the procedure to do this does vary.

Instructions to include a .SWC package into a Flash Builder project

  1. Within your project, select the File menu and choose Properties.
  2. In the left column, click ActionScript Build Path and choose the Library path tab. Locate the button labeled Add SWC... within this screen and click it.
  3. A dialog window will appear. Choose the Browse to SWC option, locate the .SWC containing our encryption library, and hit OK.
  4. The encryption library will now appear within the Build path libraries section of this screen. Verify that this is correct and exit out of the Properties window. The encryption library is now ready to be used within our mobile Android project.

Android Manifest Assurance for Flash Development

Instructions to include a .SWC package into a Flash Professional project

  1. Within your Flash project, navigate to the Properties panel and click the little wrench icon next to the Script selection box:

    Android Manifest Assurance for Flash Development

  2. This will open the Advanced ActionScript 3.0 Settings dialog window. Choose the Library path tab. Locate the Browse to SWC file icon within this screen and click it. It appears as a white and red box and is the only icon which is not grayscale upon this screen:

    Android Manifest Assurance for Flash Development

  3. A file browse dialog window will appear. Locate the .SWC containing our encryption library, and hit OK.
  4. The encryption library will now appear within the Library path section of this screen. Verify that this is correct and exit out of the Advanced ActionScript 3.0 Settings window. The encryption library is now ready to be used within our mobile Android project:

    Android Manifest Assurance for Flash Development

How to do it...

In order to encrypt an application database, we will declare a password and encrypt it using an external encryption library. This will be used when creating and opening our database connection:

  1. Within our application, we will import the following classes. Be sure to import the MD5 class or an equivalent for proper key encryption:

    import com.hurlant.crypto.hash.MD5;
    import flash.data.SQLConnection;
    import flash.data.SQLMode;
    import flash.data.SQLStatement;
    import flash.display.Sprite;
    import flash.display.StageAlign;
    import flash.display.StageScaleMode;
    import flash.events.SQLEvent;
    import flash.filesystem.File;
    import flash.text.TextField;
    import flash.text.TextFormat;
    import flash.utils.ByteArray;

  2. We must now declare a number of objects for use within this application. A String constant will hold our plain text password for later encryption. Normally, this would be supplied by the user and is hard-coded here for simplicity. We will need a SQLConnection to create or open our database file along with a set of ByteArray objects and a MD5 object to perform the actual encryption. Finally, we declare a TextField and TextFormat pair to trace out messages to the user:

    private const pass:String = "AIR@ndr0idIsKo0l";
    private var sqlConnection:SQLConnection;
    private var encryptionPass:ByteArray;
    private var encryptionKey:ByteArray;
    private var md5:MD5;
    private var traceField:TextField;
    private var traceFormat:TextFormat;

  3. We will, at this point, continue to set up our TextField, apply a TextFormat, and add it to the DisplayList for textual output. Here, we create a method to perform all of these actions for us:

    protected function setupTraceField():void {
    traceFormat = new TextFormat();
    traceFormat.bold = true;
    traceFormat.font = "_sans";
    traceFormat.size = 24;
    traceFormat.align = "left";
    traceFormat.color = 0xCCCCCC;
    traceField = new TextField();
    traceField.defaultTextFormat = traceFormat;
    traceField.selectable = false;
    traceField.multiline = true;
    traceField.wordWrap = true;
    traceField.mouseEnabled = false;
    traceField.x = 20;
    traceField.y = 40;
    traceField.width = stage.stageWidth-40;
    traceField.height =stage.stageHeight - traceField.y;
    addChild(traceField);
    }

  4. To perform the encryption of our database, we will first instantiate a ByteArray and invoke the writeUTFBytes() method, passing in our predefined password constant. This will write our String to the byte stream.
  5. Now, instantiate a new MD5 object along with another ByteArray, assigning the ByteArray to the result of the MD5.hash() method, passing in the previous ByteArray holding the password bytes.
  6. Instantiate an SQLConnection and register an event listener of type SQLEvent.OPEN. This will fire an event once the database is either created or opened successfully.
  7. Finally, invoke the SQLConnection.open() method, passing in the path to the database as a File object, the open mode constant of SQLMode.CREATE, an auto-compact Boolean, default page size of 1024, and most importantly for this example, our MD5-encrypted ByteArray:

    protected function encryptDB():void {
    encryptionPass = new ByteArray();
    encryptionPass.writeUTFBytes(pass);

    md5 = new MD5();
    encryptionKey = new ByteArray();
    encryptionKey = md5.hash(encryptionPass);

    sqlConnection = new SQLConnection();
    sqlConnection.addEventListener(SQLEvent.OPEN, dbOpened);
    sqlConnection.open(File.applicationStorageDirectory.
    resolvePath("encrypted.db"), SQLMode.CREATE, false, 1024,
    encryptionKey);
    }

  8. So long as the database is created (or opened) successfully along with valid encryption, the following method will fire, outputting information about the encrypted database to our display:

    protected function dbOpened(e:SQLEvent):void {
    traceField.appendText("Encrypted DB Created!\n\n");
    traceField.appendText("Pass: " + pass + "\n\n");
    traceField.appendText("Key: " + encryptionKey.toString());
    }

  9. When the application is run on our Android device, it will appear as follows. As the key is a truly MD5-encrypted ByteArray, it appears as garbled characters in the TextField, for it is no longer a plain text String:

    Android Manifest Assurance for Flash Development

How it works...

If an application requires encryption on a database, the encryption key must be applied when our database is created. Implementing the SQLConnection.open() or SQLConnection.openAsync() methods require us to pass in an encrypted ByteArray key created using as3Crypto or a similar encryption library. If we ever need to modify the encryption key, we can use the SQLConnection.reencrypt() to do so, generating the key in the same manner as demonstrated in this recipe. Note that a valid encryption key must be 16 bytes in length.

Summary

This article demonstrated the various Android Manifest permissions and provided examples of Market filtering, encrypted database support, and other security-minded techniques.


Further resources on this subject:


About the Author :


Joseph Labrecque

Joseph Labrecque is primarily employed by the University of Denver as Senior Interactive Software Engineer specializing in the Adobe Flash Platform, where he produces innovative academic toolsets for both traditional desktop environments and emerging mobile spaces. Alongside this principal role, he often serves as adjunct faculty communicating upon a variety of Flash Platform solutions and general web design and development subjects.

In addition to his accomplishments in higher education, Joseph is the Proprietor of Fractured Vision Media, LLC, a digital media production company, technical consultancy, and distribution vehicle for his creative works. He is founder and sole abiding member of the dark ambient recording project An Early Morning Letter, Displaced, whose releases have received international award nominations and underground acclaim.

Joseph has contributed to a number of respected community publications as an article writer and video tutorialist. He is also the author of Flash Development for Android Cookbook, Packt Publishing (2011), What's New in Adobe AIR 3, O'Reilly Media (2011), What's New in Flash Player 11, O'Reilly Media (2011), Adobe Edge Quickstart Guide, Packt Publishing (2012) and co-author of Mobile Development with Flash Professional CS5.5 and Flash Builder 4.5: Learn by Video, Adobe Press (2011). He also serves as author on a number of video training publications through video2brain, Adobe Press, and Peachpit Press.

He regularly speaks at user group meetings and industry conferences such as Adobe MAX, FITC, D2W, 360|Flex, and a variety of other educational and technical conferences. In 2010, he received an Adobe Impact Award in recognition of his outstanding contribution to the education community. He has served as an Adobe Education Leader since 2008 and is also an Adobe Community Professional.

Visit him on the Web at http://josephlabrecque.com/.

Books From Packt


Android 3.0 Application Development Cookbook
Android 3.0 Application Development Cookbook

Android Application Testing Guide
Android Application Testing Guide

Android User Interface Development: Beginner's Guide
Android User Interface Development: Beginner's Guide

Sencha Touch 1.0 Mobile JavaScript Framework
Sencha Touch 1.0 Mobile JavaScript Framework

Facebook Graph API Development with Flash
Facebook Graph API Development with Flash

Flash Facebook Cookbook
Flash Facebook Cookbook

Mobile Web Development
Mobile Web Development

PhoneGap Beginner's Guide: RAW
PhoneGap Beginner's Guide: RAW


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Y
m
Y
C
c
6
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software