Friday, December 20, 2013

ART or Dalvik? Which one is better?

ART (Android RunTime) is the next version of Dalvik. Dalvik is the runtime, bytecode, and VM used by the Android system for running Android applications.

ART has two main features compared to Dalvik:
  1. Ahead-of-Time (AOT) compilation, which improves speed (particularly start-up time) and reduces memory footprint (no JIT).
  2. Improved Garbage Collection (GC).
An ahead-of-time (AOT) compiler is a compiler that implements ahead-of-time compilation. This refers to the act of compiling an intermediate language, such as Java bytecode, into a system-dependent binary. Hence your apps are compiled to native code once, and stored on your device to run effectively as native. This differs from the traditional VM model, which interprets bytecode. Interpreters are slow, so VM developers added a technology called Just-in-Time (JIT) compilation, which compiles (and hopefully optimizes) your code to native code on-the-fly. Dalvik is a JIT'ing VM. The downside to JIT is that the JIT compiler runs while you are using your app, adding latency and memory pressure. The upside is that the JIT compiler can perform some optimizations possible, like runtime profile-guided optimizations, pseudo-constant propagation or indirect/virtual function inlining.

AOT is like JIT, but it runs once—say, at app installation time. AOT in most cases produces machine optimized code, just like a 'standard' native compiler. Beside it lacks the ability to perform profile-directed optimizations, AOT transforms the bytecode of an existing virtual machine into machine code. AOT compilers can perform complex and advanced code optimizations which in most cases of JITing will be considered much too costly.  In most situations with fully AOT compiled programs and libraries it is possible to drop considerable fraction of runtime environment, thus saving disk space, memory and starting time. Because of this it can be useful in embedded or mobile devices. I think AOT is the right step for Android and ART looks quite impressive.

ART was first included in Android KitKat, but isn't yet enabled by default. You can enable it via Settings > Developer options > Select runtime > Use ART.

Note: There is a possibility that some of the Android applications may not work with ART, because it is an entirely new VM. It may has bugs or might be some areas of the core APIs are not compatible. This is why it is not yet the default VM in Android.

Thursday, October 17, 2013

How to check support for Call & SMS on Android device?

Sometime we have requirements to implement call & sms support with in our android app. Now how to check whether device has support for call & sms feature. To verify, we can check the device phone type, which indicates the type of radio used to transmit voice calls. In addtion to this we can also check that the device has a telephony radio with data communication support or not. The method is as follows:-

public static boolean supportCallAndSMS(Context context) {
boolean isSupported = false;
TelephonyManager telephonyManager = (TelephonyManager) context
.getSystemService(Context.TELEPHONY_SERVICE);
boolean isPhone = !(telephonyManager.getPhoneType() == TelephonyManager.PHONE_TYPE_NONE);
boolean featureTelephony = context.getPackageManager().hasSystemFeature(
PackageManager.FEATURE_TELEPHONY);
if(isPhone && featureTelephony) {
isSupported = true;
}
return isSupported;
}

Sunday, September 1, 2013

Detect fake/mock GPS apps on Android device

While we are working with location APIs in any Android App, we have to make sure that user is not using any fake/mock GPS apps. We can detect fake/mock GPS apps using two ways:
  1. Detect mock location is enabled in developer settings.
  2. Detect apps installed on device who are using mock location permissions.
To detect the mock location settings:-
public static boolean isMockLocationSettingsON(Context context) {
        // returns true if mock location enabled, false if not enabled.
if (Settings.Secure.getString(context.getContentResolver(),
        Settings.Secure.ALLOW_MOCK_LOCATION).equals("0")) {
       return false;
} else {
return true;
}
}

To detect the mock location permissions:-
public static ArrayList getListOfMockPermissionApps(Context context) {
ArrayList mockPermissionApps = new ArrayList();
PackageManager pm = context.getPackageManager();
List packages = pm
.getInstalledApplications(PackageManager.GET_META_DATA);

for (ApplicationInfo applicationInfo : packages) {
try {
PackageInfo packageInfo = pm.getPackageInfo(
applicationInfo.packageName,
PackageManager.GET_PERMISSIONS);

// Get Permissions
String[] requestedPermissions = packageInfo.requestedPermissions;

if (requestedPermissions != null) {
for (int i = 0; i < requestedPermissions.length; i++) {
if (requestedPermissions[i]
.equals("android.permission.ACCESS_MOCK_LOCATION")
&& !applicationInfo.packageName.equals(context
.getPackageName())) {
mockPermissionApps.add(applicationInfo.packageName);
}
}
}
} catch (NameNotFoundException e) {
}
}
return mockPermissionApps;
}

Monday, June 10, 2013

Getting java.lang.NoClassDefFoundError after upgrade to ADT 22

After updating your Android SDK & ADT plugin, some fellow developers may be facing java.lang.NoClassDefFoundError at runtime even dependency libraries already added to the project.  To fix this issue, I found the solution at Google adt-dev group. The solution is as follows:-

It was indeed an issue with 'Order and Export' of the Java Build Path.

When upgrading, the 'Order and Export' of the new 'Android Private Libraries' is not always checked. And the android-support-v4.jar is now in this 'Android Private Libraries' section. 

To fix this, go to 'Order and Export' and check 'Android Private Libraries'. Then refresh/clean/rebuild.

After you done this 'fix' for a library project, you may need to just close and re-open any depending project, because they may not see this 'fix' immediately. 

Friday, April 19, 2013

Difference between rooting & unlocking bootloader

Lots of Android users are still don't know the difference between rooting & unlocking bootloader and they will get confused between these terminology. There is a major difference between these two & also they are related to each other. The difference & relation is as follows:-

Rooting - Rooting a device is a method to gain full access to the device operating system (Android). However, rooting only affects your operating system. With root you are able to perform all the administrative stuff, such as access to write files to the system partition or delete all the files or uninstall system apps. Root enhances your privileges and you are able to change almost anything inside of your ROM.

Unlocking Bootloader - Bootloader is the instance that calls the operating system (Android) and manages direct access to the device's partitions. Having an unlocked bootloader enables you to flash custom roms, custom kernels, recoveries and so on.

Relation between Rooting & Unlock Bootloader - A locked bootloader also locks write access to several partitions like the system partition. This is the reason why rooting is not able without unlocked bootloader. Rooting needs write access to the system partition (for storing the superuser binary and the superuser app) Without unlocked bootloader, only a temporary half-root can be achieved.

Thursday, March 21, 2013

JavascriptInterface not working with Android 4.2

As we all know android system allow you to call an android function directly from your web page by using the addJavascriptInterface(). Few fellow developers are facing issues for JavascriptInterface not working with Android 4.2. The obvious reason for this is because Google want to enhance security for Android platform.

The change will be very important for apps whose android:targetSdkVersion is set to 17 or higher, running on Android 4.2+ devices. Methods without the @JavascriptInterface annotation will not be accessible from JavaScript. Previously, any public method would be reachable via JavaScript. As Java classes usually have many inherited methods, public methods, including ones like getClass(). JavaScript could then use reflection to access other stuff, beyond what you had in mind. By limiting access to @JavascriptInterface methods, only those you specifically opt into being accessible will be usable from the JavaScript environment.

So from your JavascriptAdapterInterface class method call should be like this:-

/**
 * Call method from webview to display toast.
 */
@JavascriptInterface //required for sdk version 17 or higher
public void showToast(String message) {
     Toast.makeText(mContext, message, Toast.LENGTH_SHORT).show();
}