Started guidelines folder for new developers.
Added missing drawable resources.

Need to have fallback resources in the default folders.  Added a few extra configuration categories for completeness.
Added new preference screen for mapping buttons/axes.

A more visual layout that minimizes localization requirements.

Slightly different interactions with user that permits more flexible mapping implementations.
 - Current method: user picks an N64 button/axis, and then mupen listens for input signals and maps the first input it hears
 - New method: user presses inputs, then taps a particular N64 button/axis on screen, and then mupen adds the entry to the map

The difference is subtle but important. Imagine that the user wants to map N64 button Z to positive analog trigger.  Many analog triggers produce a value of -1 at rest, +1 at fully depressed, and float values in between.  The native gamepad listener is notified as soon as the trigger changes state from -1 to -0.99.  With the current approach, mupen maps the first thing it hears and thus maps N64 button Z to negative analog trigger (i.e. trigger at rest).  Not the desire of the user.  With the new method, the user can move the trigger through its intermediate states to the desired state, and then ask for mupen to map it.  Problem solved, and equally intuitive to the user.
Temporary feature removal: localized string resources.

In preparation for major reworking of preference menu system.  Will significantly ease debugging in the interim.  Feature will be re-inserted if/when the branch is ready for integration with master.
[Broken] Commit 1/3: Deleted current menu system (xml and java).

Breaking these commits into parts so that git history is more readable.
[Broken] Commit 2/3: Updated strings and implemented new preference menu.

Breaking these commits into parts so that git history is more readable.

Changed string key names to follow a more systematic convention.  Re-localization will be a small chore later, but I think this approach scales better and is easier to maintain.  Also decouples the design elements (strings) from the procedures (java) better.  For example, string key name isn't an abbreviated form of the english string (what happens if the designer wants to change the string? does the programmer update the key name?).  Instead, the new approach uses key names that are organized by the widget they pertain to (key=myExampleWidget, title=myExampleWidget_title, summary=myExampleWidget_summary, etc.)

Changed some of the English strings to follow the capitalization and stylistic conventions officially recommended by Android.  Changed names of some concepts to reduce my own confusion.  E.g. "touchpad" confuses me because it refers to xperia controls (not the touchscreen); "gamepad" confuses me because it refers to the touchscreen (not an external gamepad/joystick), etc.

Using Android's built-in Preference classes (CheckboxPreference, ListPreference, PreferenceScreen, PreferenceGroup).  Should make it much easier to maintain and extend the menu system, and reduce the amount of boiler-plate code needed to persist user configuration settings to storage.

Created a convenience class, Settings, which just wraps the native preference data to simplify read access, promote type-safety, and consolidate code maintenance to just a few files (Settings.java and preferences.xml).  Also, makes it harder for run-time errors to hide, since all the "risky" accessor functions (SharedPreferences.getBoolean, getString, etc.) are consolidated into the constructor.  So we don't have to wait for a corner case to reveal a broken access attempt; instead it just happens up front.
[Broken] Commit 3/3: Updated java files to use new preference system.

Breaking these commits into parts so that git history is more readable.
New universal architecture for input mapping/listening across all hardware/Android versions/IMEs.

Inputs are collected from the hardware (keyboard, gamepad, touchscreen, xperia hw) and converted to an intermediate "input code" and "strength".  "Strength" is always a float in the range 0-1 (NOT 0-80).  For digital buttons, strength only takes on the values of 0 and 1, but analog axes can range anywhere between.  "Input code" is a signed integer that extends the current notion of "key codes".  Keys, buttons, and IME-mapped analog axes are mapped to positive input codes in the range 1-255.  Native analog axes provided by Android 3.1+ are mapped to negative input codes, with the LSB encoding axis direction.

Inputs are collected by the "InputFunnel" class and its hardware-specific subclasses.  Funnels provide a universal language for abstracting away the hardware variations.  E.g. we should be able to make a funnel for the xperia touchpad and integrate it into the architecture as well.  Input funnels are agnostic to all things N64; they merely provide "input codes" and "strengths" to the subscribed listeners.

Funneled inputs are mapped to N64 controls using the "InputMapPreference" class.  This class encapsulates the entire bidirectional map between "input codes" and N64 buttons/axes.  These maps will be persistable using Android's built-in preference architecture.  Each player's controller will be associated with its own InputMapPreference instance.

Finally, the GameActivity* classes will listen to a single (hardware-dependent) InputFunnel object, and use the InputMapPreference objects to translate from the input codes and strengths to the correct player's N64 buttons/axes, passing them to the core.

Simple!