droidcon spain 2105 - one app to rule them all: methodologies, tools & tricks to achieve an...
TRANSCRIPT
One app to rule them all: Methodologies, Tools & Tricks to
achieve an effective white label model
Daniel Gallego Vico - Android architect at bq !
@thanos_malkav
bq creates HW… and SW??
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
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…
Our use case
• One project supporting 3 business models
• eBooks ecosystem
• Pre-requisites:
• Android minSDK 15
• Smartphone & Tablet
• i18n
Nubico vs Fnac vs eBiblio
Premium catalogue
Store purchase
Library loan
Achievements
33 clientsApps on Google Play
>13KDaily active users
< 1%Crash rate
5 languagesNational & International
Automation to support n ∞ clients→
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
Development workflowwhite label context compilation & packaging
APK1 APK2 APKn
Signing
Repository
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
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
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' } }
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
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
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
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
Sorolla in action!
$ python sorolla_example.py source_res_dir dest_res_dir FF0000
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
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
Future development workflowwhite label context compilation & packaging
APKwhiteLabel
APK adaptation
APKn
Repository
APK2APK1
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
Software Quality to achieve crash rate < 1%
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
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
QA current scenario
!
• >7000 compatible devices nowadays
• Impossible to test everything
• Solution: execute tests on thousands of cloud devices
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
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
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
Apps preinstallation to reach thousands of users
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…
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
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
• …
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
Conclusions
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
Open Source
• http://opensource.bq.com/
!
!
!
!
• And much more!
• Web libs, 3D model, Arduino add-ons, robotics…
SorollaAutobus Droid2ino
Collaborate!
Apps assemble!
?
