Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. 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. bq creates HW… and SW??

  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
  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…
  5. Our use case • One project supporting 3 business models

    • eBooks ecosystem • Pre-requisites: • Android minSDK 15 • Smartphone & Tablet • i18n
  6. Nubico vs Fnac vs eBiblio Premium catalogue Store purchase Library

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

    users < 1% Crash rate 5 languages National & International
  8. Automation to support n ∞ clients →

  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
  10. Development workflow white label context compilation & packaging APK1 APK2

    APKn Signing Repository
  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
  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
  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' } }
  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
  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
  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
  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
  18. Sorolla in action! $ python sorolla_example.py source_res_dir dest_res_dir FF0000

  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
  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
  21. Future development workflow white label context compilation & packaging APKwhiteLabel

    APK adaptation APKn Repository APK2 APK1
  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
  23. Software Quality to achieve crash rate < 1%

  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
  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
  26. QA current scenario ! • >7000 compatible devices nowadays •

    Impossible to test everything • Solution: execute tests on thousands of cloud devices
  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
  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
  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
  30. Apps preinstallation to reach thousands of users

  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…
  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
  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 • …
  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
  35. Conclusions

  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
  37. Open Source • http://opensource.bq.com/ ! ! ! ! • And

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

  39. Apps assemble! ?

  40. Thank you! Daniel Gallego Vico - Android architect at bq

    ! daniel.gallego@bq.com ! @thanos_malkav