Wikimedia Apps/Team/Wikipedia Android app hacking

From MediaWiki.org
Jump to: navigation, search

We welcome volunteer contributions!

The Wikipedia Android app is completely open source and welcomes contributions from all. Follow the steps below to get started, and feel free to ping any member of the WMF Android dev team (bearND, dbrant, mdholloway, niedzielski) on #wikimedia-mobileconnect for assistance.

You can find our coding conventions here.

Open bugs and feature requests

Work items are tracked on our work board. First time app contributors are encouraged to consider an Easy task. Unassigned tasks in the "Bug Backlog", "Tech Debt Backlog", and "Product Backlog" columns are generally suitable for development and roughly organized by descending priority. (Please do not work on tasks in other columns like "Open Questions" and "Needs Triage".)

Set up a development environment

Create a developer account

See Developer access .

Add your SSH key to Gerrit

See Gerrit/Tutorial#Set Up SSH Keys in Gerrit.

Install JDK 8

JDK 8 is needed to build the Android app. To find your current version:

$ javac -version
javac 1.8.0_102

The open source OpenJDK may be installed on Debian / Ubuntu by executing sudo apt install openjdk-8-jdk. The closed source Oracle JDK may be installed from here.

Download and install Android Studio

https://developer.android.com/sdk/index.html

Run the setup wizard. Standard installation is fine. Installation will take a while.

Download the project source

With SSH credentials (requires Developer access):

git clone ssh://<USERNAME>@gerrit.wikimedia.org:29418/apps/android/wikipedia

Or anonymously:

git clone https://gerrit.wikimedia.org/r/apps/android/wikipedia

Import into Android Studio

Open Android Studio > Import project > select build.gradle from the downloaded repository.

Important: If you are prompted about upgrades to components (e.g., Gradle or the Android Gradle plugin) during the initial build, please click "Don't remind me again for this project." We update these components in dedicated patches after a thorough review of the release notes, but they have a way of showing up in unrelated patches if automatic IDE prompting is enabled.

Third-Party Plugins

Checkstyle-IDEA

IntelliJ's Checkstyle-IDEA plugin is useful in ensuring that your code will meet the project style guidelines. Install from Android Studio > Preferences > Plugins, restart to complete the installation, then add the custom configuration file for the project:

Android Studio > Preferences > Other Settings > click on the '+' in the upper pane and select /gradle/src/checkstyle.xml.

Make sure you activate the new configuration file by checking the checkbox next to it, so our checkstyle rules are enabled and deviations show up as errors in the code editor.

Install and configure git-review

Install git-review: apt-get install git-review (Debian/Ubuntu) or brew install git-review (OS X)

Set the default remote to origin:

git config --global gitreview.remote origin

Make changes and submit for review via Gerrit

After cloning the app repository, set it up for git review with git review -s in the project root.

Make and commit your changes, and provide a commit message describing your changes. (Please ensure that the commit message includes line breaks for lines running over 75 characters.) If your work is associated with a specific task in Phabricator, please include, as the last line of the commit message, the following line:

Bug: Txxxxxx (where xxxxxx represents the number of the Phabricator task, e.g., T149500).

After creating your commit, submit it for review with git review -R.

You'll most likely receive requests to update and resubmit the patch. (It happens to all of us!) Make these changes locally and amend your patch with git commit --amend. Submit it again for review with git review -R, and your amended patch will show up as a new revision of the same change in Gerrit, provided that you have not altered the Change-Id: line inserted as the last line of the commit message by git-review when submitting the initial commit.

Tip: To avoid CI test failures, it's a good idea to run checkstyle (./gradlew checkstyle) and the unit test suite (./gradlew testDevDebug or ./gradlew tDD) from the project root before pushing to Gerrit.

For more information, see Gerrit/Tutorial#Prepare to push your change set to Gerrit.

Automated Tests

The codebase supports two kinds of tests:

  1. JVM JUnit (preferred, off device, fast, less flaky)
  2. Android instrumentation (on device)

Command line usage

  • JVM JUnit
    ./gradlew testDevDebug
  • Android instrumentation
    ./gradlew connectedDevDebugAndroidTest
  • Both JVM JUnit and Android instrumentation (including screenshot tests)
    ./gradlew testAllDevDebug

Tips

  • When running testAll*, add the --continue flag to run the Android instrumentation tests even if the JVM JUnit tests failed.

Android Studio setup

Both kinds of tests are supported in Android Studio. You may toggle between them by changing the Test Artifact from View -> Tool Windows -> Build Variants. "Unit Tests" are JVM JUnit tests and "Android Instrumentation Tests" are Android instrumentation tests. A run configuration must be made to prior to executing the tests.

Run configurations

JVM JUnit
  1. Click Run -> Edit Configurations...
  2. Click Add New Configuration (a large plus icon) and select JUnit.
  3. Name the configuration.
  4. Change the Test kind to All in package.
  5. Set the package to org.wikipedia.
  6. Ensure the working directory is set to $MODULE_DIR$.
  7. Set Use classpath of module to app. (TODO: update screenshot)

2015-06-23-17-39-19-358208008.png

Android instrumentation

Android-studio-run-configuration-instrumentation-tests.png

testAll

Android-studio-run-configuration-test-all.png

Screenshot tests

Some Android instrumentation tests don't actually test much. Instead, they capture a screenshot to be diffed against an expected output. Since different platforms produce different results, tests must be executed on the Android N (API 24) Nexus S emulator. Tests are exercised and the screenshots downloaded by executing:

./gradlew screenshotTestsDevDebug

Or:

./gradlew testAllDevDebug

Both commands slowly run all Android instrumentation tests. To exercise specific tests, specify them. For example:

./gradlew screenshotTestsDevDebug -Pandroid.testInstrumentationRunnerArguments.class=org.wikipedia.navtab.NavTabViewTest,org.wikipedia.feed.view.CardLargeHeaderViewTest

Then perform a diff against the previously committed screenshots:

scripts/diff-screenshots

If you're executing tests quickly via the GUI (recommended), a good workflow is:

  1. Right click on the test to execute and click run. If you see a permission error the first time, execute ./gradlew grantPermissionDevDebug, then start over
  2. If successful, execute ./gradlew pullScreenshots && scripts/diff-screenshots

The turnaround should be about a minute.

Once the screenshots are ready for versioning, move them from app/screenshots to app/screenshots-ref. git-diff-img is one way to compare versions before committing.

Conventions

  • Java code must run cleanly against Checkstyle
  • JavaScript must run cleanly against JSHint
  • We're working to be lint free! Currently Android Linting has many offenders but new contributions should help us progress towards zero.
  • Python changes should run cleanly against flake8.
  • All Android and JVM unit tests should pass.
  • Git commit messages should conform to the Gerrit/Commit message guidelines
  • Documentation should conform to the Wikipedia manual of style
  • When making changes to any strings.xml, corresponding explanatory text should be added to values-qq/strings.xml
  • Third-party libraries must meet acceptance criteria
  • Patches should conform to our coding conventions

Help make it better!

Pick a task from Phabricator:

Testing:

See pending/recent code reviews:

Appendix

Tips

Optimizing Gradle builds

The Gradle build system requires a notoriously large amount of system resources, but there are ways of speeding it up and making sure it works consistently. Add the following lines to your ~/.gradle/gradle.properties file:

org.gradle.daemon=true                                                          
org.gradle.parallel=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx2048M

WebView debugging in Chrome

Wikipedia for Android makes extensive use of WebViews. To debug WebView activity, navigate Google Chrome to chrome://inspect/#devices, then click on the topmost “inspect” link under “WebView in org.wikipedia.” From there you can debug the WebView like any other web site in Chrome.

Useful Gradle commands

If you prefer command line use the wrapper script in the root of the repo:

./gradlew

To run a clean debug build:

./gradlew -q clean assembleDevDebug

You can skip the clean part usually, which makes it much faster (from 1m:05s to 7s on my box):

./gradlew -q assembleDevDebug

To install build on device/emulator:

./gradlew -q installDevDebug

To see ProGuard output:

./gradlew clean --info proguardDevRelease

To run checkstyle:

./gradlew checkstyle

To run Lint:

./gradlew lintDevDebug

To refresh dependencies (usually not needed):

./gradlew --refresh-dependencies

To list dependencies:

./gradlew app:dependencies --configuration compile

Making apt work in Ubuntu 64-bit

If you're using 64-bit versions of Ubuntu, you might see this error when building with gradle: "Cannot run program '~/.android-sdk/build-tools/22.0.1/aapt': error=2, No such file or directory". To fix this error, install the following packages:

sudo apt-get install lib32stdc++6 lib32z1

Working with Vagrant and the Content Service

  • To work with a local Vagrant instance, change the mediaWikiBaseUri developer setting and optionally disable mediaWikiBaseUriSupportsLangCode.
  • To work with a local RESTBase instance, update RESTBaseUriFormat and optionally enable useRestbase_setManually.
  • mediaWikiBaseUriSupportsLangCode controls whether the wiki language of mediaWikiBaseUri is prefixed.
  • mediaWikiBaseUri and mediaWikiBaseUriSupportsLangCode are the second argument of RESTBaseUriFormat.
  • useRestbase_setManually and useRestbase can affect whether a MediaWiki or RESTBase client is used internally. When a MediaWiki client is forced, RESTBaseUriFormat is unused.
  • The Wiktionary domain is currently hardcoded. Ex: http://localhost:6927/en.wiktionary.org/v1/page/definition/dog
  • It is recommend to fully terminate the app process after changing any of these settings.

Beta cluster config

Ex:

RESTBaseUriFormat (default): %1$s://%2$s/api/rest_v1/
mediaWikiBaseUriSupportsLangCode (default): enabled
mediaWikiBaseUri (nondefault): https://wikipedia.beta.wmflabs.org

Local MediaWiki with production English Content Service config

Ex:

RESTBaseUriFormat (nondefault): %1$s://en.wikipedia.org/api/rest_v1/
mediaWikiBaseUriSupportsLangCode (nondefault): disabled
mediaWikiBaseUri (nondefault): http://localhost:8080

Auth manager config

RESTBaseUriFormat (default): %1$s://%2$s/api/rest_v1/
mediaWikiBaseUriSupportsLangCode (nondefault): disabled
mediaWikiBaseUri (nondefault): http://authmanager.wmflabs.org

Local Content Service config (broken)

Ex:

useRestbase_setManually (nondefault): enabled
useRestbase (default): enabled
RESTBaseUriFormat (nondefault): http://localhost:6927/%2$s/v1/
mediaWikiBaseUriSupportsLangCode (default): enabled
mediaWikiBaseUri (default): https://wikipedia.org

This doesn't quite work at moment. The app attempts to use a RESTBase feed/ endpoint when page/ is needed for the Content Service.

Local Vagrant with local Content Service config (broken)

useRestbase_setManually (nondefault): enabled
useRestbase (default): enabled
RESTBaseUriFormat (nondefault): http://localhost:6927/%2$s/v1/
mediaWikiBaseUriSupportsLangCode (nondefault): disabled
mediaWikiBaseUri (default): http://localhost:8080

This is currently broken for same reason the local Content Service config is.

Scripts

Setup

cd scripts
virtualenv -p python2 .env
. .env/bin/activate
pip install -r requirements.txt

Note: the lxml Python module seems to have system package dependencies on Debian and Ubuntu. If you're missing headers, try apt install libxml2-dev libxslt1-dev python-dev.

Troubleshooting Script Setup

On OS X a few of us ran into the issue that `libxml` couldn't get compiled. Running the following command helped:

xcode-select --install

If this still doesn't work, you might also want to try:

pip install sh jinja2 unicodecsv

Update bundled CSS files

The various CSS files for this project are generated by the *.less files found in the MobileFrontend and MobileApp MediaWiki extensions.

You'll need a MediaWiki installation, MediaWiki-Vagrant recommended, to generate them.

In the ./vagrant directory:

vagrant enable-role mobileapp mobilefrontend
vagrant provision

Change the url in scripts/make-css-assets.bash to http://127.0.0.1:8080/w instead of the bits url, then run the script and test.

Note: your system may be unable to run the Android emulator and a Vagrant / VirtualBox instance simultaneously.

Update bundled JavaScript

Portions of JavaScript code run inside the WebView component that displays articles.

This code is prepackaged using Grunt, which must be re-run every time the master .js files are edited before building.

Preparing:

First, install the Grunt CLI tool:

npm install -g grunt-cli

Install dependencies for packaging:

cd www
npm install

Building:

cd www
grunt

This will produce output files under app/src/main/assets which will be included in the apk file.

Update generated static data files

cd scripts
python make-templates.py
mv *.java ../app/src/main/java/org/wikipedia/staticdata/

Alpha build server

See Alpha build server.

Publishing to Sonatype OSSRH

See Publishing to Sonatype OSSRH.