When we talk about plugins and modular applications, we primarily mean ordinary user software. However, modular design can be just as useful when developing rootkits and backdoors. Updating such software using conventional means is too clumsy and not always possible, but loading a module with new functionality over the network without being noticed is welcome. And if you move key functionality into modules and delete them immediately after loading, you can seriously ruin the life of the reverser.

Instead of introducing

In classic Java there is a class called java.lang.ClassLoader. Its task is to load the bytecode of the specified class (a file with the .class extension) into the virtual machine during application execution. You can then create an object of this class and call its methods using reflection. This is a method of dynamically loading code that can be used to write applications with extensible functionality, or, simply put, support for plugins.

Android does not have a Java virtual machine and there is no ClassLoader class, but there is its analog DexClassLoader, which performs exactly the same function, but in relation to Dalvik bytecode (and .dex files instead of .class files, respectively). And, unlike desktop Java, where it’s easier to put the required jar file in the CLASSPATH and not bother with dynamic loading, in Android this approach really gives a lot of advantages, the main one of which is that the application’s functionality can be expanded and updated unnoticed by the user and without asking him anything. At any time, your application can download a file with a class from the server, load it, and then delete the file.

In addition, classes can be stored directly in the APK package and downloaded when the application starts. The benefit here is that the code of the loaded classes will be separated from the code of the application itself and will be located in the wrong APK; tools like apktool, which reversers love to use, will simply not be seen. On the other hand, this is rather foolproof, since a normal reverser will quickly figure out what’s what.

Be that as it may, dynamic class loading is a very useful thing when writing not entirely “white” applications, so any security specialist should know how this mechanism works and how it is used in Trojans.

The simplest example

// Path to the jar archive with our class String modFile = "/sdcard/myapp/module.jar"; // Path to the private application directory String appDir = getApplicationInfo().dataDir; // Load the file from disk DexClassLoader classLoader = new DexClassLoader(modFile, appDir, null, getClass().getClassLoader()); // Load the class, create an object and try to call the run() method using reflection try ( Class c = classLoader.loadClass("com.example.modules.simple.Module"); Method m = c.getMethod("run", null); m.invoke(c.newInstance(), null); ) catch (Exception e) ( e.printStackTrace(); )

In general, everything is simple here: the code loads the jar archive /sdcard/myapp/module.jar with our class, loads the class com.example.modules.simple.Module from it, creates an object and calls the run() method. Pay attention to three points:

• DexClassLoader can load both “just” .dex files and jar archives, the latter are preferable due to compression and the ability to use a digital signature;
• the second argument to the DexClassLoader constructor is the directory it uses to store the optimized bytecode (odex), for simplicity we specify the private directory of the application itself;
• The loadClass method must always include the class address along with the package name as an argument to the loadClass method.

To test this code for functionality, let’s create a simple module:

Package com.example.modules.simple.Module; import android.util.Log; public class Module ( public void run() ( Log.d("Module", "I am alive!!!"); ) )

Don’t rush to create a new project in Android Studio; you can write this code in Notepad and compile it into a jar archive directly from the command line:

Javac -classpath /path/to/SDK/platforms/android-23/android.jar Module.java /path/to/SDK/build-tools/23.0.3/dx --dex --output=module.jar Module. class

Make sure that the platforms/android-23 and build-tools/23.0.3 directories exist, in your case their names may be different.

If everything goes smoothly, you will get a module.jar file as output. All that remains is to add the bootloader code to the application, put module.jar on the memory card, build and run the application.

Down with reflection

Reflection is a good thing, but in this case it only gets in the way. It’s not difficult to call one method without arguments with its help, however, if we want our application to have a rich API of modules with many methods that take several parameters, we need to come up with something more convenient. For example, use a predefined interface that each module will implement.

Applying this approach to the example above, we end up with the following three files:

1. ModuleInterface.java file with API description: package com.example.modules; public interface ModuleInterface ( public void run(); )
2. Module.java file with the implementation of our module: package com.example.modules.simple.Module; import android.util.Log; public class Module implements ModuleInterface ( public void run() ( Log.d("Module", "I am alive!!!"); ) )
3. New module loader (place it in your application): String modFile = "/sdcard/myapp/module.jar"; String appDir = getApplicationInfo().dataDir; DexClassLoader classLoader = new DexClassLoader(modFile, appDir, null, getClass().getClassLoader()); // Load the class and create an object with the interface ModuleInterface ModuleInterface module; try (Classclass = classLoader.loadClass("com.example.modules.simple.Module"); module = (ModuleInterface) class.newInstance(); ) catch (Exception e) ( e.printStackTrace(); ) module.run()

This is all. Now we can work with the module as with a regular object. Moreover, the system itself will reject modules (classes) that are incompatible with the interface at the loading stage, so we don’t have to ask ourselves whether the module contains the method we need.

When there are many modules

We've sorted out one module, but what if there are many of them? How to keep track of these modules and not get lost among them? It's actually simple - you can use a hashmap for this. Let's change the bootloader again:

Continuation is available only to members

Option 1. Join the “site” community to read all materials on the site

Membership in the community within the specified period will give you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score rating!

I have a project created with Gradle in Android Studio v 0.3.2. My project has dependencies on two other modules (the library). The project structure is well defined using build.gradle files. The problem is... when I run a project on an Android device, I install 3 on my device. One of them is the main project (the only correct one), and the other two are imported modules (I don't want to install these two). How can I achieve this? Or what am I doing wrong?

Project structure:

• MyLibModule
• MainProject
• MainProject->libraries-> MyOtherModule

Where MyLibModule is on the same path as the main project because I also need this module in another project.

Just to be clear: all assembly project in order, all dependencies are ok, but why am I getting 3 APKs on my device?

After a whole day of struggling with this problem, I found the reason for this strange behavior. The problem was in the manifestation of the library module. Before I switched to Android studio I was using Eclipse. And I had testActivity declared in the library project manifest. Removing all manifest test actions from my library modules solved the problem. Android Studio now installs only the MainProject APK.

Some code: MyLibModule manifest:

Changed to:

…. And the same for MyOtherModule.

NOTE. Empty node applications must remain in the manifest to avoid build errors.

Remove intent filter from running your library

Changed to

This is because your libraries are defined in your build.gradle files as applications, not libraries. Look at this line:

Apply plugin: "android"

And replace it with:

Apply plugin: "android-library"

You may have to make other changes to the build file, since not everything that is application specific can be specified in the library build file. See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-projects for more information.

At the recent Google I/O 2018, among many innovations, also announced the addition of a new application format.

This format is called Android App Bundle and represents an improved way to build your application. With its help, you can easily optimize the size of the application without the need to make any changes to the code. The Android App Bundle includes all the compiled code and resources, then filtering out what is not needed by a specific device.

Important! At the moment, the Android App Bundle only works in the preview version of Android Studio. Latest version Android Studio 3.2 Canary available .

Android App Bundle Format

Android App Bundle is a file (with extension .aab), which is uploaded to Google. Each bundle includes compiled code and resources for all application modules and supported device configurations.

Simply put, bundles are signed ZIP files that organize application code and resources into modules.

From these modules, Google Play generates various APKs that are provided to users, such as: base APKs, dynamic feature APKs, configuration APKs, and (for devices that do not support split APKs) multi-APKs. The directories colored blue represent the code and resources that Google Play uses to create the configuration APK for each module.

Note: a bundle must be created for each unique application or applicationID. That is, if you use multiple product flavors in your application to create different APKs, and each of these branches uses a unique applicationID, then you will need to create a separate bundle for each branch.

The code and resources for each module are organized similarly to standard APKs, which makes sense since each of these modules can be generated as a separate APK. Below you can see a more detailed description of some of the files and directories of the Android App Bundle:

• base/, feature1/, feature2/. Each of these directories represents an application module. The base application module is always contained in the base bundle directory. Directories with additional features, each of which is assigned a special name, are located separately.
• files Protocol Buffer (.pb). These files contain metadata that helps describe the contents of the bundle in app stores. For example, BundleConfig.pb, located in the root directory of the bundle, provides information about the bundle itself, for example, what version build tools used for assembly. Other files such as recourse.pb And native.pb, describe how certain code and resources should be used for different device configurations. Google Play uses this information to generate an APK optimized for the user's device.
• manifest/. Unlike APKs, bundles store the AndroidManifest.xml file of each module in a separate directory.
• dex/. Unlike APKs, bundles store the DEX files of each module in a separate directory.
• root/. This directory stores files that are later moved to the directory root any APK that includes a module that contains this directory. For example, directory base/root/ a bundle can include Java resources that are loaded by the application using Class.getResources(). These files are later moved to the root APK directory of the application and each multi-APK that Google Play generates. The paths in this directory are also preserved, that is, subdirectories are also moved along with root.
  Note: if the contents of this directory conflict with other files and directories in the root of the APK, the Play Console will reject the download of the bundle. For example, you won't be able to include the root/lib/ directory because it will conflict with the lib directory already in the APK.
• res/, lib/, assets/. These directories are identical to those used in the standard APK. When you download an application, Google Play checks only those files in these directories and packages that match the configuration of the target device.

Building an App Bundle using Android Studio

Creating a bundle using Android Studio is very similar to creating an APK. To assemble, just select from the menu Build - Build Bundle(s)/APK(s) > Build Bundle(s) and the IDE will create a bundle for the selected build option and place it in the directory //build/outputs/bundle/.

If a bundle is created for the debug version of the application, Android Studio will automatically sign the bundle using the debug signing key. To upload a bundle to Google Play, it must be signed.

Once Android Studio has finished creating the signed bundle, it can be opened and analyzed. Bundle analysis allows you to check the contents and works similarly APK Analyzer.

To create an App Bundle, the IDE uses the same open source tool called bundletool, which Google Play uses to subsequently convert the bundle into signed APKs.

Before you upload a bundle to the Google Play console, you need to sign it. To create a signed App Bundle, you need to follow these steps:

Once Android Studio has completed creating the signed bundle, it can be found and analyzed by selecting the appropriate option in the toast notification. If you have chosen to export a signing key, you can quickly access it by clicking the down arrow in the lower right corner of the toast to expand it, and then selecting Show Exported Key File.

Uploading an App Bundle to the Google Play Console

Once the bundle is created, it can be uploaded to Google Play for review, testing, or publishing the application. Before starting work, the following conditions must be met:

1. Register for the program Google Play App Signing.
2. If the application includes dynamic feature modules, then it can be downloaded and tested through the internal test track of the Google Play console. However, to publish your app, you must accept the Dynamic Feature program, which is currently in beta.
3. Google Play supports app downloads no larger than 100 MB.

APK Analysis Using Explorer

When the bundle is downloaded, Google Play automatically generates split APKs and multi-APKs for all device configurations supported by the application. In the Play Console, you can use the App Bundle Explorer to view all APK variants generated by Google Play; data analysis such as supported devices and APK size savings; downloading the created APK for testing.

Application update

After uploading the application to the Play Console, to update the application you just need to upgrade the version code and create and upload a new bundle. Google Play will then generate updated APKs with the new version code and provide them as needed.

Conclusion

Using the Android App Bundle provides great benefits for optimizing APK applications. Using this method, we updated one of our applications, “Wi-Fi Network Password Manager”, replacing its standard APK with an App Bundle. Thus, the size of APK files has decreased by a whole megabyte, which is a very good result.

In addition, Google is currently testing an addition to the App Bundle, Dynamic feature modules, with which you can split the base APK into parts that will be downloaded if necessary, so far this technology is in beta.

Perhaps the only drawback of bundles at the moment is the need to use the preview version of Android Studio, but this problem is temporary.

Android Studio: Module will not show up in "Edit Configuration" (13)

Sometimes errors exist in the Android manifest due to the fact that there is a cross like image through the run/debug configuration, so try to view if the Android manifest has any errors in one case.

I have imported a project into Android Studio with several subprojects.

I want to start a subproject.

I have successfully made this subprojects build.gradle as a module.

To run it, I went to Run > Edit Configurations > Android Application.

Problem. When I try to select a module, none of them appear in the dropdown list.

Why is this?

EDIT: It appears as a module under Groovy, but not in the Android app. How can I get it in Android app?

goto Android >> Gradle Scripts >> Build Gradle (Module: app)

make sure the first line of this file is like this.

Apply plugin: "com.android.library"

For me it was fixed by simply restarting Android Studio.. Just like the good old days of Eclipse

For my case, newbie I roared my project, not sure how, but it won't work anymore and complained about the manifest, R, everything. I realized that some are like in my settings. Gradle doesn't include ":app" once I added that I was on my way again.

Finally, I figured out why the module is not showing up when I add the configuration for AndroidTests for the com.android.library module.

If you build.gradle your library module in the app's build.gradle like this:

Compile project(":yourlibrary")

Because the default library module is compiled with release mode, you can't run Android Tests on it, so it won't show up in the list of modules. I fixed it with the following modification:

Add the following configuration to your library module's build.gradle:

PublishNonDefault true

build.gradle changes the following, you can debug compilation of your library by editing the build.gradle of your application module, for example:

Compile project(":yourlibrary") + debugCompile project(path: ":yourlibrary", configuration: "debug") + releaseCompile project(path: ":yourlibrary", configuration: "release")

Then sync it and you will find it in the list.

It looks like different solutions work differently for people as I just close the project and importing it again solved the problem.

I had a similar problem, when I selected my project's parent directory, I allowed Close Project -> Remove Project from Android Studio -> Import Project by selecting the file right build.gradle .

Make sure you select the correct build.gradle file during import.

Make sure your build.gradle

Apply plugin: "com.android.application"

Once you have changed, sync again.

This happens mainly when copying a library project and creating it. The solution would be to add

Apply plugin: "com.android.application"

in the build.gradle file, instead

Apply plugin: "com.android.library"

Then do gradient sync

orderEntry type = "library" exported = "" name = "appcompat-v7-19.1.0" level = "project" />

I fixed it by adding edges to module settings. They went missing. > open Module Settings > Borders > Add faces(+ sign at the top)> Android. After adding the faces you will have modules.

UPDATE:

For the latest version of gradient Facets have been removed, you can now add modules directly. right click on the project > open module settings > Add module(at the top of the “+” sign)> Phone and Tablet app(you can now create a new module and configure it).

add your moudle to your applications. iml file like: orderEntry type = "module" module-name = "yourmoudlename" exported = ""

Modules provide a container for your app"s source code, resource files, and app level settings, such as the module-level build file and Android manifest file. Each module can be independently built, tested, and debugged.

Android Studio uses modules to make it easy to add new devices to your project. By following a few simple steps in Android Studio, you can create a module to contain code that"s specific to a device type, such as Wear OS or Android TV. Android Studio automatically creates module directories, such as source and resource directories, and a default build.gradle file appropriate for the device type. Also, Android Studio creates device modules with recommended build configurations, such as using the Leanback library for Android TV modules.

This page describes how to add a new module for a specific device.

Android Studio also makes it easy to add a library or Google Cloud module to your project. For details on creating a library module, see Create a Library Module .

Create a new module

To add a new module to your project for a new device, proceed as follows:

1. Click File > New > New Module.
2. In the Create New Module window that appears, Android Studio offers the following device modules:
   • Phone & Tablet Module
   • Wear OS Module
   • Android TV Module
   • Glass Module
   Select the module for the device you want, and then click Next.
3. In the Configure your new module form, enter the following details:
   • Application Name: This name is used as the title of your app launcher icon for the new module.
   • Module Name: This text is used as the name of the folder where your source code and resource files are visible.
   • Package Name: This is the Java namespace for the code in your module. It is added as the package attribute in the module"s Android manifest file.
   • Minimum SDK: This setting indicates the lowest version of the Android platform that the app module supports. This value sets the minSdkVersion attribute in the build.gradle file, which you can edit later.

   Then click Next.

4. Depending on which device module you selected, the following page displays a selection of appropriate code templates you can select to use as your main activity. Click an activity template with which you want to start, and then click Next. If you don"t need an activity, click Add No Activity, click Finish, and then you're done.
5. If you chose an activity template, enter the settings for your activity on the Customize the Activity page. Most templates ask for an Activity Name, Layout Name, Title, and Source Language, but each template has activity-specific settings. Click Finish. When you create an app module with an activity template, you can immediately run and test the module on your device.

Android Studio creates all the necessary files for the new module and syncs the project with the new module gradle files. Adding a module for a new device also adds any required dependencies for the target device to the module"s build file.

Once the Gradle project sync completes, the new module appears in the Project window on the left. If you don"t see the new module folder, make sure the window is displaying the Android view .

Import a module

To import an existing module into your project, proceed as follows:

1. Click File > New > Import Module.
2. In the Source directory box, type or select the directory of the module(s) that you want to import:
   • If you are importing one module, indicate its root directory.
   • If you are importing multiple modules from a project, indicate the project folder. For each module inside the folder, a box appears and indicates the Source location and Module name. Make sure Import box is checked for each module that you want to import.
   If your module(s) have other dependencies, they will be listed to import under Additional required modules.
3. Type your desired module name(s) in the Module name field(s).
4. Click Finish.

Next steps

Once you"ve added a new module, you can modify the module code and resources, configure module build settings, and build the module. You can also run and debug the module like any other app.

• To learn about build settings for a module, see The Module-level Build File .
• To build and run a specific module, see Select and build a different module .

You"ll also want to add code and resources to properly support the new device. For more information about how to develop app modules for different device types, see the corresponding documentation:

• For Wear OS modules:
• For Android TV modules:
• For Glass modules: GDK Quick Start

As you develop your new module, you might create independent device code that is already duplicated in a different app module. Instead of maintaining duplicate code, consider moving the shared code to a library module and adding the library as a dependency to your app modules. For more information on creating a library module and adding it as a dependency, see