Droidcon Spain 2015 - One app to rule them all: Methodologies, Tools & Tricks to achieve an effective white label model

Droidcon Spain 2015 - One app to rule them all: Methodologies, Tools & Tricks to achieve an effective white label model

Watch the presentation: https://youtu.be/d772fKxi0lY

This presentation shows how Android Development is carried out in a corporate environment like bq following a white label model attending to concepts like quality of software, scalability, reusability, maintainability, client personalization…

The development workflow is presented by giving details on the use of Gradle, Jenkins and additional tools created by the Android bq team in order to automate processes.

On the other hand, details about how the QA is carried out, as well as solutions to Android challenges related to our experience preinstalling apps on bq devices are revealed.

4143a69d2d7722f3f687c097c70c4613?s=128

Daniel Gallego Vico

April 23, 2015
Tweet

Transcript

  1. 1.

    One app to rule them all: Methodologies, Tools & Tricks

    to achieve an effective white label model Daniel Gallego Vico - Android architect at bq ! daniel.gallego@bq.com ! @thanos_malkav
  2. 3.

    Apps Android at bq • 7 DEVs + 3 QAs

    + 2 UX/UI • Several projects • From pure SW to some involving HW • Agile methodologies • Scrum ban supported by Atlassian tools
  3. 4.

    My goal here • Show how Android Development is carried

    out in a corporate environment • Following a white label model • Mandatory concepts: • Quality, scalability, reusability, maintainability, client personalization…
  4. 5.

    Our use case • One project supporting 3 business models

    • eBooks ecosystem • Pre-requisites: • Android minSDK 15 • Smartphone & Tablet • i18n
  5. 7.

    Achievements 33 clients Apps on Google Play >13K Daily active

    users < 1% Crash rate 5 languages National & International
  6. 9.

    Ideas behind automation • Scalability • If we can support

    1 client, we should support ∞ • Reusability • If you do something twice, then automate it • Maintainability • Understandable architecture and processes • Everything has to be documented
  7. 11.

    Gradle • 7 signing configs • Build variants • 4

    build types: qa, qa2, staging, pro • 34 product flavors: white label + 33 clients • Development • Enable debug if connected via USB • Obfuscate if not connected via USB • Upload generated artifacts (APKs) to our repository using Maven Gradle plugin Build types Flavors Development
  8. 12.

    Gradle + Jenkins • Use of custom tasks to be

    invoked by Jenkins • Decouples Jenkins from general Gradle tasks • Parametrized using environment variables in Jenkins machine • Executed sequentially by using: • Custom subtasks + dependsOn + mustRunAfter • 3 main custom tasks • jenkinsTestsTask: run tests + assemble one variant • jenkinsCITask: run tests + assemble 3 variants + upload Snapshots • jenkinsFlavorTask (with parameters): run tests + assemble X flavors + upload Snapshot/Release
  9. 13.

    Gradle custom tasks // Main custom task task jenkinsFlavorTask {

    dependsOn jenkinsFlavorAssembleSubTask, uploadArchives uploadArchives.mustRunAfter jenkinsFlavorAssembleSubTask } ! ! // Custom subtask that assembles selected flavor task jenkinsFlavorAssembleSubTask { def flavorsArray = "$System.env.PARAM_FLAVORS" flavorsArray.each { flavor -> dependsOn 'assemble' + flavor + 'qa', 'assemble' + flavor + 'qa2, 'assemble' + flavor + 'staging', 'assemble' + flavor + 'pro' } }
  10. 14.

    Jenkins • 4 jobs associated to Gradle main custom tasks

    • Test • jenkinsTestsTask: triggered by every push to the git repository • CI • jenkinsCITask: every friday evening • Snapshot • jenkinsFlavorTask: on demand • Release • jenkinsFlavorTask: on demand
  11. 15.

    Automatic asset generation • Asset client-based personalization at compile time

    • Lollipop tint features work at run time • New Support Library 22.1 allows tint by using DrawableCompat • Steps: • White label assets extracted from designers repository • Processed according to each client look&feel • Replacement of white label assets by new ones before compiling
  12. 16.

    Sorolla project • Image scaling, tinting & coloring utilities optimized

    for Android resources • Resources supported while keeping their properties: • drawable-dpi images, 9-patch, vectors (.pdf & .svg) • Requirements: • Python 2.7.x, ImageMagick & GhostScript http://opensource.bq.com/sorolla
  13. 17.

    Sorolla API • Sorolla.color_resource(source_file, dest_file, fill_color) • Colors a raster

    resource detecting if it's a 9-patch in order to color it properly • Sorolla.scale_resource(source_file, dest_file, scale) • Scales a resource detecting if it's a 9-patch in order to scale it properly • Sorolla.tint_resource(source_file, dest_file, tint_color) • Tints a gray-scaled raster resource detecting if it's a 9-patch in order to tint it properly
  14. 19.

    Future work • Gradle takes too much time generating all

    APKs • Solution: • Adapting APKs by client without recompiling the whole project • Avoid compiling .dex files for each flavor • Preliminar results show significant reduction of time
  15. 20.

    1. Generate only the white label APK 2. Decode !

    $ java -jar apktool.jar decode whiteLabel.apk -o folder 3. Change flavor related data • Graphic resources • XMLs: strings, colors, app configuration… 4. Build ! $ java -jar apktool.jar build folder -o client.apk 5. Resign and align ! $ zip -d client.apk META-INF/\* $ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore myReleaseKey.keystore clientSigned.apk clientAlias $ zipalign -v 4 clientSigned.apk clientSignedAligned.apk APK adaptation: steps
  16. 22.

    Future Gradle + Jenkins • Simpler Gradle • Signing managed

    when building APK • Variants: • 2 build types (debug and release) • 4 product flavors (qa, qa2, staging and pro) • Total: 8 build variants (17 times less!) • Depend on build type to enable/disable debugging, obfuscation... • Jenkins: less jobs and more power! • Single Jenkins job listening to changes on the repo and executing a proper action depending on the branch changed • Upload generated artifacts (APKs) to our repository using Maven Jenkins plugin
  17. 24.

    Is TDD the best option? • Maybe in other platforms,

    but not for us in Android • Testing business logic in Java is OK • Testing Android components NO • Too much time coding test cases that need a lot of boilerplate to work • Immature testing Android tools • But we are aware of recent launches • Android Studio code coverage • Robolectric 3.0
  18. 25.

    Quality Assurance • Team composed by engineers, not monkeys •

    Automated tests based on • Best alternative to Robot, Robotium, Calabash… • Continuous integration: every commit is tested • Executed in devices covering all densities, versions, screen sizes… • Regression/Certification tests performed on staging environment • Feature coverage better than code coverage
  19. 26.

    QA current scenario ! • >7000 compatible devices nowadays •

    Impossible to test everything • Solution: execute tests on thousands of cloud devices
  20. 27.

    Crash reporting • Goal: crash rate < 1% • Use

    dedicated tools • Use single API key: no matter the client, it’s the same app • But enrich exceptions to incorporate domain information • Client, environment, endpoints… • Use handled exceptions to get insights of errors that don’t crash the app
  21. 28.

    Crash reporting • No error is small: • If it

    affects one client, probably it will affect all • Review crashes generated on a daily basis to create bugs in your development project • Include them in your next sprint, never later • The last resort: • No clues about the context of an error? Talk to the user when possible
  22. 29.

    Analytics • Mandatory: know how your apps are used •

    Use a single API key even for different mobile platforms • But enrich hits with domain information to discover different app usages related to each client • Use screens, events, ecommerce… • Automatic periodic reports to UX team
  23. 31.

    bq + Nubico • Why Nubico? • How we do

    it? • Preinstallation in /data partition of bq devices to allow uninstall • Adaptation of Android AOSP boot wizard to include Nubico as an additional step • But we found several challenges…
  24. 32.

    Challenge 1: Update notifications • Apps preinstalled on /data •

    When not installed from Google Play, they are treated as unknown sources by Android • Update notifications lost until the user updates the app through Google Play • Solution: install the app in /system
  25. 33.

    Challenge 2: accessing native libs • When the app is

    installed on /system • Third party native libs not accessible when they are part of the APK • Solution: they have to be part of the system • Placed them on: • /system/lib • /vendor/lib • …
  26. 34.

    Challenge 3: uninstall app • Apps on /system cannot be

    uninstalled • Updates are installed on /data • But you cannot remove preinstalled version of the app • Unless you are root • Solution: accept the tradeoff
  27. 36.

    Main ideas • A white label model has to be

    profitable • Keys to achieve it: • Automation • Clear workflow definition • Quality in everything as daily mantra • Focus on the end user
  28. 37.

    Open Source • http://opensource.bq.com/ ! ! ! ! • And

    much more! • Web libs, 3D model, Arduino add-ons, robotics… Sorolla Autobus Droid2ino
  29. 40.

    Thank you! Daniel Gallego Vico - Android architect at bq

    ! daniel.gallego@bq.com ! @thanos_malkav