Patent Description:
Software development kit (SDK) developers currently publish their libraries as a platform or computer language based archive. A library may depend on other libraries (known as transitive dependencies). Similar to applications (e.g., applications that run on mobile devices), these dependencies are declared in a library's build file. Once the library is ready to be shared, SDK developers distribute their libraries to application developers to integrate into their applications. A single SDK can contain one or more libraries. When an application is packaged, all the libraries it depends on (direct and transitive) are downloaded from repositories, conflicting library artifacts are resolved, and the code is compiled and merged with the application entries (e.g., exe files, native files, resources, assets, etc.).

<CIT> discloses interfaces for receiving software development kit runtime binaries configured for a standardized platform; receiving a driver framework package that is generated based on the software development kit and configured to enable extensibility under a set of constraints; and interacting with first party frameworks and allowing third party frameworks to access the software development kit runtime binaries and allow applications to use the third party frameworks.

In general, techniques of this disclosure are directed to separate packaging and distribution of software development kits (SDKs) and their respective application(s) that depend on them during runtime. In one example, the packaging and distribution are performed by a central computing system that serves the application developers, SDK developers, and users that download and install applications and SDK packages to their devices. As such, the techniques of this disclosure may take advantage of version control and distribution of the SDK builds, enforce policies (e.g., data access and privacy) associated with the interplay between an SDK build and an associated application, provide updates to SDK builds without requiring an application update, among other advantages.

In one example, this disclosure describes a method that includes receiving, by a computing system, a software development kit (SDK) bundle, wherein the SDK bundle comprises one or more SDK builds; packaging the SDK bundle into an SDK package configured to be installed on a device for access by one or more applications installed on the device, wherein each application is dependent upon an SDK build of the one or more SDK builds during runtime; and outputting the SDK package comprising the one or more SDK builds to the device, wherein each SDK build is configured to run in a separate process on the device with respect each corresponding application.

In another example, a computing device includes a memory and one or more processors operably coupled to the memory and configured to receive a software development kit (SDK) bundle, wherein the SDK bundle comprises one or more SDK builds; package the SDK bundle into an SDK package configured to be installed on a device for access by one or more applications installed on the device, wherein each application is dependent upon an SDK build of the one or more SDK builds during runtime; and output the SDK package comprising the one or more SDK builds to the device, wherein each SDK build is configured to run in a separate process on the device with respect each corresponding application.

In another example, this disclosure describes a method that includes receiving, by a user computing device, an install package that includes an application package and a software development kit (SDK) package, wherein an application in the application package declares a dependency on an SDK version; determining, by the user computing device, that an SDK in the SDK package matches the dependency declared by the application; running, by the user computing device, the SDK in a first process on the user computing device; running, by the user computing device, the application in a second process on the user computing device, the second process on the user computing device being distinct from the first process on the user computing device, wherein the SDK in the first process on the user computing device is restricted from access to data of the application in the second process on the user computing device and the application uses functionality of the SDK in a first process on the user computing device.

In another example, a computing device comprising means for receiving a software development kit bundle, wherein the software development kit bundle includes one or more software development kit builds, packaging the software development kit bundle into a software development kit package configured to be installed on a device for access by one or more applications installed on the device, wherein each application from the one or more applications installed on the device is dependent upon at least one software development kit build from the one or more software development kit builds during runtime, and providing, by the computing device and to the device (e.g., user computing system), the software development kit package including the one or more software development kit builds, wherein each software development kit build from the one or more software development kit builds is configured to run in a process on the device distinct from one or more processes in which the one or more applications run on the device.

Throughout the disclosure, examples are described where a computing system is configured for separately packaging and distributing software development kits (SDKs) that may include one or more libraries and their respective application(s) that depend on them. The application and SDK builds are often inseparable when delivered to the device (e.g., bundled into an executable file). Because they are bundled together, the SDK has the same data access as the application creating a security and privacy concern. Separation of the SDK from the device/client application not only isolates the SDK, but also enables the SDK to be updated independently from the application release and update lifecycle.

The separation and SDK policies provide control for a SDKs' data access on devices by running in isolation with respect to the application, such as by running in an "SDK Sandbox. " The SDK Sandbox includes SDKs that run in a separate process, thus creating clear boundaries between applications and SDKs and limiting SDK's data access, separate context, and no permissions. The platform may uninstall and manage the SDKs, control the SDK lifecycle on the device (including updating and disabling), and provide a kill switch for individual SDKs. The platform may prevent users of a device from uninstalling SDKs.

<FIG> is a block diagram illustrating an example SDK and application publishing system <NUM>, in accordance with one or more aspects of the present disclosure. Application publishing system <NUM> includes computing system <NUM>, application developer computing device <NUM>, SDK developer computing device <NUM>, and user computing device <NUM>. In some examples, computing system <NUM> may include stationary computing devices such as desktop computers. mainframes, etc., and may be in communication with remote computing systems, such as application developer computing device <NUM> and SDK developer computing device <NUM>, over one or more networks, such as network <NUM> and network <NUM>.

As shown in <FIG>, computing system <NUM> includes processors <NUM>, UI components <NUM> and storage devices <NUM>. Storage devices <NUM> includes distribution modules <NUM>, application package <NUM> and SDK package <NUM>. In one example, application developer computing device <NUM> and SDK developer computing device <NUM> may upload application bundle <NUM> and SDK bundle <NUM>, respectively, to the computing system <NUM> through network <NUM>. In one example, computing system <NUM> may receive and package, using processors <NUM> and distribution modules <NUM>, application bundle <NUM> and SDK bundle <NUM> into application package <NUM> and SDK package <NUM>. Distribution modules <NUM> may generate install package <NUM> that includes one or both of application package <NUM> and SDK package <NUM>. Computing system <NUM> may provide the software package to user computing device <NUM> through network <NUM>. Install package <NUM> includes one or more SDK builds and may include an application build, each installable on user computing device <NUM>.

In one example, user computing device <NUM> installs. from install package <NUM>, SDK <NUM> including one or more SDK builds and application <NUM>, each running in a separate process on user computing device <NUM>. Application <NUM> is dependent upon an SDK build of the one or more SDK builds during runtime. In another example. application <NUM> is resident on user computing device <NUM> and install package <NUM> includes an update to SDK <NUM> and includes a newer version of an SDK build compatible with application <NUM>.

In one example, network <NUM> and network <NUM> are the same network, in other examples they are different networks using the same or different communication protocols. Network <NUM> and network <NUM> may include network hubs, network switches, network routers. etc., that are operatively inter-coupled thereby providing for the exchange of information between computing system <NUM>, application developer computing device <NUM>, SDK developer computing device <NUM>, and user computing device <NUM>. In some examples. communication links associated with network <NUM> and network <NUM> may be wireless and/or wired connections, Ethernet, asynchronous transfer mode (ATM) or other network connections.

<FIG> is a block diagram illustrating example computing system <NUM> for generating software packages for distribution to user devices, in accordance with one or more aspects of the present disclosure. <FIG> illustrates one example of computing system <NUM>, as illustrated in <FIG>. Computing system <NUM> may include stationary computing devices such as desktop computers. mainframes, etc., and may be in communication with remote computing systems (e.g.. application developer computing device <NUM> and SDK developer computing device <NUM>), over one or more networks (e.g., network <NUM> and network <NUM>). Many other examples of computing system <NUM> may be used in other instances and may include a subset of the components included in example computing system <NUM> or may include additional components not shown in <FIG>.

As shown in the example of <FIG>, computing system <NUM> includes processors <NUM>, one or more input/output components, such as user interface components (UIC) <NUM>, one or more communication units <NUM>, and one or more storage devices <NUM>. Storage devices <NUM> of computing system <NUM> may include distribution modules <NUM> and operating system <NUM>, and UIC <NUM> may include I/O (input/output) devices <NUM>. Distribution modules <NUM> may include application package module <NUM>, SDK package module <NUM> and software package module <NUM>. The one or more communication units <NUM> of computing system <NUM>, for example, may communicate with external devices by transmitting and/or receiving data at computing system <NUM>, such as to and from SDK package module <NUM> and software package module <NUM> and remote computer systems, such as application developer computing device <NUM>, SDK developer computing device <NUM>, and user computing device <NUM> of <FIG>. For example, computing system <NUM> may receive, through communication units <NUM>, application bundle <NUM> and SDK bundle <NUM> from application developer computing device <NUM> and SDK developer computing device <NUM>, respectively. Application package module <NUM> generates an application package (e.g., application package <NUM>) and SDK package module <NUM> generates an SDK package (e.g., SDK package <NUM>) that includes one or more SDK builds.

In one example, software package module <NUM> combines the application package and the SDK package into a software package for sending to a device, such as user computing device <NUM>. In another example, software package module <NUM> sends the application package and the SDK package in separate packages (e.g., files) in the same or separate transmissions to user computing device <NUM>.

In another example, to support backwards compatibility, software package module <NUM> may generate the install package <NUM> by merging the SDK package (e.g., SDK package <NUM>) into the application package (e.g., application package <NUM>) for distribution to user devices that do not support runtime separation of SDKs from applications.

Example communication units <NUM> include a network interface card (e.g., such as an Ethernet card), an optical transceiver, a radio frequency transceiver, or any other type of device that may send and/or receive information. Other examples of communication units <NUM> may be devices configured to transmit and receive Ultrawideband®, Bluetooth®, GPS, <NUM>, <NUM>, and Wi-Fi®, etc. that may be found in computing devices, such as mobile devices and the like. As shown in the example of <FIG>, communication channels <NUM> may interconnect each of the components as shown for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels <NUM> may include a system bus, a network connection (e.g., to a wireless connection as described above), one or more inter-process communication data structures, or any other components for communicating data between hardware and/or software locally or remotely.

One or more storage devices <NUM> within computing system <NUM> may store information, such as data associated with SDK bundles, SDK builds, application bundles and application builds, SDK packages, application packages, software packages and other data discussed herein, for processing during operation of computing system <NUM>. In some examples, one or more storage devices of storage devices <NUM> may be a volatile or temporary memory. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. Storage devices <NUM>, in some examples, may also include one or more computer-readable storage media. Storage devices <NUM> may be configured to store larger amounts of information for longer terms in non-volatile memory than volatile memory. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage devices <NUM> may store program instructions and/or data associated with operating system <NUM> and distribution modules <NUM>.

One or more I/O devices <NUM> of computing system <NUM> may receive inputs and generate outputs. Examples of inputs are tactile, audio, kinetic, and optical input, to name only a few examples. Input devices of I/O devices <NUM>, in one example, may include a touchscreen, a touch pad, a mouse, a keyboard, a voice responsive system, a video camera, buttons, a control pad, a microphone or any other type of device for detecting input from a human or machine. Output devices of I/O devices <NUM>, may include, a sound card, a video graphics adapter card, a speaker, a display, or any other type of device for generating output to a human or machine.

One or more of distribution modules <NUM> may perform operations described herein using software, hardware, firmware, or a mixture of both hardware, software, and firmware residing in and executing on computing system <NUM> or at one or more other remote computing devices (e.g., cloud-based application - not shown). Computing system <NUM> may execute distribution modules <NUM>, such as application package module <NUM>, SDK package module <NUM> and software package module <NUM>, with one or more processors <NUM> or may execute any or part of distribution modules <NUM> as or within a virtual machine executing on underlying hardware. Distribution modules <NUM> may be implemented in various ways, for example, as a downloadable or pre-installed application, remotely as a cloud application or as part of operating system <NUM> of computing system <NUM>. Other examples of computing system <NUM> that implement techniques of this disclosure may include additional components not shown in <FIG>, <FIG> or <FIG>.

In the example of <FIG>, one or more processors <NUM> may implement functionality and/or execute instructions within computing system <NUM>. For example, one or more processors <NUM> may receive and execute instructions that provide the functionality of UIC <NUM>, communication units <NUM>, and one or more storage devices <NUM> and operating system <NUM> to perform one or more operations as described herein. One or more processors <NUM> may include central processing unit (CPU) <NUM>. Examples of CPU <NUM> include, but are not limited to, a digital signal processor (DSP), a general-purpose microprocessor, a tensor processing unit (TPU); a neural processing unit (NPU); a neural processing engine; a core of a CPU, VPU, GPU, TPU, NPU or other processing device, an application specific integrated circuit (ASIC), a field programmable logic array (FPGA), or other equivalent integrated or discrete logic circuitry, or other equivalent integrated or discrete logic circuitry.

One or more processors <NUM> may implement functionality and/or execute instructions within computing system <NUM>. For example, one or more processors <NUM> may receive and execute instructions that provide the functionality of some or all of distribution modules <NUM> to perform one or more operations and various functions described herein to package and distribute one or more SDK packages and one or more application packages. For example, SDK builds may be formatted as a stand-alone runnable object such that the SDK package plus all dependencies are packaged together in a single deliverable item independent of the application package.

In one example, the SDK and its associated application may depend on different versions of a common library (not shown). In such a case, the SDK package module (e.g., SDK package module <NUM>) may rename and repackage those dependencies based in the common library so as not to clash with an application library of same name and different version. In examples that use major and minor version types, when multiple applications on a device depend on the same major version of the SDK, then all those applications will depend on the same minor version of the SDK.

Distribution modules <NUM> may enable application developers to build a single application or artifact to target user computing devices that support the separated SDK and application as well as user computing devices that do not support the separated SDK and application. Application developers may rely on distribution modules <NUM> to correctly distribute to target user computing devices that support the separated SDK and application and target computing devices that do not support the separated SDK and application. Software package module <NUM> of distribution modules <NUM> may generate a combined package by merging the SDK package into the application package for distribution to user computing devices that do not support runtime separation of SDKs from applications. Software package module <NUM> may also send the application package and the SDK package as separate packages for user computing devices that support the separated SDK and application. Application developers merely have to provide the application and an indication of the SDK (such as an indication of a major version of the SDK in a declaration of dependency) to distribution modules <NUM>.

Distribution modules <NUM> may enable application developers to have some guarantees on which SDK versions will be deployed with their application, such as by using a declaration of dependency. As described below with respect to <FIG>, application developers may declare that an application has a dependency on a major version of an SDK. When a user computing device does not support runtime separation of SDKs from applications, software package module <NUM> of distribution modules <NUM> may generate a combined package by merging the SDK package, as indicated by the declaration of dependency, with the application package for distribution. When a user computing device does support runtime separation of SDKs from applications, software package module <NUM> of distribution modules <NUM> may provide the SDK package as indicated by the declaration of dependency. The declaration of dependency may also be provided to the user computing device to ensure that it uses the correct SDK version.

Distribution modules <NUM> may enable SDK developers to progressively roll out new versions, detect issues quickly, and rollback if necessary. Distribution modules <NUM> may be used to associate the SDK versions with the applications. New minor versions of the SDK may quickly be introduced using distribution modules <NUM>. A new SDK version may be associated with applications as soon as it is provided to distribution modules <NUM> at computing system <NUM>. Because computing system <NUM> distributes to many user computing devices, it may receive centralized feedback on issues with an SDK version which may be provided to the SDK developer. Such feedback may be more immediate than feedback from application developers using the SDK version.

Distribution modules <NUM> at computing system <NUM> may provide a central location for the rollback of an SDK version. Distribution modules <NUM> may disable an SDK version to be rolled back for an older SDK version. The older SDK version may be provided to user computing devices that support runtime separation of SDKs from applications as well as instructions to disable the newer SDK version. Distribution modules <NUM> may produce a combined package for the rollback by merging the older SDK with the application and providing them as a package to user computing devices that do not support runtime separation of SDKs from applications. Rollback of an SDK version through the centralized computing system <NUM> is quicker and more efficient than rollback of an SDK version through multiple application developers that each use the SDK version.

SDK updates may affect a large number of applications. For example, minor versions may be automatically updated by computing system <NUM> which may affect applications that depend on the corresponding major version of the SDK on the device. Computing system <NUM> may provide the SDK modules with the latest minor version available for a requested major version.

Safeguards may be used to minimize the negative impact of a bad SDK version, including a progressive, gradual rollout of new SDK versions. (such as to a fraction of users). Tooling for SDK Developers may be used to monitor the SDK rollout, with crash reporting functionality. The system may have an ability to roll back an SDK to a previous version as needed. The system may keep impacted applications informed about SDK updates and enable applications to report issues with SDKs.

SDK package module <NUM> may package the SDK bundle into an SDK package configured to be installed on a device (e.g., user computing device <NUM> of <FIG>) for access by one or more applications installed on the device. SDK package module <NUM> may format SDK builds as a stand-alone runnable object such that the SDK package plus all dependencies are packaged together in a single deliverable item independent of the application package.

Application package module <NUM> may generate an application package (e.g., application package <NUM>) from the application bundle <NUM> provided by the application developer. Application package module <NUM> may configure the application to be installed on a device (e.g., user computing device <NUM> of <FIG>). Application package module <NUM> may format applications such that they may be run in a first process and interact with an SDK in a separate process.

Software package module <NUM> may combine the application package and the SDK package into a software package for sending to a device, such as user computing device <NUM>. In another example, software package module <NUM> may send the application package and the SDK package in separate packages (e.g., files) in the same or separate transmissions to user computing device <NUM>.

<FIG> is a block diagram illustrating example user computing device <NUM> that sandboxes an SDK for an application, in accordance with one or more aspects of the present disclosure. <FIG> illustrates one example of user computing device <NUM>, as illustrated in <FIG>. User computing device <NUM> may include user devices such as smartphones, personal computers, smart watches, and may be in communication with remote computing systems (e.g., computing system <NUM>), over one or more networks (e.g.. network <NUM>). Many other examples of user computing device <NUM> may be used in other instances and may include a subset of the components included in example user computing device <NUM> or may include additional components not shown in <FIG>.

As shown in the example of <FIG>, user computing device <NUM> includes processors <NUM>, one or more input/output components, such as user interface components (UIC) <NUM>, one or more communication units <NUM>, and one or more storage devices <NUM>. Storage devices <NUM> of user computing device <NUM> may include distribution modules <NUM> and operating system <NUM>, and UIC <NUM> may include I/O (input/output) devices <NUM>.

One or more communication units <NUM> of user computing device <NUM>, for example, may communicate with external devices by transmitting and/or receiving data at user computing device <NUM>. such as to and from remote computer systems, such as computing system <NUM> of <FIG>. For example, user computing device <NUM> may receive, through communication units <NUM>, install package <NUM> from computing system <NUM>.

In one example, sandbox <NUM> contains SDK <NUM> that is used by application <NUM> but sandbox <NUM> does not contain application <NUM>. Sandbox <NUM> may be a controlled. restricted environment to run and execute code. This environment helps developers isolate and protect system resources from malware and other kinds of cyberthreats. Code in sandbox cannot take malicious action against code outside the sandbox because it does not have the appropriate default user privileges required to do so.

In the example of <FIG>, platform <NUM> maintains sandbox <NUM> for SDK <NUM> and sandbox <NUM> for application <NUM>. Sandbox <NUM> and sandbox <NUM> may be separate process maintained by operating system <NUM> and/or platform <NUM>. For example, platform <NUM> may separate the SDK <NUM> and application <NUM> using constructs of the operating system <NUM>. For example, if the operating system <NUM> is a Linux operating system or other operating system that uses user IDs (UIDs), platform <NUM> may assign unique UIDs to application <NUM> and SDK <NUM> so as to produce kernel level sandboxes. In this example, because sandboxes <NUM> and <NUM> are at the kernel level, the sandbox security model extends to native code and OS applications, and all software above the kernel, including OS libraries, application runtime and application frameworks.

The logical separation between an application and its SDKs disappears when the software package is compiled. SDKs typically have the same data access privileges as the application. SDKs may in particular access sensitive user data (such as location information) or application data, sometimes without the application developer's knowledge. Thus, even when sandboxing is used, the SDK and application are typically contained by the same sandbox.

Sandbox <NUM> (containing SDK <NUM> but not application <NUM>) may provide a clear boundary between application <NUM> and SDK <NUM>. In one embodiment, Sandbox <NUM> provides SDK <NUM> limited data access, a separate context, and no permissions. Separating SDK <NUM> from application <NUM> that depends on it may enforce policies through runtime isolation. Separate SDK <NUM> also benefits from better updatability, because user computing device <NUM> may update SDK <NUM> independently from application <NUM>.

SDK <NUM> may be an advertising SDK. Platform <NUM> may give SDK <NUM> access to privacy preserving application programing interfaces (APIs) suited for ad targeting. Platform <NUM> may also use a set of policies that dictate what types of ads SDK <NUM> may serve. Tools at platform <NUM> may enforce such policies.

SDK <NUM> may be shared by multiple applications at user computing device <NUM>. This means that SDK <NUM> need only be sent once to user computing device <NUM>. As discussed with respect to <FIG>, application <NUM> may declare a dependency on SDK <NUM> and the user computing device may then enable application <NUM> to interact with SDK <NUM> as needed.

Operating system <NUM> and/or platform <NUM> may control the installation and uninstallation of SDK <NUM>. Operating system <NUM> and/or platform <NUM> may control the lifecycle of SDK <NUM> on user computing device <NUM>, including updating and disabling SDK <NUM>. Operating system <NUM> and/or platform <NUM> may enable a rollback of the SDK version at user computing device <NUM> by SDK developers. In one example, SDK <NUM> is not directly uninstalled by users.

Operating system <NUM> and/or platform <NUM> may maintain backwards compatibility and run other applications which are combined with the SDK, as well as separated SDK <NUM> and application <NUM> shown in <FIG>. Such backwards compatibility enables previously created applications to run on user computing device <NUM>.

In one example, applications only explicitly declare the major version of the SDKs they depend on and only implicitly depending on their latest minor version User computing device <NUM> installs an SDK when its corresponding application is installed because applications are unable to run without all the SDKs they depend on. At runtime, the SDK may run in a sandbox and the platform may join the SDK and the application via the dependency declaration. In one example, multiple major versions of an SDK may be installed on the device, but only one minor version per major version.

Example communication units <NUM> include a network interface card (e.g., such as an Ethernet card), an optical transceiver, a radio frequency transceiver, or any other type of device that can send and/or receive information. Other examples of communication units <NUM> may be devices configured to transmit and receive Ultrawideband®, Bluetooth®, GPS, <NUM>, <NUM>, and Wi-Fi®, etc. that may be found in computing devices, such as mobile devices and the like. As shown in the example of <FIG>, communication channels <NUM> may interconnect each of the components as shown for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels <NUM> may include a system bus, a network connection (e.g., to a wireless connection as described above), one or more inter-process communication data structures, or any other components for communicating data between hardware and/or software locally or remotely.

One or more storage devices <NUM> within user computing device <NUM> may store information, such as operating system <NUM>, sandbox <NUM>, SDK <NUM> and application <NUM> and other data discussed herein, for processing during operation of user computing device <NUM>. In some examples, one or more storage devices of storage devices <NUM> may be a volatile or temporary memory. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. Storage devices <NUM>, in some examples, may also include one or more computer-readable storage media. Storage devices <NUM> may be configured to store larger amounts of information for longer terms in non-volatile memory than volatile memory. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage devices <NUM> may store program instructions and/or data associated with operating system <NUM> and distribution modules <NUM>.

One or more I/O devices <NUM> of user computing device <NUM> may receive inputs and generate outputs. Examples of inputs are tactile, audio, kinetic, and optical input to name only a few examples. Input devices of I/O devices <NUM>, in one example, may include a touchscreen, a touch pad, a mouse, a keyboard, a voice responsive system, a video camera, buttons, a control pad, a microphone or any other type of device for detecting input from a human or machine. Output devices of I/O devices <NUM>, may include, a sound card, a video graphics adapter card, a speaker, a display, or any other type of device for generating output to a human or machine.

Sandbox <NUM>, SDK <NUM>, and application <NUM> may perform operations described herein using software, hardware, firmware, or a mixture of both hardware, software, and firmware residing in and executing on user computing device <NUM> or at one or more other remote computing devices (e.g., cloud-based application - not shown). User computing device <NUM> may execute Sandbox <NUM>, SDK <NUM>, and application <NUM> as or within a virtual machine executing on underlying hardware. Sandbox <NUM>, SDK <NUM>, and application <NUM> may be implemented in various ways, for example, as a downloadable or pre-installed application, remotely as a cloud application or as part of operating system <NUM> of user computing device <NUM>. Other examples of user computing device <NUM> that implement techniques of this disclosure may include additional components not shown in <FIG>, <FIG> or <FIG>.

In the example of <FIG>, one or more processors <NUM> may implement functionality and/or execute instructions within user computing device <NUM>. For example, one or more processors <NUM> may receive and execute instructions that provide the functionality of UIC <NUM>, communication units <NUM>, and one or more storage devices <NUM> and operating system <NUM> to perform one or more operations as described herein. One or more processors <NUM> may include central processing unit (CPU) <NUM>. Examples of CPU <NUM> include, but are not limited to, a digital signal processor (DSP), a general-purpose microprocessor, a tensor processing unit (TPU); a neural processing unit (NPU); a neural processing engine; a core of a CPU, VPU, GPU, TPU, NPU or other processing device, an application specific integrated circuit (ASIC), a field programmable logic array (FPGA), or other equivalent integrated or discrete logic circuitry, or other equivalent integrated or discrete logic circuitry,.

One or more processors <NUM> may implement functionality and/or execute instructions within user computing device <NUM>. For example, one or more processors <NUM> may receive and execute instructions that provide the functionality of some or all of sandbox <NUM>, SDK <NUM>, and application <NUM> to perform one or more operations and various functions described herein.

Computing device <NUM> may receive install packages that include an application package and an SDK package. The application may declare a dependency on an SDK version. Computing device <NUM> may use the declared dependency to determine that an SDK version in an SDK package matches the dependency declared by the application. For example, the application may indicate a major version of the SDK that the application is dependent on. Computer device <NUM> may also select a minor version corresponding to the major version, such as the most recent minor version of the SDK, to run with the application.

Computing device <NUM> may support runtime separation of SDKs from applications using platform <NUM>, as discussed above. Computing device <NUM> may run the selected SDK <NUM> in a first process on the user computing device, such as in sandbox <NUM>, and the application in a second process distinct from the first process on the user computing device. The SDK <NUM> in the first process may be restricted from access to data of the application in the second process. SDK <NUM> may be less of a security and privacy risk because it cannot access the application data. Application <NUM> in the second process may use the functionality of the SDK <NUM> as it runs in the first process.

The SDKs and applications may also be updated independently. Computing device <NUM> may receive new minor versions of the SDK without receiving an application at the same time and if computing device <NUM> already has the correct SDK, computing device <NUM> does not have to resend the same SDK with a new version of the application.

<FIG> is a diagram illustrating examples of published versions of stand-alone SDK builds that may be distributed and installed via a software package that includes SDK package on user devices. Published versions of stand-alone SDK builds may be distributed by an application store (e.g., computing system <NUM> and <NUM> of <FIG> and <FIG>) and installed via an install package (e.g., install package <NUM>) that includes an SDK package on user devices (e.g., user computing device <NUM> of <FIG> and user computing device <NUM> of <FIG> ). For example, application <NUM> declared, when the application was developed, a dependency on SDK major version <NUM>. In one example, a host (e.g., application store) publishes a newer version of the SDK, such as SDK package <NUM> generated by computing system <NUM>, that includes major versions <NUM> and <NUM> and minor versions <NUM> and <NUM>. Because application <NUM> declared major version <NUM>, application <NUM> would automatically use the updated minor version <NUM> and not the older major version <NUM> or any of the <NUM> versions. This is similarly illustrated with application <NUM> and SDK package <NUM> that declared major version <NUM> utilizing minor version <NUM> in updated SDK package <NUM>.

Including multiple major versions within a single SDK package may enable multiple applications on the same device (e.g., user computing device <NUM>) to declare and utilize different versions of the SDK included in SDK package <NUM> without having to update the applications or request additional SDK builds. For example, SDK package <NUM> may include two or more major version and associated minor versions. Application <NUM> may declare major version <NUM> and application <NUM> may declare major version <NUM> of the SDK included in SDK package <NUM>. In this example, application <NUM> would utilize the latest minor version <NUM> and application <NUM> the latest minor version <NUM>, both included within SDK package <NUM>.

In the example of <FIG>, an application developer may upgrade a major version (to SDK V2. <NUM>), but because application <NUM> declares a dependency on an older major version (SDK V1. <NUM>), SDK versions V2. <NUM> and V1. <NUM> are both maintained on the user computing device. Only one SDK per major version need be maintained on the user computing device because a new minor version may replace an old minor version at the user computing device.

The "major version" / "minor version" model is just one example implementation of distributing sets of mutually substitutable SDK versions. In this example, all minor versions under the same major version are substitutable with each other because an application depending on one of the major or minor versions is ensured to be compatible with all of them within the same version. As such, minor versions belonging to different major versions, in this example, may not be substitutable with each other and conflict at runtime.

In other examples, SDK developers may upload an SDK bundle with multiple versions of the SDK builds and provide identifiers to groups of SDK builds that are mutually substitutable. For example, an SDK developer may include a graph where each SDK version is a node, and each connected component in the graph is a group of SDK build versions that may substitute each other. The application store may provide an updated SDK package that includes a new SDK build version to a device if the two (installed and new) versions belong to the same group of mutually substitutable SDK build versions.

<FIG> is a diagram illustrating an example workflow <NUM> showing a flows to publish an SDK package including SDK builds that may be distributed and installed via a software package (e.g., install package <NUM> to user devices, such as user computing device <NUM> of <FIG> and user computing device <NUM> of <FIG> ), in accordance with one or more aspects of the present disclosure. <FIG> is described below in the context of computing system <NUM> of <FIG> and computing system <NUM> of <FIG>. For example, application store <NUM> may be implemented in computing system <NUM> of <FIG> and computing system <NUM> of <FIG>. In other examples, SDK build system <NUM> and application build system <NUM> may be implemented by computing system <NUM> and computing system <NUM>, implemented on a different computer system, or locally on a developer's device (e.g., application developer computing device <NUM> and SDK developer computing device <NUM> of <FIG>), or any combination thereof.

<FIG> includes SDK bundle <NUM>, application package <NUM> and application bundle <NUM>, and SDK <NUM>. <FIG> additionally includes application store <NUM> that provides application package <NUM>, application <NUM>, and SDK <NUM> via an install package (e.g., install package <NUM>) of <FIG>) from application store <NUM>. As illustrated, , application package <NUM> includes the application code and SDK code packaged into a single inseparable file (e.g., Java executable file) at application development time and is distributed through application store <NUM> (e.g., computing system <NUM>, <NUM>). For example, as discussed above with respect to <FIG> to support backwards compatibility, application store <NUM> may generate the install package by merging the SDK package (e.g., from SDK bundle <NUM>) into the application package (e.g., from application bundle <NUM>) for distribution to user devices that do not support runtime separation of SDKs from applications.

In one example, in accordance with one or more aspects of the present disclosure, SDK bundle <NUM> may be provided to the application development environment and the application store <NUM>. SDK bundle <NUM> may be unbundled into SDK <NUM> and run separately from application bundle <NUM> in a sandboxed environment. In one example, SDK <NUM> includes one or more SDK builds that may include a multitude of major and minor version builds (e.g., v1. <NUM>, etc.). At development time, because the SDK code is not directly integrated into the application, application bundle <NUM> declares which major version (e.g., v2. <NUM>) of the SDK build it will depend upon for execution after installation on a device. This declaration permits application store <NUM> to manage, package and distribute the contents of SDK bundle <NUM> (e.g., SDK package <NUM>) to devices independently of application bundle <NUM>.

In one example, application store <NUM> distributes application bundle <NUM> received from the application development environment for packaging and distribution to a device (e.g., user computing device <NUM>). In one example, application bundle <NUM> may be received from an application developer and stored in application storage <NUM> as application bundle <NUM>. Application store <NUM> may retrieve and include application bundle <NUM> in an install package for distribution with or without an SDK bundle depending on destination device configuration. Application store <NUM> may separately package and distribute SDK <NUM> to the device to install and execute in a process separate from the application (e.g., sandboxed environment). In one example, an updated SDK bundle (e.g., new version of SDK bundle <NUM>) is provided to application store <NUM> and may include new major and minor versions of the SDK builds. Application store <NUM> may package and distribute (e.g., push out) the updated SDK bundle (e.g., SDK <NUM>) to user devices independent of the version of application <NUM>.

In one example, application store <NUM> may check and enforce policies against the contents of SDK bundle <NUM> prior to distributing SDK <NUM>. This provides one example advantage of providing security and data protection against an SDK bundle that may compromise data (e.g., user data), violate application store policies, and fraud, such as creating false clicks for payment within an advertising SDK executing in conjunction with an application.

In one example, an SDK developer may use the SDK build system <NUM> to create a new SDK module. SDK build system <NUM> may download any transitive dependencies from external repositories, and then compile, optimize and package the SDK. SDK build system <NUM> may validate the SDK to ensure it meets privacy and other and store the SDK bundle in SDK storage.

At application build system <NUM>, application developers may have the SDK code that will be fused into the application for faster incremental builds. The application developer may also side-load the SDK into a sandbox testing environment.

Application store <NUM> may store and provide install packages to devices. In the example of <FIG>, device <NUM> is provided application package <NUM> and device <NUM> is provided separate application <NUM> and SDK <NUM>.

Application store <NUM> may provide the latest minor version of the SDK to devices <NUM> and <NUM>. When a new minor version is provided to application store <NUM> from the SDK developer. Application store <NUM> may repackage the install packages provided to devices <NUM> and <NUM>.

<FIG> is a flowchart illustrating an example mode of operation for a computing device to generate software packages for distribution to user devices, in accordance with one or more aspects of the present disclosure. <FIG> is described below in the context of computing system <NUM> of <FIG> and computing system <NUM> of <FIG>. Computing system <NUM> may act as a central location receiving application bundles <NUM> from an application developer and receiving SDK bundles <NUM> from an SDK developer in the sense that computing system <NUM> may be under the control of a single entity to receive and distribute applications and SDKs even when computing system <NUM> is distributed. The computing system <NUM> may provide SDKs such as in install package <NUM> to user computing device <NUM>.

As shown in <FIG>, computing system <NUM>, for example, may receive a software development kit (SDK) bundle, wherein the SDK bundle includes one or more SDK builds (<NUM>). Computing system <NUM> may act as a central provider of the SDK builds rather than relying on application developers to combine the SDK with applications. Having computer system <NUM> receive the SDK bundles enables computing system <NUM> to act as such a central provider of the SDK builds.

Computing system <NUM> may package the SDK bundle into an SDK package configured to be installed on a device (e.g., user computing device <NUM>) for access by one or more applications installed on the device, wherein each application is dependent upon an SDK build of the one or more SDK builds during runtime (<NUM>). The computing device may output the SDK package including the one or more SDK builds to the device, wherein each SDK build is configured to run in a separate process on the device with respect to each corresponding application (<NUM>). The SDK package may be part of install package <NUM> provided to the device (such as, user computing device <NUM>). Having each SDK build configured to run in a separate process on the device with respect to each corresponding application enables the device (such as, user computing device <NUM>) to run the SDK in a different process than the application. This provides security and privacy advantages because the SDK may be restricted from having all the privileges of the application. For example, the device (such as, user computing device <NUM>) may sandbox the SDK such that it does not have access to application data because the SDK does not run in the same process as the application.

<FIG> is a flowchart illustrating an example mode of operation for a user computing device to run an SDK and application in different processes, in accordance with one or more aspects of the present disclosure. <FIG> is described below in the context of user computing device <NUM> of <FIG> and user computing device <NUM> of <FIG>. As shown in <FIG>, user computing device <NUM>, for example, may receive an install package that includes an application package and a software development kit (SDK) package, wherein an application in the application package declares a dependency on an SDK version (<NUM>). User computing device <NUM> may use the declaration of dependency of the application on the SDK version to avoid having to run a combined application and SDK, which is typically run as a single process.

User computing device <NUM> may determine that an SDK in the SDK package matches the dependency declared by the application (<NUM>). User computing device <NUM> may run the SDK in a first process on the user computing device <NUM> (<NUM>). User computing device <NUM> may run the application in a second process on user computing device <NUM>, the second process on user computing device <NUM> being distinct from the first process on the user computing device <NUM>, wherein the SDK in the first process on user computing device <NUM> is restricted from access to data of the application in the second process on user computing device <NUM> and the application uses functionality of the SDK in a first process on user computing device <NUM> (<NUM>). Because user computing device <NUM> runs the application and SDK in separate processes, user computer device may restrict the operations of the SDK and improve privacy and security such as by restricting access to data of the application. User computing device <NUM> may thus sandbox the SDK in a way that would not be possible if a combined SDK and application is run in a single process.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. It should be understood, however, that computer-readable storage mediums and media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Combinations of the above should also be included within the scope of a computer-readable medium.

The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. A control unit including hardware may also perform one or more of the techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various techniques described in this disclosure. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware, firmware, or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware, firmware, or software components, or integrated within common or separate hardware, firmware, or software components.

Claim 1:
A method comprising:
receiving, by a computing system (<NUM>, <NUM>), a software development kit bundle (<NUM>), wherein the software development kit bundle includes one or more software development kit builds;
packaging, by the computing system, the software development kit bundle into a software development kit package (<NUM>) configured to be installed on a device (<NUM>, <NUM>) for access by one or more applications (<NUM>) installed on the device, wherein each application from the one or more applications installed on the device is dependent upon a software development kit build from the one or more software development kit builds during runtime; and
providing, by the computing system and to the device, the software development kit package including the one or more software development kit builds, wherein each software development kit build from the one or more software development kit builds is configured to run in a process on the device distinct from one or more processes in which the one or more applications run on the device.