Android App Bundles - Overview
•Als PPTX, PDF herunterladen•
0 gefällt mir•196 views
Agenda of this Presentation is: What is Android App Bundle? AAB ≠ APK .aab file structure Advantages Dynamic Delivery Modular App Development Dynamic Feature Module Reduced application size Code Walkthrough and Limitations
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Android App Bundles - Overview
Ähnlich wie Android App Bundles - Overview (20)
Mehr von Syed Awais Mazhar Bukhari
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Android App Bundles - Overview
- 1. Android App Bundles Syed Awais Mazher May 07, 2021
- 2. - What is Android App Bundle? - AAB ≠ APK - .aab file structure - Advantages - Dynamic Delivery - Modular App Development - Dynamic Feature Module - Reduced application size - Code Walkthrough - Limitations 😣
- 4. .aab file structure assets/<name>#<key>_<value>/... Where <key> is one of { lang, tcf, opengl, vulkan } base/ manifest/ AndroidManifest.xml dex/ Classes.dex res/ drawable/.. values-fr/ assets/.. lib/ armeabi-v7a/..
- 5. Dynamic Delivery & modularization Split APK’s ● Base APK ● Configuration APKs ● Dynamic feature APKs
- 8. Split APKs
- 9. Objective Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
- 11. Reduced APK Size On average 35% size reduced
- 12. Code Walkthrough ● Google Play Core Library ● Play Feature Delivery ○ Install-time delivery ○ Conditional delivery ○ On-demand delivery ■ Best Practices ● Play Asset Delivery
- 13. Dependency wheel
- 14. Create a DFM
- 15. Create a DFM
- 16. Create a DFM
- 17. Configuration of install time module
- 18. Configuration of install time module
- 19. Configuration of install time module
- 20. Configuration of conditional module This allow you to set certain device configuration requirements for feature modules to be downloaded automatically during app install. If a device does not meet all the requirements you specify, the module is not downloaded at app install-time. . However, you can still request feature for installation later.
- 21. on-demand delivery - SplitInstallManagerFactory - SplitInstallRequest Builder - Monitoring request state - State updates - Pending, Requires_User_Confirmation, - Downloading, Downloaded, - Installing, Installed - Failed, Canceling, Canceled - Downloading progress - Manage Installed modules - Access Modules by enabling SplitCompat - Access Components using reflection - Local testing of DFM modules.
- 23. Asset Delivery Module will be installed in a same way as we did in on-demand module approach. After successful installation, we will get assets as following.
- 24. Local Testing - Build an app Bundle using Android Studio Plugin, (in wizard) - Use bundletool to generate a set of APKs - passing --local-testing flag - Device configurations .e.g. bundletool build-apks --bundle=/Users/joebirch/releases/sample.aab -- output=/Users/bell/releases/sample.apks --ks=/Users/bell/some_keystore.jks --ks-pass=file:/Users/bell/some_keystore.pwd --ks-key-alias=SomeAlias --key-pass=file:/Users/bell/some_key.pwd
- 25. Limitations Though App Bundle is compatible with Pro-Guard, but we are facing some issue with Dex-Guard. Still need to look into this vertical. If you have any experience with Dex-Guard, please get in touch for further analyses.
- 26. Q&A
- 27. If you joined late or I fast forwarded, feel free to get in touch at https://www.linkedin.com/in/awaismazharbukhari/ I Would love to hear your thoughts. References ● https://developer.android.com/guide/playcore ● Exploring the Android App Bundle
Hinweis der Redaktion
- Biggest problem now a days is large application size, which eventually takes a lot of space and slow down phones. Which results to more uninstallation. Android App Bundle is a new app publishing format in playstore, which help devs to optimize the size of apk. An APK is something that we can serve directly to our users devices, whereas on the other hand an App Bundle is a publishing format that cannot be installed onto a device on it’s own. Whilst they do have their similarities, the app bundle does contain some content which we will not find within our APKs. For example, the meta data files within the bundles are used by tooling to build the APKs that will be served to our users — these files are then not included in the APKs themselves. Whilst most of the content within the app bundle you will likely already be familiar with, let’s take a look at what a typical app bundle might contain: No more Multi APKs Previously, we used to build multiple APKs and manage different versions and the process was so messy and NOT Efficient.
- An APK is something that we can serve directly to our users devices, whereas on the other hand an App Bundle is a publishing format that cannot be installed onto a device on it’s own. Whilst they do have their similarities, the app bundle does contain some content which we will not find within our APKs. For example, the meta data files within the bundles are used by tooling to build the APKs that will be served to our users — these files are then not included in the APKs themselves. Whilst most of the content within the app bundle you will likely already be familiar with, let’s take a look at what a typical app bundle might contain:
- Almost similar to APK manifest.xml — Just like you will find in your APKs, there is a manifest file present per app bundle. However, unlike the APK these are not stored in a binary format — it is compiled into protocol buffer format which makes it easier for tooling to transform when required. res / assets / libs — All resources, assets and native libraries are stored the same way as in an APK. The only difference here is that any resource files will also be stored in the protocol buffer format as the last point. resources.pb — Similar to the resource.arac file which can be found inside of our current APK files, the resources.pb file is a resource table which states the resources and specifics for targeting which are present inside of our app. The .pb extension is due to the protocol buffer format which is used by tooling to transform the app bundle before it is converted into the binary format used within the APK. assets.pb — This is the equivalent of a resource table for application assets and will only be present if you are using assets in your application. native.pb — This is the equivalent of a resource table for native libraries and will only be present if you are using native libraries in your application.
- Base APK: This APK contains code and resources that all other split APKs can access and provides the basic functionality for your app. This is the first APK that’s installed when a user downloads your app. Configuration APKs: Each of these APKs include native libraries and resources for a specific screen density, CPU architecture, or language. That way, when a device downloads a base or dynamic feature APK, it downloads only the libraries and resources it needs. For most app projects, you don’t need to refactor your app to support configuration APKs, Google Play generates them for you from the code and resources you include in your app bundle. Dynamic feature APKs: Each of these APKs contain code and resources that are not required when your app is first installed, but may be downloaded and installed later.
- bundle { language { enableSplit = false } density { enableSplit = true } abi { enableSplit = true } }
- What is Play Core? The Play Core Library is your app’s runtime interface with the Google Play Store. Some of the things you can do with Play Core include the following: Download additional language resources Manage delivery of feature modules Manage delivery of asset packs Trigger in-app updates Request in-app reviews
- In the standard project structure that uses libraries, the base com.android.application module depends on com.android.library modules, which means you can use any classes defined in the library from the base module freely. With DFMs however, the base com.android.application is a dependency of com.android.dynamic-feature modules, which means you can use any classes defined in the base module and its libraries in the DFM, but you can’t reference any code defined in the DFM from the base application at compile time. Once the APKs produced by the DFM are installed with your application (regardless of the delivery mechanism: install-time, on-demand or conditional), their code is available to the ClassLoader at runtime.
- Conditional delivery options are not supported for instant-enabled feature modules. <dist:country dist:code="CN"/> <dist:min/max-sdk dist:value="21"/>
- Access base code from a module Code that is inside your base module can be used directly by other modules. You don't need to do anything special; just import and use the classes you need. Access module code from another module An object or class inside a module cannot be statically accessed from another module directly, but it can be accessed indirectly, using reflection. You should be wary of how often this happens, due to the performance costs of reflection. For complex use cases, go for DI i.e. Dagger 2 to guarantee a single reflection call per application lifetime. To simplify the interactions with the object after instantiation, it is recommended to define an interface in the base module and its implementation in the feature module. For instance:
- Perform download and install in the background Free up device storage when a module is no longer needed Advanced tips Anticipate a user's need for a feature in the current session/ ahead of installation based on hardware, country etc.
- Access base code from a module Code that is inside your base module can be used directly by other modules. You don't need to do anything special; just import and use the classes you need. Access module code from another module An object or class inside a module cannot be statically accessed from another module directly, but it can be accessed indirectly, using reflection. You should be wary of how often this happens, due to the performance costs of reflection. For complex use cases, go for DI i.e. Dagger 2 to guarantee a single reflection call per application lifetime. To simplify the interactions with the object after instantiation, it is recommended to define an interface in the base module and its implementation in the feature module. For instance: