Android: Catching NDK crashes

On Android catching Java exceptions is easy via UncaughtExceptionHandler. Catching NDK crashes is a bit more convoluted. Since the native stack is probably corrupted, you want the crash handler to run on a separate process. Also, since the system might be in an unstable shape, don’t send the crash report to your web server or do anything fancy. Just write the crash report to a file, and on the next restart of the app, send to your web server and delete it from the disk. I ended up using jndcrash package for this.

Read More

Dealing with phone numbers in contact book

If you are building an app that uses the user’s contact book then their certain gotchas to avoid.

Telephone country codes are prefix-free

If a country has a country code “+91”, then no other country will get a country code like “+912” or “+913”. This scheme ensures that numbers are inherently unambiguous.

Telephone numbers can have multiple representations

Since most people don’t dial internationally, telecom systems implicitly assume a domestic call. So, someone dialing 612-555-1234 in the US is dialing “+1-612-555-1234”, while the same person in India is dialing “+91-612-555-1234”. Since international dialing would be more infrequent, telecoms require unique prefix numbers like “00” to distinguish whether someone is 612-555-1234 in their country or 0061-255-51234 in Austria. In some states, even the domestic area code is not explicitly required. So, a user might have stored “555-1234” as the phone number to which telecoms will implicitly prefix the user’s area code. And if the user wants to dial beyond their area, the telecom operator would require an additional “0” prefix to mark that it is an STD call. This localization has a massive implication regarding processing cleaning and normalizing phone numbers retrieved from the user’s contact book. Both country code and area code don’t contain “0”, and usually, that’s superfluous. So, while telecoms might be OK with calling or sending SMS to “0-612-555-1234”, they will treat a number like “91-0-612-555-1234” as incorrect.

Multiple countries can share telephone codes

USA, Canada, and many countries in the Caribbean share the “+1” telephony code. The carriers would treat calls or SMS as international, though. Italy and Vatican city share “+39”.

Continuous area codes or country codes are not always adjacent

As the population grows in certain areas more than others, the codes reserved for other regions can get allotted to them. An example of that is the San Francisco Bay area, where the first 408 and then 669 was allocated on top of the existing 650 area codes to deal with the growing population.

Confirming phone number ownership

You can never trust an incoming call or incoming SMS’s phone number. Therefore, the only way to verify that the user owns a phone number is by sending them a text message or making them a phone call.

Troublshooting Android Emulator: “Emulator: Process finished with exit code 1”

Emulator: Process finished with exit code 1

You opened AVD Manager in Android Studio and tried to start an AVD, you got
“Emulator: Process finished with exit code 1”. Following are the steps to debug
this

  1. Find out the name of the emulator.
    Click the down arrow ūüĒĹ which is to the right of play arrow ‚Ė∂ÔłŹ, to find out the name of the AVD. Let’s say the name is “Nexus_5X_API_28_x86”.
  2. Try starting the AVD directly from command-line
    It fails with another cryptic error, but that’s at least¬†more actionable

    $(dirname $(which android))/emulator -avd Nexus_5X_API_28_x86
    ...
    PANIC: Broken AVD system path. Check your ANDROID_SDK_ROOT value [/opt/android_sdk]!

    Let’s retry in the verbose mode to see a detailed error

    $(dirname $(which android))/emulator -avd Nexus_5X_API_28_x86 -verbose
    ...
    Not a directory: /opt/android_sdk/system-images/android-28/google_apis/x86/
    

    So, the system image is missing.

  3. Install system image
    # List all possible system images.
    $(dirname $(which android))/bin/sdkmanager --list
    # List the images we are interested in.
    $(dirname $(which android))/bin/sdkmanager --list | ack google_apis | ack android-28 | ack x86
    # Install the right one using
    $(dirname $(which android))/bin/sdkmanager --install 'system-images;android-28;google_apis;x86'
    
  4. Now try starting the AVD again.
    $(dirname $(which android))/emulator -avd Nexus_5X_API_28_x86 -verbose
    ...
    emulator:Probing program: /opt/android_sdk/tools/emulator64-x86
    emulator:Probing program: /opt/android_sdk/tools/emulator-x86
    PANIC: Missing emulator engine program for 'x86' CPU.
    

    Turns out there is another version of emulator installed in $(dirname $(dirname $(which android)))/emulator/emulator. And the emulator I was using is a stray one.

    # This works
    $(dirname $(dirname $(which android)))/emulator/emulator -avd Nexus_5X_API_28_x86 -verbose
    

Android: Using “Die with me” app without killing the phone’s battery

Die with me¬†is a chat app which can be used only when the phone’s battery is below 5%.

Here is a fun way to use the app without draining your phone’s battery. Connect the phone via ADB or start Android emulator and fake the battery level to 4%.

sudo pip3 install adb-enhanced
adbe battery level 4 # Set battery level to 4%

And now, you can use the app. After playing with the app, reset the battery level with,

adbe battery reset

 

Circle CI vs Travis CI

I maintain a somewhat popular Android developer tool (adb-enhanced). The tool is written in Python, supporting both Python 2 and 3. Testing the tool requires both Python runtime as well a running Android emulator. I, initially, used Travis CI for setting up continuous testing of this tool. Later, I felt that Travis CI was too slow and when I came across Circle CI, I decided to give it a try. As of now, both Travis and Circle CI are used for testing. Here is what I learned from my experience.

Read More

Android: Fragment related pitfalls and how to avoid them

  1. Don’t use platform fragments (android.app.Fragment), they have been deprecated and can trigger version-specific bugs. Use the support library fragments (android.support.v4.app.Fragment) instead.
  2. A Fragment is created explicitly via your code or recreated implicitly by the FragmentManager. The FragmentManager can only recreate a Fragment if it’s a public non-anonymous class. To test for this, rotate your screen while the Fragment is visible.
  3. FragmentTransaction#commit can fail if the activity has been destroyed.
    “java.lang.IllegalStateException: Activity has been destroyed”
    Why РThis can happen in the wild where say right before FragmentTransaction#commit() executes, the user gets a phone call and your activity is backgrounded and destroyed.
    How to trigger manually – The easy way to manually test this is to add a call to Activity#finish() right before FragmentTransaction#commit.
    Fix¬†– Before doing FragmentTransaction#commit(), check that the activity has not been destroyed –Activity#isDestroyed() should return false.
  4. FragmentTransaction#commit can fail if onSaveInstanceState has been called.
    “java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState”
    Why РThis can happen in the wild where say right before FragmentTransaction#commit() executes, the user gets a phone call and your activity is backgrounded and paused.
    How to trigger manually – The easiest way to manually trigger this behavior is to call Activity#onSaveInstanceState in your uncommitted code right before the call to FragmentTransaction#commit
    Fix 1 Рcall FragmentTransaction#commitAllowingStateLoss but that implies that your fragment would be in a different state then the user expects it to be.
    Fix 2 – The better way is to ensure that the code path L which leads to FragmentTransaction#commit is not invoked once Activity’s onSaveInstanceState has been called but that’s not always easy to do.
  5. FragmentManager is null after Activity is destroyed.
    “java.lang.NullPointerException: … at getSupportFragmentManager().beginTransaction()”
    Why РThis can happen when the activity has been destroyed before getSupportFragmentManager() is invoked. The common cause of this is when a new fragment has to be added in response to a user action and the user immediately backgrounds the app, again, say due to a phone call, after clicking the button before getSupportFragmentManager() is invoked. Another common case is where an AsyncTask which will call getSupportFragmentManager() in onPostExecute and while the task is engaged in the background processing (doInBackground), the activity is destroyed.
    How to trigger manually – call `Activity#finish()` before `getSupportFragmentManager().beginTransaction()`
    Fix – If getSupportFragmentManager() is being invoked in the Activity, check if it’s null. If it is being invoked inside a Fragment check if isAdded() of the Fragment returns true before calling this.
  6. Avoid UI modifications which are not related to a FragmentTransaction with FragmentTransaction committed using commitAllowStateLoss
    Why¬†– Any UI modifications like modifications of the text in a TextView are synchronous while the execution of a FragmentTransaction via `FragmentTransaction#commitAllowStateLoss()` is asynchronous. If the activity’s onSaveInstanceState is invoked after the UI changes have been made but before commitAllowStateLoss is called then the user can end up seeing a UI state which you never expected them to see.
    Fix¬†– use commitNow() or hook into FragmentManager.FragmentLifecycleCallbacks#onFragmentAttached(). I will admit this I haven’t found a simpler fix for this. And this issue is definitely an edge case.
  7. Saving Fragment State
    As mentioned earlier, a Fragment is re-created on activity recreation by FragmentManager which will invoke it’s default no-parameter constructor. If you have no such constructor then on Fragment recreation, the app will crash with “java.lang.InstantiationException: MyFragment has no zero argument constructor”. If you try to fix this by adding a no argument constructor then the app will not crash but on activity recreation say due to screen rotation, the Fragment will lose its state. The right way to serialize a Fragment’s state is to pass arguments in a Bundle via setArguments.

    MyFragment myFragment = new MyFragment();
    myFragment.setArguments(mBundle);
    return myFragment;
    

    The Fragment code should then use getArguments() method to fetch the arguments. In fact, I would recommend a Builder pattern to hide all this complexity.

    Consider this complete example,

    public class MyFragment {
    	
    		private static final String KEY_NAME = "name";
    	
    		public static class MyFragment.Builder {
    		   private final Bundle mBundle = new Bundle();
    		   
    		   public Builder setName(String username) {
    		       mBundle.putInt(KEY_NAME, clickCount);
    		       return this;
    		   }
    		   
    		   public MyFragment build() {
    		      MyFragment myFragment = new MyFragment();
    		      // Set the username
    		      myFragment.setArguments(mBundle);
    		      return myFragment;
    		   }
    		}
    		
    		public MyFragment() {
    			// Get the user name
    			@Nullable String username = getArguments() != null ? getArguments().getString(KEY_NAME, null) : null;
    		}
    	}
    	
    	if (!isDestroyed()) {
    	   // Create the Fragment
    		MyFragment myFragment = new MyFragment().Builder().setName(username).build();
    		// Add the Fragment
    		FragmentTransaction ft = getSupportFragmentManager().beingTransaction();
    		ft.add(myFragment);
    		ft.commitNowAllowingStateLoss();
    	}
  8. Inside your Fragment code, if you want to decide whether it is safe to execute a UI code or not, rely on isAdded(), if it returns true, it is safe to perform UI modifications, if it returns false, then your Fragment has been detached from the activity either because it has been removed or because the host (Fragment/Activity) is being destroyed.
  9. Callbacks
    To callback into the parent activity/fragment in case of action inside your Fragment, say, a user click, provide an interface (say, MyFragmentListener) which the holding activity/Fragment should implement. In Fragment#onCreateView() get the host via getHost(), cast it to MyFragmentListener, and store it in the instance variable of your Fragment class. Set that instance variable to null in Fragment#onDestroyView(). Now, you can invoke callbacks on this MyFragmentListener instance variable.
  10. Backstack
    Backstack is nuanced and my grasp of it is still limited. What I do understand is that if you want your Fragment to react to the back key press then you should call FragmentTransaction#addToBackStack(backStackStateName) while adding the Fragment via FragmentTransaction and remove it while removing it. Removal from the back stack is a bit more nuanced. Note that, manual removal of a fragment from the back stack is not required in Activity#onBackPressed() as long as your Activity inherits from FragmentActivity.

    SupportFragmentManager manager = getSupportFragmentManager();
    	FragmentManager.BackStackEntry entry = manager.getBackStackEntryAt(manager.getBackStackEntryCount() - 1);
    	if (backStackStateName.equals(entry.getName())) {
    	   manager.popBackStack(backStackStateName, FragmentManager.POP_BACK_STACK_INCLUSIVE);
    	}
    }

 

Android: Handling JPEG images with Exif orientation flags

A JPEG file can have Exif metadata¬†which can provide the rotation/translation field information for a raw JPEG image. So, a landscape raw JPEG image could actually be a portrait¬†because it’s EXIF¬†orientation could be set to ORIENTATION_ROTATE_90, the best way to handle such scenarios is to either use a library like Picasso or Glide or at least learn from them. Here is a piece of code from Picasso which loads a JPEG as an in-memory bitmap and performs the right translation/rotation.

// Get the orientation
ExifInterface exifInterface = new ExifInterface(imageFilePath);
int exifOrientation = exifInterface.getAttributeInt(TAG_ORIENTATION, ORIENTATION_NORMAL)

// Take the source of these methods from 
// https://github.com/square/picasso/blob/31779ac2cb971c4534cc17bd437fab1aa0083d3d/picasso/src/main/java/com/squareup/picasso3/BitmapHunter.java#L625-L659
int exifRotation = getExifRotation(exifOrientation);
int exifTranslation = getExifTranslation(exifOrientation);

Matrix matrix = new Matrix();
if (exifRotation != 0) {
  matrix.preRotate(exifRotation);
}
if (exifTranslation != 1) {
  matrix.postScale(exifTranslation, 1);
}

// Now use this matrix to create a new Bitmap from the existing Bitmap

 

Mac OS: App Translocation and Android Studio updates failure

I installed Android Studio via homebrew “brew cask install android-studio” as a part of my automated Mac OS setup. Recently, Android Studio prompted me that an update is available. When I accepted to update, it failed with an error “Studio does not have write access to /private/var/folders/wt/rjv6_wcn4f97_2nth7fqftqh0000gn/T/AppTranslocation/19A80F28-865B-41FC-AA87-B8E43C826FCB/d/Android Studio.app/Contents. Please run it by a privileged user to update.” This¬†error was confusing; I was running Android Studio as myself, a nonprivileged user and the same user owned this directory. Googling it a bit for AppTranslocation took me here.

From this point onward, the issue and the fix were relatively straightforward. Apple marked Android Studio as quarantine and hence was in a read-only directory. Quarantine status was confirmed by

$ xattr -l /Applications/Android\ Studio.app/
com.apple.quarantine: 00c1;5ad6b178;Chrome;9B843802-B7C1-4F48-BC68-09D8F81E6784

The fix was relatively simple as well

$ xattr -d -r -s com.apple.quarantine /Applications/Android\ Studio.app/

Update worked as expected after this.

Setting¬†HOMEBREW_CASK_OPTS=–no-quarantine seems to enable¬†this behavior for all the future installs.

-->