What is code obfuscation?

If you are ready to submit your app to the Amazon Appstore for Android, you might consider obfuscating your code. Obfuscating your code modifies your source and machine code to be difficult for a human to understand if your app gets decompiled. If you are concerned about your app being reverse engineered, using a tool to obfuscate your code can help a great deal.

Caveat

Not all of your source can be obfuscated, however. If you are implementing In-App Purchasing for your app, the Amazon Appstore relies on certain methods being available to call and provide you with information about a purchase request. If these methods get obfuscated and renamed, the Appstore will not be able to send information to your app. This post is a brief walkthrough on adding code obfuscation to your project.

Proguard

For android apps, Proguard is a code obfuscation tool that is provided to you once you download the Android SDK. The program shrinks and obfuscates your source code.

Setting Up Code Obfuscation for your Project

Prerequisites

This walkthrough assumes you have the Android SDK and Amazon In-App Purchasing API installed and your project already completed.

For help on installing the Android SDK, please refer to their website at http://www.developer.android.com/sdk/installing.html. Download the Amazon In-App Purchasing API by going to http://developer.amazon.com/

Enabling Proguard for your App

To enable Proguard for your Android app, refer to the following documentation from the Android SDK: http://developer.android.com/guide/developing/tools/proguard.html

Edit the build.properties file inside of your project, and add the following line (if you don’t have this file in your project directory, make one):

 ‘Keeping’ the In-App Framework Intact

When incorporating the in-app framework into your library, you will need to specify classes to ‘keep’ and not obfuscate. Add the following lines anywhere in your proguard.cfg file.

Finalizing and Releasing Your App

Now that you’ve fully set up your proguard.cfg and build.properties file, you can run Proguard through the ant  build script for your project.

Obfuscation with another Program

If you are using another program for code obfuscation, to ensure that in-app functionality is preserved, make sure your program does not obfuscate any class under the com.amazon.* namespace, including method names and identifiers. Your obfuscation program must also preserve annotations.

Conclusion and Additional Resources

The code in this article serves as a walkthrough for enabling and using Proguard for release candidates of your app. Sample apps that include the code from this article are provided in the In-App Purchasing API. Again, you can download the SDK by logging into http://developer.amazon.com/

This post discusses how Android apps can use Amazon Web Services (AWS) to send e-mail without additional infrastructure. The sample code presented here uses Amazon Simple Email Service to record feedback from users but this same method could be used in the following scenarios:

• automated alerts/bug reports
• feature requests
• blog by e-mail

Amazon Simple Email Service (Amazon SES) is a highly scalable and cost-effective bulk and transactional email-sending service for businesses and developers. Amazon SES eliminates the complexity and expense of building an in-house e-mail solution or licensing, installing, and operating a third-party e-mail service.

This post shows a sample for the Android platform. The complete sample code and project files are included in the AWS SDK for Android. A link to the SDK is available at the end of this post.

To use the AWS SDK for Android, you will need AWS credentials, that is, an Access Key ID and Secret Access Key. If you haven't already signed up for Amazon Web Services, you will need to do that first to get your credentials. You can sign up for AWS here. After you sign up, you can retrieve your credentials at this page.

The sample application described here demonstrates how Android apps can record feedback from their users through Amazon SES. It requires that you already have a verified e-mail address; this address will be used as both the sender and recipient of the message, so it is not necessary to get production access to Amazon SES before using this sample application. You can verify an e-mail address on the AWS console and read more about verification and production access in the Amazon SES Getting Started Guide. Amazon SES can also be used to create other types of e-mails not shown here.

Creating an Amazon SES Client

Making requests to Amazon SES requires creating a client for the service. The code below shows how to create a client on both the iOS and Android platforms.

AWSCredentials credentials = new BasicAWSCredentials(                                           PropertyLoader.getInstance().getAccessKey(),                                           PropertyLoader.getInstance().getSecretKey() );AmazonSimpleEmailServiceClient sesClient =                              new AmazonSimpleEmailServiceClient( credentials );

Creating E-mail

SES will accept both regular and raw e-mails. Our application makes use of the regular method, meaning we do not have to construct our own headers. Regular e-mails require a source, destination (list of to, cc, and bcc addresses) and a message, which itself comprises a body and subject. The code below shows how to create the various parts of the email on both the iOS and Android platforms.

String subjectText = "Feedback from " + nameField.getText();Content subjectContent = new Content(subjectText);    	String bodyText = "Rating: " + ratingBar.getRating() + "\nComments\n" + commentsField.getText();Body messageBody = new Body(new Content(bodyText));	    	Message feedbackMessage = new Message(subjectContent,messageBody);    	String email = PropertyLoader.getInstance().getVerifiedEmail();Destination destination = new Destination().withToAddresses(email);

Sending E-mail

Once we've constructed our e-mail components, it simply becomes a matter of creating a SendEmailRequest and passing this to the SES client we created earlier. The code below shows how to create a SendEmailRequest and send it with Amazon SES on both the iOS and Android platforms.

SendEmailRequest request = new SendEmailRequest(email,destination,feedbackMessage);SendEmailResult result = clientManager.ses().sendEmail(request);

References

A sample application that includes this code is provided in the AWS SDK for Android. The download link can be found on the following pages:

• AWS SDK for Android

For more information about using AWS credentials with mobile applications see the following article:

• Authenticating Users of AWS Mobile Applications with a Token Vending Machine

Questions?

Please feel free to ask questions or provide comments in the Mobile Development Forum.

At last week’s CES, it was hard to ignore the fact that many technology pundits are considering 2011 as the year of the tablet.  And although Apple should be thanked for resurrecting interest in tablets in 2010, 2011 will see a record breaking surge in the number of vendors bringing new tablets to market.  Sean Dubravac, Chief Economist and Director of Research, Consumer Electronics Association,  predicted, “While many firms are touting product launches within the tablet sphere for the fourth quarter of 2010, the real action will occur a few weeks after the end of the quarter at CES.”  The next few weeks will be telling for the future of the tablet and so far it’s looking quite bright. 

The good news for you, the Android developer, is that many of these tablets will be sporting Android OS and, with the recent announcement of the Amazon Appstore Developer Portal, you have a convenient way of offering your apps to both tablet and smartphone users.  We’re not mandating that you optimize your apps for tablets as well as smartphones, but it’s definitely something you should consider. 

The expected surge in the number of tablets on the market and the number of Android devices a single user will own brings forth new opportunities and challenges.  The opportunities are clear—more devices mean more users, more hardware features and more APIs to take advantage of.   These new tablets will continue to feature larger screens and supported resolution levels, ample amounts of disk space and extremely fast processer speeds that are not far behind that of a typical laptop. An important thing to remember as a developer is that customers may be using your app across tablets and smartphones – no longer just one or the other. 

 A quick comparison of the best selling smartphones and tablets on Amazon.com shows that tablets boast 50-100% more screen real-estate and 50% more disk space.  Furthermore, many of the tablets demonstrated at CES also feature dual-core CPUs.  These differences make it more important than ever for developers to be aware of the device capabilities and limitations.  With Amazon.com’s convenient 1-Click purchase and digital locker features, customers will be able to buy your apps and run it on any of their Android devices.  Unfortunately, the growth in devices will present one of the biggest challenges for you—you want to continue to build and extend your killer apps and offer it to the tens of millions of Amazon.com customers, but you also want to keep your customers happy by setting expectations on how and where the apps can be run.   

The Android SDK requires that each application contain a file called AndroidManifest.xml within the apk.  This is where you can let the system know what your app needs at a minimum to run and what resources and services it will use.  For instance, if you are building a word processor app that is designed to only run on a tablet, you will want to set the android:largeScreens attribute to “true” on the <supports-screens> property, while explicitly setting the small and normal screen flags to false.  If you don’t declare this requirement for your app, then the Android system will assume it works on all screen sizes.   

On the other hand, if you are building a game that looks great on any phone or tablet, then you can declare this in the xml file by including the following settings:

<supports-screens
        android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true" />

One thing to be aware of, however, is that once you declare support for all screen sizes, you will want to check the DisplayMetrics settings at runtime to make important display decisions in your code.  This information can be used to make performance optimizations, such as displaying low to medium resolution images on small devices and high resolution images on large screens—a great way to avoid creating multiple versions of your app.

Apps that depend on hardware resources, such as GPS, Wi-Fi or Bluetooth capabilities, can define these requirements by appropriately setting the <uses-features> option. 

Furthermore, with last month’s announcement of the Gingerbread release, there are now 6 flavors of Android OS in use.  If the trend over the past two years continues, you can expect one more major release (3.0, Honeycomb) and another minor release to be announced before 2012. With major features being added in every new platform version, such as improved copy-and-paste and faster text input processing in Gingerbread, you will want to take advantage of these capabilities and also ensure your apps only run under their supported environment.  The manifest provides a way to enforce dependencies on specific SDK features by using the <uses-sdk> flag.

Customer satisfaction is a key driver behind Amazon.com’s success.  As you develop and offer your application to Amazon.com’s customers, following these Android development best practices guidelines is a great start towards achieving similar success.