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.

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