"Exercising Our Remote Application Removal Feature"

A friend of mine shared an interesting blog entry from the Android Developer Blog on Buzz. Here some excerpts:

Exercising Our Remote Application Removal Feature

Every now and then, we remove applications from Android Market due to violations of our Android Market Developer Distribution Agreement or Content Policy. In cases where users may have installed a malicious application that poses a threat, we’ve also developed technologies and processes to remotely remove an installed application from devices. If an application is removed in this way, users will receive a notification on their phone. [...]

The remote application removal feature is one of many security controls Android possesses to help protect users from malicious applications. In case of an emergency, a dangerous application could be removed from active circulation in a rapid and scalable manner to prevent further exposure to users. While we hope to not have to use it, we know that we have the capability to take swift action on behalf of users’ safety when needed.

This remote removal functionality — along with Android’s unique Application Sandbox and Permissions model, Over-The-Air update system, centralized Market, developer registrations, user-submitted ratings, and application flagging — provides a powerful security advantage to help protect Android users in our open environment.

Source: Android Developer Blog

(The highlighting in the quote is mine.) From a pure technological, tech-Android-programmer point of view I'd say "yah, damn cool". I mean, this is no doubt a very powerful feature. Suppose some malware will be distributed and Google knows about it. Without you even to take note about the potential danger they'll remove it from all of their devices and keep their platform safe and clean. Nice, isn't it? On the other side it leaves some strange feeling which most of us will have when knowing that others can remotely control your device. Naturally questions arise whether this is the only thing they can do remotely...

However, given the open-minded strategy which is driving the evolution of the Android platform, this is probably the only way to be able to keep it under control, to - from time to time when it becomes necessary - do some corrective countermeasures.

Instead, Apple's strategy on the App Store is a completely opposed one. It is a closed world where applications have to pass a long-lasting approval process governed by Apple itself. This has often been criticized but they seem to do a good job so far in keeping their platform clean and secure.

What do you think? Which is the better/more suitable approach and why??

Let tests guide you through development

I'm currently working on my MSc thesis work which is divided into a project that has to be developed (in my case an Android application) and then the according paper that has to be written. Now since I'm also working part-time as a software developer, a usual day in front of the computer, solving computing tasks often becomes quite long and intense. There are a couple of issues related to this...

1. As all of us know, the longer you sit in front of the computer, the more tired you get and consequently the more errors you commit to the code base.
   
2. Moreover there is the well known context-switch problem. I develop .Net in the morning, Java in the afternoon. I mean you get accustomed to it, but you have to carefully keep track what has to be done in each of the projects, at work in the morning and for the thesis project in the afternoon. This needs a lot of organization. How to do that? Task lists??

How to approach those problems? My answer: use TDD style and automated tests. How that works? Well,

Read more »

Presentation: Testing on Android

A very interesting presentation by Diego Torres Milano that gives a good overview and examples about testing on the Android platform. Definitely worth to take a look at.

Testing on Android

View more presentations from dtmilano.

Android Instrumentation test - AndroidTestCase: java.lang.IllegalAccessError

Today I started writing the instrumentation tests for the Android platform side of the project. For your understanding, here's the structure of my situation:

• Library Project
  This part of the project encapsulates general functionality and functions as platform independent class library allowing to plug-in the platform dependent components. Testing is straightforward and can be done with plain-old jUnit tests.
  
  
• Android Project
  This is the part of the project which is being deployed on the Android OS platform. It uses the previously mentioned "Library Project" which is directly referenced in the Eclipse workspace.
  
  
• Android Test Project
  This project contains all of the Android platform specific instrumentation tests.

So far everything's good. In the Android Test Project I'm writing my test cases extending from the AndroidTestCase class which gives me basic Android-platform specific objects like the Context object. The Android Test Project references the Android Project for testing it, obviously :) . Moreover since in the test cases I'm using objects from the Library Project I've referenced also this one.

For the purpose of comfortableness you create a generic suite like the following

public class AllInstrumentationTests extends TestSuite {

 public static Test suite(){
  return new TestSuiteBuilder(AllInstrumentationTests.class)
   .includeAllPackagesUnderHere()
   .build();
 }
}

Then running this test using the correct menu entry "Android JUnit Test"...

...gave the error

[2010-06-03 21:45:04 - DroidSenseInstrumentationTests] Launching instrumentation android.test.InstrumentationTestRunner on device emulator-5554
[2010-06-03 21:45:10 - DroidSenseInstrumentationTests] Test run failed: java.lang.IllegalAccessError
[2010-06-03 21:45:10 - DroidSenseInstrumentationTests] Test run complete

...with the more "concrete" message

java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation

Beside the Eclipse jUnit runner which seems to have problem with the instrumentation tests, forcing me to often start them multiple times in order to get a result (hate that!!), it drove me crazy in trying to find the problem for it. I soon discovered it must depend on the included Library Project. This blog post then pointed me to the right direction and finally I solved the problem.

The Library Project shouldn't be included on the Android Test Project's build path, but instead you need to export (check it in the "Order and Export" tab) it from the Android Project. Otherwise your Android Test Project won't compile:

The same holds for externally included libraries.

• Reference the library in the build path of your main project as usual, but also check it to be exported
• In the test project just reference your main project which is subject to the tests. You will not need to also include the externally used library

Now everything should run "smoothly" (under quotation marks 'cause the Android jUnit integration in Eclipse is everything else than "smooth" right now).

Btw, running the tests from the shell rather than from within Eclipse runs them faster, however, remember to deploy your app on your emulator first. The command:

adb shell am instrument -w com.yourcompany.youapp.test/android.test.InstrumentationTestRunner

HowTo: Get an Android app's database from the emulator

Most apps need a database for storing their data onto the device in a structured form. Android's natively supported DB is SQLite. Now of course if you develop an app you'll probably have the need for inspecting the stored data during development. Since the DB sits on the emulator/real device you have to first pull it to your workstation, however.

There are two possibilities for doing so:

• Use the adb command from your shell:
  For instance
  
  

  adb pull /data/data/com.yourcompany.yourpackage/databases/yourdbname.db /Users/Juri/Desktop/
  

  This will store it on your desktop.
  
  
• Alternatively you can use Eclipse like: