Facebook remains in the dark ages

What is HTML5? Most people would be able to answer this question, whether they are highly educated IT professionals or a hobby programmer, but at Facebook it seams as if they are still struggling with this strange concept.

The thing that I love the most about HTML5, is the fact that we no longer need any plug-ins to be installed in browsers. It's canvas and socket features replaces the old and terrible Java Applets. Don't get me wrong, I love Java. It's a nice programming language and it's great when you want to easily port programs across multiple architectures. But the Java Applets is one of the worst thing ever created, next to Microsoft's ActiveX (Along with their Browser). It will not be missed. The HTML5 Video and EME features replaces both Flash and Silverlight. Both of which brings nothing but instability and security vulnerabilities.

For a long time now, I have not had any plug-ins installed in my browser and I have not had any reason to. It seams that the vast majority of websites has either switched to full HTML5 or at least provide this as a second option. The few sites that don't, are not very important. At least that has been my observation until today.

My brother wanted to show me a video on my laptop. He navigated to Facebook and logged into he's account. He then searched for a specific video and tried to play it, but it wouldn't start because Flash is not installed in my browser. I don't use Facebook myself, so I have never noticed this. But Facebook, one of the worlds largest websites, do not have any support for HTML5 playback. Personally I have never liked Facebook, I cannot say why as I don't really know it myself. Nevertheless I have always pictured them as technologically advanced. Properly because I could not imagine a website being able to reach this magnitude of popularity while falling behind in this area. They proved me wrong.

Why am I writing about this? I have no idea. Maybe it's just the chock getting to me. Next to Google/Youtube, this was the last place that I would ever expect to be so far behind in technology. I mean this is freaking Facebook that we are talking about, and their only video solution is Flash? A technology that should have been extinct by now. And this is just the observation I made in the 2 minutes that my brother was trying to get this video to play. This is something that I would have expected from a small personal site where the owner had not yet had the time or resources to make the switch. But even those sites are up-to-date. The only one missing is the one that should have plenty of resources and highly skilled personal to do it, although I am starting to doubt the later.

The world of Root and Xposed Bridge

People have a tendency to install and enable things that they do not fully understand. In this article I will try to explain just what Root and Xposed Bridge is and how dangerous it can be. Don't get me wrong, I love both of these things, but it is important to be careful and not grant just any application these types of rights.

Let's picture a small village. In the middle of this village is a large bank. It is surrounded with a lot of smaller buildings. The bank represents the core Android system while the buildings are all of the Applications. All the people within each building can communicate with one another since they are all within the same building. If a building needs to communicate with another building, it has to send someone across town to the other building. It is then up to the people in that building to decide whether or not they want to let that person inside. While inside, the person can make a request or a delivery. Maybe he wants to borrow some sugar. He then delivers the response (in this case the sugar) back to his building. The same applies for the bank which is surrounded by guards. To make a request for a specific item in the bank, a building will need a permission slip for that item in order to bypass the guard watching it.

One building however has an Xposed Module implemented. In this case it is a specific type of person, I spy if you will. The building can send this person over to the bank and make him act as a guard. The bank and it's other guards will not not sense that anything is wrong. This spy can now move around in any section of the bank without any permission slip. He can steel items, place new items or make changes to the existing once without anyone asking questions. He can also disguise himself as a member of other buildings and walk around those without an invite. This spy is essentially a god amongst men.

In Android it allows applications to provide features not normally available, like changing theme and colors in any part of the system, create security modules that can restrict other applications from gathering specific information and much more. But it also allows application to do things that you might not want it to, like gathering information and uploading it to a server. Since the module can do whatever it wants, there is no way to restrict it.

Root is similar. It is the main built-in Administrator in the Linux kernel (Which Android is built on top of). In this case it acts as the emperor of the village. It is the main authority in the system and no one would dare to tell it no. It can move, do and behave just as it feels like without no one trying to stop it. The most important thing to note here is that Xposed Modules is able to acts as root, even if the device is not rooted. It is also important to note that gaining root via Xposed Bridge will not trigger your normal Root Popup window on rooted devices. So you will not even know that this has happened.

There is no doubt that devices with Xposed Bridge and Root enabled are much more fun. This article is not meant to scare anyone from rooting their devices or install Xposed Bridge on them. It is meant to inform people about the danger of doing so to make them more aware next time they enable an Xposed module or grant root to an application asking for it. Make sure that the application in question can be trusted, which most importantly mean that you should not allow this for Closed Source applications. If the source codes are close, there is no telling what has been implemented into the application.

So the next time you think about enabling an application in Xposed Bridge or grant root to an application, do some research first. Make sure that you can find a link to the source codes, make sure that the developer is contactable, do some searches to make sure that others have not warned about this application.

In any case, do not just blindly enable whatever the application asks for.

Check if current user is owner

One would think that this is a simple task in Android, especially since one would expect Google to have added some kind of tool for it, like something to return the current user id. Well they have, but they also decided to hide it. Android actually has a very pore collection of tools when it comes to working with multi-users. Like many things in the framework, Google did not think that apps had any reason to access to any information regarding the users. Android's sources might be fully open, but the framework is more closed than boot loaders on HTC devices.

The user id is normally not a very important information since it is nothing more than a number from 10 and up, except for the owner which have 00. The only thing that this number can tell you, is which user was created first. But checking for the 00 id to identify the owner can be very helpful. You may be working on an app that should have certain restrictions when not used by the device owner. Maybe your app should not be used by other users at all. In any case identifying the owner is useful enough that Google should have added something like isOwner() to the UserManager service.

Searching the web, it seams like people are using a lot of reflection to access some of the hidden classes in order to identify the device owner. However reflection is not really needed, and it should be avoided if possible, simply because hidden classes are not official and might change over time. If this happens, apps need to be updated or they will be broken on future versions of Android.

Even though Android did not directly provide any access to the current user id, they did indirectly do this in one way, namely the app data folder. In Android 4.1 and below, all app data was placed in /data/data, but in newer versions they are placed in /data/user/[userid] and all apps have access to their own data folder. So to get the current user id from within an app, you only need to get the name of the parent folder to your apps data location. This is very simple.

MainActivity.java:

public class Utils {
 public static boolean isOwner(Context context) {
  /* 
   * Get the parent location. 
   * This can either be /data/user/[userid] or /data/data depending on Android version.
   */
  File file = new File(context.getApplicationInfo().dataDir).getParentFile();
  
  /*
   * Get the name of the folder in the parent location. 
   * This can either be [userid] or data
   */
  String user = file.getName();
  
  try {
   /*
    * Returns TRUE if this user has the id 0 (device owner)
    */
   return Integer.valueOf(user) == 0;
   
  } catch (NumberFormatException e) {
   /*
    * The user variable contained "data". 
    * This is not an multi-user environment, which means that we only have the device owner available.
    */
   return true;
  }
 }
}

The above code is even backward compatible with Android version without multi-user support, without any need to check the current API level. And we did not use any reflection or unsupported classes/methods.

JNI / Android NDK

If you visit the Android developer page and read about Android's NDK, it will seam as if Google is trying to scare people from using it and just stick with Java. In most cases this will properly be the best idea. Java is a great language and does a good job for most tasks. However JNI is not as dangerous as Google is trying to make it. Most of Android is build on JNI and IPC. Information is being parsed in and out of JVM and between processes constantly, so why should applications not take advantage of this as well?

One thing to remember about JNI is that it creates a bit of overload to parse in and out of JVM. But depending on the task, this is not necessarily enough downside to keep away from it. The best way to figure out whether or not to use C/C++ or Java, is to test your task in both and then compare the result.

One good example of a task better suited for JNI could be some extensive file operations. For this example we will collect the content of the stat file for all currently running processes on a device. On my device running Android 5, we are talking about rounded 300 files. We add this to a loop which will run 100 times which in turn will create 3000 file read operations.

The first thing we need, is a basic activity to run our examples in.

MainActivity.java:

public class MainActivity extends Activity {
 @Override
 protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  
  setContentView(R.layout.activity_main);
  
  StringBuilder builder = new StringBuilder();
  
  for (int i=0; i < 2; i++) {
   double start = System.nanoTime();
   int files = 0;
   
   for (int x=0; x < 100; x++) {
    String[] list = null;
    
    switch (i) {
     case 0: list = JavaCollector.collect(); break;
     case 1: list = NativeCollector.collect();
    }
    
    files += list.length;
   }
   
   double end = System.nanoTime();
   
   builder.append(i == 0 ? "JavaCollector" : "NativeCollector\n");
   builder.append("Files = " + files + "\n");
   builder.append("Time = " + ((end - start) * Math.pow(10, -9)) + " seconds\n");
   builder.append("\n");
  }
  
  TextView view = (TextView) findViewById(R.id.textview);
  view.setText(builder.toString());
 }
}

We also need a Java method to do the collection work. We will separate the native method and the Java method into two files in this example. It makes it easier to keep an overview.

JavaCollector.java:

public class JavaCollector {
 
 /*
  * Re-defined regexp to match directories in /proc with process id's
  */
 protected static final Pattern REFEXP_PID = Pattern.compile("^[0-9]+$");
 
 /*
  * The method that collects all the file data
  */
 public static String[] collect() {
  /*
   * Get a listing from the /proc directory
   */
  String[] procListing = new File("/proc").list();
  
  /*
   * Define our input stream
   */
  BufferedReader in = null;
  
  /*
   * Create a temp container for the file output
   */
  ArrayList<String> lines = new ArrayList<String>();
  
  /*
   * Handle each entity in /proc
   */
  for (String procEntity : procListing) {
   /*
    * We only want the pid directories
    */
   if (REFEXP_PID.matcher(procEntity).matches()) {
    try {
     /*
      * Open the sub directory stat file
      */
     in = new BufferedReader(new FileReader("/proc/" + procEntity + "/stat"));
     
     /*
      * Get the content of the stat file
      */
     lines.add(in.readLine());
     
    } catch (IOException e) {} finally {
     if (in != null) {
      try {
       /*
        * Close the file
        */
       in.close();
       in = null;
       
      } catch (IOException e) {}
     }
    }
   }
  }
  
  /*
   * Create and return a string array
   */
  return lines.toArray( new String[ lines.size() ] );
 }
}

And we cannot compare the above Java class to JNI without a native example as well.

NativeCollector.java:

public class NativeCollector {
 
 /*
  * Load our collector library
  */
 static {
  System.loadLibrary("collector");
 }
 
 /*
  * This is really a call to Java_com_example_NativeCollector_collect() in collector.cpp
  */
 public static native String[] collect();
}

collector.cpp:

JNIEXPORT jobjectArray JNICALL Java_com_example_NativeCollector_collect(JNIEnv *env, jobject thisObj) {
 /*
  * Open /proc
  */
 DIR* procDirectory = opendir("/proc");

 if (procDirectory != NULL) {
  /*
   * Create a temp container with minimum 100 indexes pre-allocated
   */
  std::vector<std::string> lines(100);

  /*
   * Create an input stream
   */
  std::ifstream in;

  /*
   * Create a variable for the proc entities
   */
  struct dirent* procEntity;

  /*
   * Handle each entity in /proc
   */
  while ((procEntity = readdir(procDirectory)) != NULL) {
   /*
    * We only want the pid directories
    */
   if (std::regex_match (procEntity->d_name, std::regex("^[0-9]+$") )) {
    /*
     * Open the sub directory stat file
     */
    std::string path = std::string("/proc/") + procEntity->d_name + "/stat";
    in.open( path.c_str() );

    if (in && in.good()) {
     /*
      * Get the content of the stat file
      */
     std::string line;
     std::getline(in, line);

     lines.push_back(line);
    }

    /*
     * Close the file
     */
    if (in) {
     in.close();
    }
   }
  }

  /*
   * Create Java return data
   */
  if (lines.size() > 0) {
   /*
    * Create a Java array
    */
   jobjectArray ret = env->NewObjectArray(lines.size(), env->FindClass("java/lang/String"), NULL);

   for (int i=0; i < lines.size(); i++) {
    /*
     * Place the line in a Java String
     */
    jstring stringObject = env->NewStringUTF( lines[i].c_str() );

    /*
     * Add the Java String to the Java Array
     */
    env->SetObjectArrayElement(ret, i, stringObject);

    /*
     * Release the Java String reference.
     *
     * Note: This is important. We can only have a limited ammount of Java objects
     * at a time and they are not auto released until we return to the JVM. And since we
     * are looping an unknown, but large, number of files, we could end up with a memory overflow.
     */
    env->DeleteLocalRef(stringObject);
   }

   /*
    * Return the array to JVM
    */
   return ret;
  }
 }

 /*
  * Return an empty array
  */
 return env->NewObjectArray(0, env->FindClass("java/lang/String"), NULL);;
}

If we compile and run this application, we will get the following result:

• JavaCollector$collect: 21.2 seconds
• NativeCollector$collect: 2.7 seconds
  
  This is not just slightly faster than Java, this is 87% faster. 

This is only a simple example. If it should be used in a real application, then depending on the amount of files and amount of data, it might be a good idea to make some sort of iteration mechanism to avoid memory overflow. But as the result shows, it is sometimes a good idea to check whether or not a JNI solution might be better. Java is not always the correct solution. 

So get started with:

1. Learning C/C++
2. Learning JNI
3. Setup your NDK
4. Bookmark the C++ manual and the JNI manual

Communication across the UI

One of the greater things in newer Android versions is the Fragments. It allows you to split the UI into smaller pieces that can be put together in different ways, depending on different circumstances like screen size and such. However some times you might need to adapt things in one Fragment based on some conditions in another. Talking to an Activity from within a Fragment is easy enough, but Fragments to Fragments is another thing. Especially since it is unadvised to have one specific Fragment talk to another specific one.

A better solution is to have a small message delivery system that works similar to Android's broadcast system. That way you can parse information between Fragments, but without targeting specific ones. For this we need an extended Activity that has these capabilities.

One issue with Java (or not, depending on who you ask) is that Java does not support multi-inheritance. I for one is quite fine with this, but I would like to see something like traits be introduced into the language. In this the problem lies with the many different Activity and Fragment classes that Android has available. We don't want to copy paste everything into each Activity and Fragment sub-class that we want to use.

With the lack of traits or similar, we will be using the famous logic trick instead where we place all the logic into one class, and then only create redirection in each of the Activity and Fragment classes. Not only will this limit the size of each Activity and Fragment class, but it will also make sure that we only have to edit one class if we want to change something.

ActivityLogic.java:

final public class ActivityLogic {
    public static interface IActivityLogic {
        public void onReceiveMessage(String message, Object data, Boolean sticky);
        public void onFragmentAttachment(IActivityLogicFragment fragment);
        public void onFragmentDetachment(IActivityLogicFragment fragment);
        public void sendMessage(String message, Object data);
        public void sendMessage(String message, Object data, Boolean sticky);
    }
    
    public static interface IActivityLogicFragment {
        public void onReceiveMessage(String message, Object data, Boolean sticky);
    }
    
    private final static class ActivityLogic_MessageHandler extends AbstractHandler<ActivityLogic> {
        public ActivityLogic_MessageHandler(ActivityLogic reference) {
            super(reference);
        }

        @Override
        public void handleMessage(Message msg) {
            ActivityLogic logic = getReference();
            
            if (logic != null) {
                IActivityLogic activity = logic.ActivityLogic_mActivity.get();
                
                if (activity != null) {
                    Set<IActivityLogicFragment> fragments = new HashSet<IActivityLogicFragment>(logic.ActivityLogic_mFragments);
                    Object[] input = (Object[]) msg.obj;
                    String message = (String) input[0];
                    Object data = input[1];
                    
                    activity.onReceiveMessage(message, data, false);
                    
                    for (IActivityLogicFragment fragment : fragments) {
                        fragment.onReceiveMessage(message, data, false);
                    }
                }
            }
        }
    }
    
    private Set<IActivityLogicFragment> ActivityLogic_mFragments = Collections.newSetFromMap(new WeakHashMap<IActivityLogicFragment, Boolean>());
    private Map<String, Object> ActivityLogic_mStickyMessages = new HashMap<String, Object>();
    
    private ActivityLogic_MessageHandler ActivityLogic_mMessageHandler;
    private WeakReference<IActivityLogic> ActivityLogic_mActivity;
    
    public ActivityLogic(IActivityLogic activity) {
        ActivityLogic_mActivity = new WeakReference<IActivityLogic>(activity);
        ActivityLogic_mMessageHandler = new ActivityLogic_MessageHandler(this);
    }
    
    public void onFragmentAttachment(IActivityLogicFragment fragment) {
        synchronized (ActivityLogic_mFragments) {
            ActivityLogic_mFragments.add(fragment);
            
            for (String message : ActivityLogic_mStickyMessages.keySet()) {
                fragment.onReceiveMessage(message, ActivityLogic_mStickyMessages.get(message), true);
            }
        }
    }
    
    public void onFragmentDetachment(IActivityLogicFragment fragment) {
        synchronized (ActivityLogic_mFragments) {
            ActivityLogic_mFragments.remove(fragment);
        }
    }
    
    public void sendMessage(String message, Object data) {
        sendMessage(message, data, false);
    }
    
    public void sendMessage(String message, Object data, Boolean sticky) {
        synchronized(ActivityLogic_mFragments) {
            if (sticky) {
                ActivityLogic_mStickyMessages.put(message, data);
            }

            ActivityLogic_mMessageHandler.obtainMessage(0, new Object[]{message, data}).sendToTarget();
        }
    }
}

The above Activity Logic class is only the first step towards getting our message delivery system working. Since this is meant to be used to communicate between Fragments, we still need a Fragment Logic class as well.

FragmentLogic.java:

final public class FragmentLogic {
    
    public static interface IFragmentLogic extends IActivityLogicFragment {
        public IActivityLogic getParent();
        public void sendMessage(String message, Object data);
        public void sendMessage(String message, Object data, Boolean sticky);
    }
    
    private WeakReference<IActivityLogic> FragmentLogic_mActivity;
    private WeakReference<IFragmentLogic> FragmentLogic_mFragment;
    
    public FragmentLogic(IFragmentLogic fragment) {
        FragmentLogic_mFragment = new WeakReference<IFragmentLogic>(fragment);
    }
    
    public void onAttach(IActivityLogic activity) {
        FragmentLogic_mActivity = new WeakReference<IActivityLogic>(activity);

        IFragmentLogic fragment = FragmentLogic_mFragment.get();
        if (fragment != null) {
            activity.onFragmentAttachment(fragment);
        }
    }
    
    public void onDetach() {
        IFragmentLogic fragment = FragmentLogic_mFragment.get();
        IActivityLogic activity = FragmentLogic_mActivity.get();
        
        if (fragment != null && activity != null) {
            activity.onFragmentDetachment(fragment);
        }
        
        FragmentLogic_mActivity.clear();
    }
    
    public IActivityLogic getParent() {        
        return FragmentLogic_mActivity.get();
    }
    
    public void sendMessage(String message, Object data) {
        sendMessage(message, data, false);
    }
    
    public void sendMessage(String message, Object data, Boolean sticky) {
        IActivityLogic activity = getParent();
        
        if (activity != null) {
            activity.sendMessage(message, data, sticky);
        }
    }
}

Now that we have all of the logic behind this delivery system, we need to extend some classes that will be using these classes. Let's start with the Activity class.

AbstractActivity.java:

public abstract class AbstractActivity extends Activity implements IActivityLogic {
    
    private ActivityLogic mLogic;
    
    public AbstractActivity() {
        mLogic = new ActivityLogic(this);
    }
    
    @Override
    public void onFragmentAttachment(IActivityLogicFragment fragment) {
        mLogic.onFragmentAttachment(fragment);
    }
    
    @Override
    public void onFragmentDetachment(IActivityLogicFragment fragment) {
        mLogic.onFragmentDetachment(fragment);
    }
    
    @Override
    public void onReceiveMessage(String message, Object data, Boolean sticky) {}
    
    @Override
    public final void sendMessage(String message, Object data) {
        mLogic.sendMessage(message, data);
    }
    
    @Override
    public final void sendMessage(String message, Object data, Boolean sticky) {
        mLogic.sendMessage(message, data, sticky);
    }
}

And we will of course also need a Fragment class.

AbstractFragment.java:

public abstract class AbstractFragment extends Fragment implements IFragmentLogic {
    
    private FragmentLogic mLogic;
    
    public AbstractFragment() {
        mLogic = new FragmentLogic(this);
    }

    @Override
    public final IActivityLogic getParent() {        
        return mLogic.getParent();
    }
    
    @Override
    public void onAttach(Activity activity) {
        super.onAttach(activity);
        
        mLogic.onAttach((IActivityLogic) activity);
    }
    
    @Override
    public void onDetach() {
        super.onDetach();
        
        mLogic.onDetach();
    }
    
    public void onReceiveMessage(String message, Object data, Boolean sticky) {}
    
    public final void sendMessage(String message, Object data) {
        mLogic.sendMessage(message, data);
    }
    
    public final void sendMessage(String message, Object data, Boolean sticky) {
        mLogic.sendMessage(message, data, sticky);
    }
}

And that's it. We now have one normal Activity and Fragment class that we can use. Note that these are abstract, this is because we use these to extend our actual ones.

Let's take a small example of how to use these.

SomeFragment.java:

public class SomeFragment extends AbstractFragment {
    @Override
    public void onResume() {
        // Send a message to other Fragments or the Activity
        if (someVariable == "someCondition") {
            sendMessage("tellSomeone", "someCondition");
        }
    }

    @Override
    public void onReceiveMessage(String message, Object data, Boolean sticky) {
        // Receive message from other Fragments or the Activity
        if (message.equals("someOtherCondition")) {
            // Do something
        }
    }
}

If we need other types as well, like DialogFragment or ActionBarActivity, we can re-use our logic classes to easily create them.