Plug-in project app description

The main work:

• Add app productFlavor, the same set of code can compile plugins and apps
• Use Activity to host LauncherFragment
• Troubleshoot package dependencies
• Permission application (account permission, cde permission)
• Handling problems caused by package name changes
• Add app upgrade function
• Related UI and experience design

Use Activity to carry entry Fragment

• Add entry Activity
• Set the LauncherFragment's view to the Activity's contentView (lower view level than the add fragment method & avoid the fragment recovery and reconstruction problem)
• Manually call the lifecycle function of LauncherFragment
• Implement the interface of the previous host Activity and provide key implementations

Troubleshoot package dependencies

The plug-in references some classes and functions of the launcher. The plug-in does not need to compile those classes into dex, but only needs to be compiled, so there are many jars that are provided.

As a standalone app, you need to compile those jars into dex.

Two problems were encountered:

1. jar class conflict
   1. After changing to compile mode, I encountered the problem of jar class conflict. The previous jar settings are unreasonable, and multiple jars will contain the same classes. If they are compiled in, there will be conflicts.
   2. Solution: Unzip the jar, delete the redundant classes, and repackage the jar (Java Jar package compression and decompression usage guide  https://www.cnblogs.com/javastack/p/8761248.html ).
2. The number of methods exceeds 64K (already obfuscation and de-resource redundancy)
   1. Before many jars were not compiled into dex, after changing to the compile method, the number of methods exceeded the standard
   2. Approach:
      1. Clean up code (delete old and unused functional code and related jars)
      2. Minus the dependence on fresco (in the case of plug-in, freso is not compiled into dex. fresco will introduce a lot of code and so in app, we do not have ImageLoader used by most functions, we can remove fresco. fresco will also introduce so , as a system app, so must be placed in system/lib. Now there are system applications that put so in system/lib. If we also use fresco, we must consider the version of so, which is expensive and prone to errors).
         
         

Permission application (account permission, cde permission)

Previously, the host had permission to apply for an account. After running as an app, you must apply for an account and other permissions by yourself, and apply for joining a whitelist.

Handling problems caused by package name changes

The host uniformly modifies the package name of the plug-in. In the plug-in, all the package names obtained by the standard api belong to the host. After changing to app, the package name obtained by these ap is the package name of the plugin itself.

The package name change involves: targeted broadcasting, the judgment of the package name by the advertising sdk, and the judgment of the package name by other sub-functions

app upgrade function

The upgrade of the plug-in is managed by the host in a unified manner. After the app, you need to consider the upgrade function yourself. There are two ways to upgrade:

1. Use the silent upgrade feature of the App Store
2. Add upgrade logic & UI yourself. By upgrading the sdk, the upgrade logic can be quickly completed.

Related UI and experience design

1. Logo
2. Startup map
3. Large background image & loading background image
4. In the case of multiple desktop plug-ins, the left button, the upper button, and the right button have corresponding functions, such as cutting the desktop and calling out the notification bar. In the case of an app, you can redefine these keys.