Eclipse Jersey 2.28 to 2.33 and Eclipse Jersey 3.0.0 to 3.0.1 contains a local information disclosure vulnerability. This is due to the use of the File.createTempFile which creates a file inside of the system temporary directory with the permissions: -rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system. As such, if the contents written is security sensitive, it can be disclosed to other local users.

**Package**

maven org.glassfish.jersey.core:jersey-common (Maven)

**Affected versions**

<=2.33, <=3.0.1

**Patched versions**

2.34, 3.0.2

**Impact**

Eclipse Jersey 2.28 - 2.33 and Eclipse Jersey 3.0.0 - 3.0.1 contains a local information disclosure vulnerability. This is due to the use of the File.createTempFile which creates a file inside of the system temporary directory with the permissions: -rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system. As such, if the contents written is security sensitive, it can be disclosed to other local users.

**Workaround**

This issue can be mitigated by manually setting the java.io.tmpdir system property when launching the JVM.

**Patches**

Jersey 2.34 and 3.0.2 forward sets the correct permissions on the temporary file created by Jersey.

**References**

*   #4712
*   CWE-378: Creation of Temporary File With Insecure Permissions
*   CWE-379: Creation of Temporary File in Directory with Insecure Permissions

**Similar Vulnerabilities**

Similar, but not the same:

*   JUnit 4 - GHSA-269g-pwp5-87pp
*   Google Guava - google/guava#4011
*   Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
*   JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
*   Eclipse Jetty - GHSA-g3wg-6mcf-8jj6

Original Disclosure:

> Hello Jersey Security Team,
> 
> Utilizing a custom CodeQL query written as a part of the GitHub Security Lab Bug Bounty program, I've unearthed a local temporary file information disclosure vulnerability.
> 
> You can see the custom CodeQL query utilized here:  
> https://lgtm.com/query/8831016213790320486/
> 
> This particular vulnerability exists because on unix-like systems (not including modern versions of MacOS) the system temporary directory is shared between all users. As such, failure to correctly set file permissions and/or verify exclusive creation of directories can lead to either local information disclosure, or local file hijacking by another user.
> 
> This vulnerability impacts the following locations in this project's source:
> 
> *   final File file = Utils.createTempFile();
>     
>     final OutputStream stream = new BufferedOutputStream(new FileOutputStream(file));
>     
>     try {
>     
>     writeTo(entityStream, stream);
>     
>     } finally {
>     
>     stream.close();
>     
>     }
>     
>     return file;
>     
> *   // Create a temporary file.
>     
>     final File file = Utils.createTempFile();
>     
>     // Move the part (represented either via stream or file) to the specific temporary file.
>     
>     entity.moveTo(file);
>     
>     return file;
>     
> 
> This vulnerability exists because of the vulnerability in the Utils.createTempFile:
> 
> /\*\*
> 
> \* Create an empty file in the default temporary-file directory.
> 
> \*
> 
> \* @return An abstract pathname denoting a newly-created empty file.
> 
> \* @throws IOException if a file could not be created.
> 
> \*/
> 
> public static File createTempFile() throws IOException {
> 
> final File file = File.createTempFile("rep", "tmp");
> 
> // Make sure the file is deleted when JVM is shutdown at last.
> 
> file.deleteOnExit();
> 
> return file;
> 
> }
> 
> This is because File.createTempFile creates a file inside of the system temporary directory with the permissions: -rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system.
> 
> If there is sensitive information written to these files, it is disclosed to other local users on this system.
> 
> The fix for this vulnerability is to use the Files API (instead of the File API) to create temporary files/directories as this new API correctly sets the posix file permissions.

CVE-2021-28168

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.

**Impact**

When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.

The CVSSv3.1 score of this vulnerability is calculated to be a 6.2/10

**Vulnerability Details**

On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.

The method File.createTempFile on unix-like systems creates a random file, but, by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.

This is the case in netty's AbstractDiskHttpData is vulnerable.

private File tempFile() throws IOException {

String newpostfix;

String diskFilename = getDiskFilename();

if (diskFilename != null) {

newpostfix = '\_' + diskFilename;

} else {

newpostfix = getPostfix();

}

File tmpFile;

if (getBaseDirectory() == null) {

// create a temporary file

tmpFile = File.createTempFile(getPrefix(), newpostfix);

} else {

tmpFile = File.createTempFile(getPrefix(), newpostfix, new File(

getBaseDirectory()));

}

if (deleteOnExit()) {

// See https://github.com/netty/netty/issues/10351

DeleteFileOnExitHook.add(tmpFile.getPath());

}

return tmpFile;

}

AbstractDiskHttpData is used as a part of the DefaultHttpDataFactory class which is used by HttpPostRequestDecoder / HttpPostMultiPartRequestDecoder.

You may be affected by this vulnerability your project contains the following code patterns:

channelPipeline.addLast(new HttpPostRequestDecoder(...));

channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...));

**Patches**

This has been patched in version 4.1.59.Final.

**Workarounds**

Specify your own java.io.tmpdir when you start the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.

**References**

*   CWE-378: Creation of Temporary File With Insecure Permissions
*   CWE-379: Creation of Temporary File in Directory with Insecure Permissions

**Similar Vulnerabilities**

Similar, but not the same.

*   JUnit 4 - GHSA-269g-pwp5-87pp
*   Google Guava - google/guava#4011
*   Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
*   JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in netty
*   Email us here

**Original Report**

> Hi Netty Security Team,
> 
> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project:  
> https://lgtm.com/query/7723301787255288599/
> 
> Netty contains three local information disclosure vulnerabilities, so far as I can tell.
> 
> One is here, where the private key for the certificate is written to a temporary file.
> 
> // Encode the private key into a file.
> 
> ByteBuf wrappedBuf = Unpooled.wrappedBuffer(key.getEncoded());
> 
> ByteBuf encodedBuf;
> 
> final String keyText;
> 
> try {
> 
> encodedBuf = Base64.encode(wrappedBuf, true);
> 
> try {
> 
> keyText = "-----BEGIN PRIVATE KEY-----\\n" +
> 
> encodedBuf.toString(CharsetUtil.US\_ASCII) +
> 
> "\\n-----END PRIVATE KEY-----\\n";
> 
> } finally {
> 
> encodedBuf.release();
> 
> }
> 
> } finally {
> 
> wrappedBuf.release();
> 
> }
> 
> File keyFile = File.createTempFile("keyutil\_" + fqdn + '\_', ".key");
> 
> keyFile.deleteOnExit();
> 
> OutputStream keyOut = new FileOutputStream(keyFile);
> 
> try {
> 
> keyOut.write(keyText.getBytes(CharsetUtil.US\_ASCII));
> 
> keyOut.close();
> 
> keyOut = null;
> 
> } finally {
> 
> if (keyOut != null) {
> 
> safeClose(keyFile, keyOut);
> 
> safeDelete(keyFile);
> 
> }
> 
> }
> 
> One is here, where the certificate is written to a temporary file.
> 
> wrappedBuf = Unpooled.wrappedBuffer(cert.getEncoded());
> 
> final String certText;
> 
> try {
> 
> encodedBuf = Base64.encode(wrappedBuf, true);
> 
> try {
> 
> // Encode the certificate into a CRT file.
> 
> certText = "-----BEGIN CERTIFICATE-----\\n" +
> 
> encodedBuf.toString(CharsetUtil.US\_ASCII) +
> 
> "\\n-----END CERTIFICATE-----\\n";
> 
> } finally {
> 
> encodedBuf.release();
> 
> }
> 
> } finally {
> 
> wrappedBuf.release();
> 
> }
> 
> File certFile = File.createTempFile("keyutil\_" + fqdn + '\_', ".crt");
> 
> certFile.deleteOnExit();
> 
> OutputStream certOut = new FileOutputStream(certFile);
> 
> try {
> 
> certOut.write(certText.getBytes(CharsetUtil.US\_ASCII));
> 
> certOut.close();
> 
> certOut = null;
> 
> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable.
> 
> tmpFile = File.createTempFile(getPrefix(), newpostfix);
> 
> All of these vulnerabilities exist because File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: -rw-r--r--, thus, any other local user on that system can read the contents of that file.
> 
> Impacted OS:
> 
> *   Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows.
> 
> Mitigation.
> 
> Moving to the Files API instead will fix this vulnerability.  
> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...-
> 
> This API will explicitly set the posix file permissions to something safe, by default.
> 
> I recently disclosed a similar vulnerability in JUnit 4:  
> GHSA-269g-pwp5-87pp
> 
> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case.  
> GHSA-g3wg-6mcf-8jj6
> 
> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice.  
> https://github.com/netty/netty/security/advisories
> 
> This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.
> 
> Cheers,  
> Jonathan Leitschuh

CVE-2021-21290

Apache Groovy provides extension methods to aid with creating temporary directories. Prior to this fix, Groovy's implementation of those extension methods was using a now superseded Java JDK method call that is potentially not secure on some operating systems in some contexts. Users not using the extension methods mentioned in the advisory are not affected, but may wish to read the advisory for further details. Versions Affected: 2.0 to 2.4.20, 2.5.0 to 2.5.13, 3.0.0 to 3.0.6, and 4.0.0-alpha-1. Fixed in versions 2.4.21, 2.5.14, 3.0.7, 4.0.0-alpha-2.

**Security updates**

Here you can find information about security patches or updates released for Apache Groovy. Note that unless specified otherwise, no binary or source patches are available. To obtain a security fix, you need to upgrade to the latest maintained version of Apache Groovy.

Releases prior to 2.4.4 were not released under Apache so no official patches for security updates are available for older versions.

**CVE-2015-3253 Apache Groovy Information Disclosure**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   Unsupported Codehaus versions of Groovy from 1.7.0 to 2.4.3
    
*   Fixed in version 2.4.4
    

Impact:

Remote execution of untrusted code, DoS

Description:

When an application has Groovy on the classpath and uses standard Java serialization mechanisms to communicate between servers, or to store local data, it is possible for an attacker to bake a special serialized object that will execute code directly when deserialized. All applications which rely on serialization and do not isolate the code which deserializes objects are subject to this vulnerability.

Mitigation:

Apache Groovy 2.4.4 is the first supported release under the Apache Software Foundation. It is strongly recommended that all users using serialization upgrade to this version. If you cannot upgrade or rely on an older, unsupported version of Groovy, you can apply the following patch on the MethodClosure class (src/main/org/codehaus/groovy/runtime/MethodClosure.java):

     public class MethodClosure extends Closure {
    +    private Object readResolve() {
    +        throw new UnsupportedOperationException();
    +    }

Alternatively, you should make sure to use a custom security policy file (using the standard Java security manager) or make sure that you do not rely on serialization to communicate remotely.

Credit:

This vulnerability was discovered by:

*   cpnrodzc7 working with HP’s Zero Day Initiative
    

References:

*   CVE-2015-3253: Remote execution of untrusted code
    
*   http://groovy-lang.org/security.html
    

**CVE-2016-6814 Apache Groovy Information Disclosure**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   Unsupported Codehaus versions of Groovy from 1.7.0 to 2.4.3
    
*   Apache Groovy 2.4.4 to 2.4.7
    
*   Fixed in version 2.4.8
    

Impact:

Remote execution of untrusted code, DoS

Description:

When an application with Groovy on classpath uses standard Java serialization mechanisms, e.g. to communicate between servers or to store local data, it is possible for an attacker to bake a special serialized object that will execute code directly when deserialized. All applications which rely on serialization and do not isolate the code which deserializes objects are subject to this vulnerability. This is similar to CVE-2015-3253 but this exploit involves extra wrapping of objects and catching of exceptions which are now safe guarded against.

Mitigation:

Users of Groovy relying on (de)serialization with the affected versions should apply one of the following mitigations:

*   Isolate the code doing the (de)serialization
    
*   Upgrade to Apache Groovy 2.4.8 or later
    
*   Users of older versions of Groovy can apply the following patch to the MethodClosure class (src/main/org/codehaus/groovy/runtime/MethodClosure.java):
    

    public class MethodClosure extends Closure {
    +    private void readObject(java.io.ObjectInputStream stream) throws
    IOException, ClassNotFoundException {
    +        if (ALLOW_RESOLVE) {
    +            stream.defaultReadObject();
    +        }
    +        throw new UnsupportedOperationException();
    +    }

Credit:

This vulnerability was discovered by:

*   Sam Thomas of Pentest Limited working with Trend Micro’s Zero Day Initiative
    

History:

*   2016-09-20 Original advisory
    
*   2017-01-12 Updated information on affected versions
    

References:

*   CVE-2016-6814: Remote execution of untrusted code
    
*   http://groovy-lang.org/security.html
    

**CVE-2020-17521 Apache Groovy Information Disclosure**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

Unsupported Codehaus versions of Groovy from 2.0 to 2.4.4. Apache Groovy versions 2.4.4 to 2.4.20, 2.5.0 to 2.5.13, 3.0.0 to 3.0.6, and 4.0.0-alpha-1.

Fixed in versions 2.4.21, 2.5.14, 3.0.7, 4.0.0-alpha-2

Impact:

This vulnerability potentially impacts Unix-like systems, and very old versions of Mac OSX and Windows. On such OS versions, Groovy may create temporary directories within the OS temporary directory which is shared between all users on affected systems. Groovy will create such directories for internal use when producing Java Stubs (very low impact) or on behalf of user code via two extension methods\[4,5\] for creating temporary directories. If Groovy user code uses either of these extension methods, and stores executable code in the resulting temporary directory, then the risk is high, since this can lead to local privilege escalation. If such Groovy code is making use of the temporary directory to store sensitive information, then the risk is medium, since such information could be exposed or modified.

When analyzing the impact of this vulnerability, here are the important questions to ask:

Is the Groovy code running on a machine with an impacted operating system? Do other users have access to the machine running the Groovy code? Does the Groovy code create temporary directories using Groovy’s createTempDir extension methods\[4,5\]?

If you answer no to any of these questions, you are not affected. If you answered yes, does the Groovy code write or store executable code in the temporary directory? If you answer yes, the risk is high, and can lead to local privilege escalation. Does the Groovy code write sensitive information, like API keys or passwords, into the temporary directory? If you answer yes, the risk is medium, and information may be exposed or modified.

Description:

Groovy was making use of a method in the JDK which is now flagged as not suitable for security-sensitive contexts. In addition, Groovy wasn’t checking a flag related to successful creation of the temporary directory which leads to a race condition whereby the vulnerability exists\[1\].

For the fixed versions, Groovy 2.5 and above is now using a newer JDK method which creates a directory that is only readable by the user running the Groovy code. The same is true for the fixed Groovy 2.4 version except if running on a pre-JDK7 version of the JDK in which case a fallback implementation is used which now checks for successful creation of the temporary directory. This eliminates the high-risk scenario involving the race condition whereby executables or information could be modified, but still leaves the potential for sensitive information leakage. Groovy 2.4/JDK 6 users are recommended to use the java.io.tmpdir mitigation.

Mitigation:

Setting the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems and all Groovy versions.

Users who cannot easily move to the fixed Groovy versions may wish to consider using the JDK’s Files#createTempDirectory method instead of the Groovy extension methods.

Credit:

Similar Vulnerabilities:

*   Jetty - https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6
    
*   JUnit4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp
    
*   Google Guava - https://github.com/google/guava/issues/4011
    
*   Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
    
*   JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
    

References:

**Reporting problems**

The Apache Software Foundation takes a very active stance in eliminating security problems in its software products. If you have questions about how to configure or use Groovy securely, you should send them to the users mailing list. If you find any security problems due to bugs in Groovy software, you should raise issues in the bug tracker. The Apache Software Foundation has a dedicated security team which you may contact should the need arise.

CVE-2020-17521: The Apache Groovy programming language

A local, arbitrary code execution vulnerability exists in the SplitCompat.install endpoint in Android's Play Core Library versions prior to 1.7.2. A malicious attacker could create an apk which targets a specific application, and if a victim were to install this apk, the attacker could perform a directory traversal, execute code as the targeted application and access the targeted application's data on the Android device. We recommend all users update Play Core to version 1.7.2 or later.

*   Platform
*   Android Studio
*   Google Play
*   Jetpack
*   Kotlin
*   Docs
    *   Overview
    *   Guides
    *   Reference
    *   Samples
    *   Design & Quality
*   Games

Stay organized with collections Save and categorize content based on your preferences.

This page explains what's included in the recent updates to the Google Play Core libraries.

**Migrate to the new Play libraries (April 2022)**

The Google Play Core Java and Kotlin library have been split into multiple separate libraries, one for each feature. Please update to following new libraries to benefit from new product additions:

*   Play Asset Delivery Library
*   Play Feature Delivery Library
*   Play In-App Reviews Library
*   Play In-App Updates Library

See migration guide for more information.

The monolithic library will not receive future updates or bug fixes.

**1.10.3 (January 2022)**

**Bug fixes**

*   Play Feature Delivery: Fixed a crash at startup time affecting certain devices.
*   Play Asset Delivery: Fixed a race condition that could rarely cause asset pack installation to fail with the error code -100.

**1.10.2 (September 2021)**

**Bug fixes**

*   Play Asset Delivery: Fixed an issue that could cause an ANR in certain edge cases during the installation of asset packs.
*   Play Asset Delivery: Fixed an issue that could cause the installation of fast-follow packs to fail.
*   General infrastructure fix that reduces number of internal errors for all APIs.

**1.10.1 (September 2021)**

**Behavior changes**

*   Increased Android minimum SDK version to 14 (Ice Cream Sandwich).

**Bug fixes**

*   Stability fixes to Play Feature Delivery (deferred uninstall and split emulation), In App Updates (improved input parameter validation) and general library infrastructure (handle corner-cases when the Play Store disabled or not running).
*   Introduced a dedicated ReviewException in the In App Review API.
*   Strengthened security of Play Feature Delivery split emulation.

**1.10.0 (February 2021)**

**New features**

*   Play Core Native SDK: Supports In-App Updates

**Behavior changes**

*   ReviewManager.requestReviewFlow() now provides a ReviewErrorCode.PLAY_STORE_NOT_FOUND error to indicate that the Play Store app is either not installed or not the official version.

**1.9.1 (January 2021)**

**Bug fixes**

*   Bug fixes for Play Asset Delivery and Play Feature Delivery.

**1.9.0 (December 2020)**

**New features**

*   Play Feature Delivery now provides a new user confirmation that enables feature delivery for users who installed your app from a different source than the Play Store.
    *   Previously this would result in an APP_NOT_OWNED error.
    *   Now, startInstall() returns a REQUIRES_USER_CONFIRMATION status for users who haven't installed the app from Play. After user acceptance, the download will proceed as normal.
    *   If your app already handles the REQUIRES_USER_CONFIRMATION status, there are no code changes required to benefit from this feature.

**Bug fixes**

*   Bug fixes for Play Asset Delivery.

**1.8.3 (October 2020)**

**Behavior changes**

*   Deprecated MissingSplitsManager. The feature is now obsolete. Incomplete installs with missing split APKs will fail on devices where Google Play Protect is active and on all devices running Android 10 or above.

**Bug fixes**

*   Fixed Play Asset Delivery patching bug affecting asset packs using texture compression format targeting.

**1.8.2 (September 2020)**

**Bug fixes**

*   Fixed UI flickering in the In-App Review API.
*   Minor bug fixes for other APIs.

**1.8.1 (August 2020)**

com.google.android.play:core-ktx bugfix release only.

**Bug fixes**

*   Fixes an issue where including the Play Core KTX library adds unnecessary permissions to the app project.

**1.8.0 (July 2020)**

**New features**

*   Adds support for In-App Reviews.
*   Kotlin extensions:
    *   New In-App Reviews extension.
*   Play Core Native SDK:
    *   Supports In-App Reviews.

**Behavior changes**

*   Play Asset Delivery, In-App Updates, and Play Feature Delivery now return a specific APP_NOT_OWNED error if the user hasn't acquired the app via Play. This error used to be surfaced as API_NOT_AVAILABLE: the latter is still used for other cases when the API is not available (such as when the device is not supported).
*   Bugfixes in Play Asset Delivery that improve the stability and performance of app updates with asset packs.
*   Play Core KTX no longer incorrectly exposes the ExperimentalCoroutinesApi annotation on its extension functions.

**Known issues**

*   The Play Core KTX artifact (com.google.android.play:core-ktx) incorrectly specifies its minSdkVersion, resulting in unnecessary permissions being added to the app project. Please use the 1.8.1 bugfix release of the KTX library.

**1.7.3 (May 2020)**

**New features**

*   Added AppUpdateOptions.setAllowClearStorage(boolean), an option to allow the In-App Updates API to delete Asset Packs if the device has insufficient storage for the update.

**Behavior changes**

*   Play Feature Delivery: Deprecated direct creation of FakeSplitInstallManager. Use FakeSplitInstallManagerFactory instead to create FakeSplitInstallManager.
*   In-App Updates: Deprecated InstallErrorCode.NO_ERROR_PARTIALLY_ALLOWED. The API now returns InstallErrorCode.NO_ERROR for this case.
*   Bugfixes in SplitCompat and the local testing mode for Play Asset Delivery.

**1.7.2 (March 2020)**

**Behavior changes**

*   Fixed a path traversal security vulnerability in Split Install API (CVE-2020-8913) and other general bugfixes. **If you are using a lower version, please update to this version.**

**1.7.1 (March 2020)**

**New features**

*   Play Core Native SDK:
    *   Supports Play Asset Delivery.

**Behavior changes**

*   Fixed a permission bug in the Play Asset Delivery API. **If you are using 1.7.0, please update to this version.**

**1.7.0 (March 2020)**

**New features**

*   Adds support for Play Asset Delivery.
*   Kotlin extensions:
    *   New Play Asset Delivery extension.
    *   Added support for new signals (update priority, app staleness, download progress) in the In-App Updates extension.

**1.6.5 (February 2020)**

**New features**

*   Adds new features to In-App Updates API:
    *   Check staleness of the installed version of your app.
    *   Monitor download progress.
    *   Retrieve in-app update priority, as as defined by you in the Google Play Developer API.
*   Better local testing of the module install flow using the FakeSplitInstallManager:
    *   Automatically instantiate the fake implementation of SplitInstallManager from SplitInstallManagerFactory if the App Bundle was built in local testing mode.
    *   Improvements to more realistically match the actual implementation.
*   You can now initiate SplitInstallManager confirmation flows from fragments (in addition to activities).

**Behavior changes**

*   Improved on-demand feature module installation performance, especially for Android L.
*   Kotlin extensions: The Flow returned by SplitInstallManager.requestProgressFlow now uses Channel.UNLIMITED instead of Channel.BUFFERED.

**1.6.4 (October 2019)**

**New features**

*   Adds FakeSplitInstallManager, which you can use for testing dynamic feature module install in integration tests, without connectivity.
*   Javadoc and IntDef annotations are now exported in the maven repository, providing Android Studio completion, etc.
*   Kotlin extensions now available in alpha. Add com.google.android.play:core-ktx:1.6.4 as a module dependency and include import com.google.android.play.core.ktx.* in your code.
*   You can now initiate in-app update flows from fragments (in addition to activities).

**1.6.3 (September 2019)**

This release includes general bugfixes.

**1.6.2 (September 2019)**

**New features**

*   Adds a new API SplitCompat.installActivity for installing SplitCompat on activities. This has better performance than calling full SplitCompat.install on the activity.

**Behavior changes**

*   Native code fix for loading certain libraries on certain devices
*   More robust recovery from interrupted SplitCompat
*   More useful information in the string representation of exceptions
*   Other general bugfixes and updated JavaDocs

**1.6.1 (July 2019)**

This release includes general bugfixes.

**1.6.0 (May 2019)**

**New features**

*   New Sideloading crash prevention API, which allows you to detect incomplete installation of apps that are built using an Android App Bundle. To learn more, read Verify non-Google Play app installs.

**1.5.0 (April 2019)**

**New features**

*   New In-App Update API, which allows you to request users to trigger an update directly from the app. To learn more, read Support in-app updates.

**1.4.1 (April 2019)**

**Behavior changes**

*   Fixes multi-process race condition in SplitCompat
*   Better background thread management

**1.4.0 (February 2019)**

**New features**

*   New API that allows you to download additional languages on demand
*   SplitCompat now supported on devices running Android Q

**1.3.7 (February 2019)**

**New features**

*   Adds explicit error codes for SplitCompat failure scenarios
*   Adds the startIntentSenderForResult() method to start the confirmation dialog. Using the PendingIntent directly has been deprecated. To learn more, read Obtain user confirmation

**Behavior changes**

*   Fixes race conditions in SplitCompat that, in rare occasions, lead to errors
*   Fixes bug in SplitCompat where, in the rare case that the app had no configuration splits, modules were not reported as installed

**1.3.6 (November 2018)**

**New features**

*   New INSUFFICIENT_STORAGE error when installs cannot complete due to lack of disk space

**Behavior changes**

*   A module is now reported as installed only if its master split is installed (previously any split would suffice)
*   Mixed case class names are no longer used, which sometimes caused issues when building on Windows

Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Last updated 2022-10-05 UTC.

Tag

#kotlin