Patent Description:
Developers of applications on the Android™ operating system are strongly competing to reduce power and run applications as efficiently as possible, while enhancing application performance. Various compilers, tools, and optimizers have been developed to help build applications with high-performance and low-energy profiles. However, much amount of information remains untapped in the Android Runtime Architecture (RTA) Layer.

<CIT> discloses computer-implemented methods, software, and systems, including methods for generating code visualizations including code analysis. Further, D1 discloses methods for gathering and analyzing runtime information that may be generated during code debugging.

<CIT> discloses techniques for automated classification of mobile applications battery consumption using simulations. The simulations are performed using a dynamic analyzer implemented as an instrumented Android emulator.

<CIT> Aldiscloses systems and methods for optimizing parameters of systems. The disclosed systems and methods involve a process for adapting "programming models" to achieve a desired behavior such as portability or to better utilize available resources.

<CIT> discloses methods to support performance analysis. These methods include compiling a program and embedding in the program performance profiling functionalities.

Embodiments described here are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

Embodiments described herein are directed to improvement of performance of developed applications using a smart runtime analyzer and advisor.

In conventional development of applications including Android applications (Android referring to the Android operating system for mobile and other devices), there are known tools and optimizers to assist in building applications. These tools may be applied to improve performance and reduce energy consumption in Android applications. For example, Profile Guided Optimization (PGO) is a well-known profile-based compiler optimization technique.

However, tools such as PGO focus on optimizing an application by generating optimized code based on sample data set for the application. PGO is ignorant about information that is present in the RTA (Android Runtime Architecture) layer. Android Runtime (ART) is an application runtime environment used by the Android operating system.

While the RTA may be utilized in enterprise platforms and operating environments, embedded systems and low-energy edge-computing devices such as smartphones based on Android have different characteristics and requirements, and thus enterprise solutions generally do not provide adequate results.

In some embodiments, a diagnostics and advisory tool is provided to intelligently process the internal runtime information, including symbol attributes, segment properties, and many more, available in the Executable and Linkable Format (ELF) portion (a binary object file) of the Android Runtime Layer, to produce impactful diagnostics. The ELF and the related ABI (Application Binary Interface) aspects of the ART are referred to herein as the "ART Layer". Technology to utilize such information is not present in the Android platform, and providing a solution to apply the runtime information can significantly augment the capabilities of application developers and library vendors on Android to achieve higher levels of performance and lower energy profiles.

In some embodiments, an application development tool includes both a static component for the development of an application utilizing internal runtime information, and a dynamic component to allow a developer to receive optional feedback from users.

<FIG> illustrates a runtime analyzer and advisor tool for application development, according to some embodiments. In some embodiments, a runtime analyzer and advisor diagnostic tool <NUM> includes a first component referred to as development and build component <NUM> in which diagnostics and advisory based performance improvements are provided in a development and build phase of product development.

The diagnostic tool <NUM> further includes a second component referred to as a diagnostic collection component <NUM>. In the diagnostic collection component <NUM> additional diagnostics (beyond the diagnostics provided in the development and build component <NUM>) can be collected from users who opt-in to participate in a user-experience-improvement-program, by installing a smart runtime analyzer and advisor (referred to herein as Smartan) Android app.

In some embodiments, the diagnostic tool <NUM> (which may be referred to as the Smartan tool) processes the raw information regarding an application available in the ELF portion (binary object file) of the ART, wherein the raw information may include:.

In some embodiments, the diagnostic tool <NUM> may further combine the information from the ELF with other runtime data (one or more other runtime artefacts, such as a call-graph (referring to a control-flow graph representing relationships in a program)), to produce meaningful and impactful diagnostics.

In some embodiments, the tool may obtain the raw information from the ELF in two ways:.

The development and build component <NUM> and the diagnostic collection component <NUM> may be utilized jointly in application development <NUM> to generate an application product <NUM>.

In some embodiments, the runtime analyzer and advisor tool <NUM> may be utilized to tap the potential of ART Layer information to provide crucial diagnostics and advisory information that is currently not readily available in the ART layer. The tool is to process raw information from the binary object file, combined with other runtime artifacts, and then produce resulting diagnostics for a developer. In a particular implementation, by default the tool may generate output to a standard output. However, several other developer friendly options are also available, such as storing data in a database that can later be used to compare and measure progress, storing output in a plain text file, or other similar output.

Once the diagnostics are generated, a developer may use these or refer to accompanying documentation regarding possible solutions for fixing runtime issues, programming constructs, or incorrect options, that are detected by the tool, and rebuild the application accordingly.

In addition to a static development phase, the invention also provides an Android system service (through a installed daemon on user devices) to enable an application to analyze additional dynamic runtime aspects that could not be analyzed during the static development phase. In some embodiments, this is an optional feature that users may choose to opt into as part of a user experience improvement program to assist developer in improving applications. For example, an Android app developer, making use of the runtime analyzer and advisor tool for development, may provide a link to the Smartan app in their app. Users can then install the app for the runtime analyzer and advisor tool on their device and enable monitoring. If a user has multiple apps that support the runtime analyzer and advisor tool app, the user may selectively enable only those apps that the user wants to opt-in for.

The dynamic runtime aspects that are captured by the runtime analyzer and advisor tool app may include, but are not limited to:.

In some implementations the daemon functionality provided by the runtime analyzer and advisor tool app may be provided by default on an Android stack (such as, for example, the Intel Celadon Stack) as an option (such as under the name SmartanDiag in a particular instance) under Developer Options. In this manner, users can opt-in by turning ON the option and selecting the apps to be monitored as required.

In some embodiments, the runtime analyzer and advisor tool app, in addition to such runtime analysis, may also provide dynamic optimization and performance boost by tuning certain Android kernel parameters (e.g., hugepagesz (a page size parameter), etc.) to optimum values, for those applications selected by the user, without affecting performance of any other apps on the device.

<FIG> is an illustration of a smart runtime analyzer and advisor system, according to some embodiments. In some embodiments, application development <NUM> includes operation of a runtime analyzer and advisor based workflow <NUM> in the development of a particular application to generate a first set of diagnostics and advisory information <NUM>, the information being provided to, for example, a diagnostics and advisory database <NUM>. The first set of diagnostics and advisory information <NUM> is generated based upon raw data that is read from the binary object file (ELF on Android) that is built on disk. The first set of diagnostics and advisory information <NUM> may be referred to as static diagnostics and advisory information as these are developed in the initial development of the application. The first set of diagnostics and advisory information is generated through analysis of the internal runtime information in the ELF portion of the Android Runtime Layer.

In some embodiments, the smart runtime analyzer and advisor system further includes receipt of data from diagnostic collection through operation of a runtime analyzer and advisor app <NUM>, wherein the runtime analyzer and advisor app is run on one or more user systems upon a respective user opting into the optional operation of the app. The diagnostic collection through operation of the runtime analyzer and advisor app <NUM> is to generate a second set of diagnostics and advisory information <NUM>, which may be referred to as dynamic diagnostics and advisory information as these are developed in the active user operation of the application. The second set of diagnostics and advisory information <NUM> is generated based upon reading in-memory ELF segments and library details, and may include symbols accessed dynamically, the runtime actual memory usage, and other related runtime info.

The second set of diagnostics and advisory information may be received via a network <NUM> (such as the Internet), with the generated information being provided to, for example, the diagnostics and advisory database <NUM>.

The stored information in the diagnostics and advisory database <NUM> then is available for the developer for diagnostics and advisory based recompilation of the application <NUM>.

<FIG> illustrates runtime analyzer and advisor based development workflow, according to some embodiments. The runtime analyzer and advisor based development workflow <NUM>, as illustrated in <FIG>, may include user application development <NUM>, relating to development of the Android application for user operation in the Android NDK (Native Development Kit), and building the Android stack <NUM>, as performed in the Android build system.

The user app development <NUM> may include dynamic linker operation <NUM> from Android device operation <NUM> (to load dynamic libraries) and static linker operation <NUM> (to load static libraries). In some embodiments, the user app development further includes RTA information in the ELF <NUM>, which is information that is not conventionally available for app development. The building of the Android stack also includes dynamic linker operation <NUM> from Android device operation <NUM> and static linker operation <NUM>.

In some embodiments, the output from the user app development <NUM> and the building of the Android stack <NUM> are received by a runtime analyzer and advisor tool <NUM>, which generates the first set of diagnostics and advisory information <NUM>, as illustrated in <FIG>.

<FIG> illustrates runtime layer elements that are accessed by a smart runtime analyzer and advisor system, according to some embodiments. In some embodiments, the runtime analyzer and advisor tool <NUM> is to access the executable and linkable format (ELF) <NUM> of the Android runtime layer <NUM>. The elements of the ELF that are accessed may include, but are not limited to:.

<FIG> illustrates diagnostics and advisory based recompilation, according to some embodiments. The diagnostics and advisory based recompilation <NUM> is based at least in part on data from the diagnostics and advisory database <NUM>, as illustrated in <FIG>.

In some embodiments, the recompilation <NUM> may include changing source code or adding runtime options as suggested by the diagnostic and advisory information <NUM>, which information may include both the first set of diagnostics and advisory information generated through analysis of the internal runtime information in the ELF portion of the Android Runtime Layer and the second set of diagnostics and advisory information developed in the user operation of the relevant application. The operation of the diagnostics and advisory based recompilation <NUM> allows for generation of an optimized application <NUM> and generation of an optimized Android stack <NUM> utilizing the processing of the internal runtime information in the Android Runtime Layer.

<FIG> is an illustration of diagnostic collection through a runtime analyzer and advisor application, according to some examples. Diagnostic collection through operation of a runtime analyzer and advisor app <NUM>, as illustrated in <FIG>, includes operation of a daemon <NUM> runtime analyzer and advisor application to collect diagnostic information from one or more applications, shown as App-<NUM><NUM> and App-<NUM><NUM>, in an app process address space during operation on a user system.

In some embodiments, the collection of data may be a developer option, and further may only occur if the user has opted into the data collection process. In some embodiments, a user having more than one eligible application may select which application or applications to opt into the data collection process, such as the user opting in either or both of App-<NUM><NUM> and App-<NUM><NUM> as illustrated in <FIG>. The operation of the runtime analyzer and advisor app <NUM> is to generate the second set of diagnostics and advisory information <NUM>, referred to as the dynamic diagnostics and advisory information, for either or both of App-<NUM><NUM> and App-<NUM><NUM>.

<FIG> is an illustration of diagnostics and advisory information generated by a runtime analyzer and advisor system, according to some embodiments. As illustrated in <FIG>, possible issues or problems that may be identified by the runtime analyzer and advisor system may include, but are not limited to, the following:.

In each case, the runtime analyzer and advisor system is to provide a diagnostic message identifying the detected problem, and providing advisory information to assist a developer in addressing the identified problem.

<FIG> is a flowchart to illustrate a process for providing diagnostics and advisory information in application development, according to some embodiments. In a diagnostics and advisory process <NUM>, code for an application (such as an Android application) is received at a platform for diagnostics and advisory analysis <NUM>. In the analysis, the application is run <NUM> and runtime layer data for the application is accessed <NUM>. In some embodiments, static diagnostic and advisory information is generated based on the runtime layer data <NUM>. The generated static diagnostic and advisory information may then be stored in a diagnostic and advisory database <NUM>.

In some embodiments, the process <NUM> further includes dynamic runtime information for the application from operation of a daemon on one or more user systems <NUM>. Dynamic diagnostic and advisory information is generated based on the received dynamic runtime information <NUM>. The generated dynamic diagnostic and advisory information may then be stored in the diagnostic and advisory database <NUM>.

In some embodiments, the stored diagnostic and advisory information stored in the diagnostic and advisory database may be made available to the application developer <NUM>, thus enabling development and improvement of the application and the software stack. The information provided to the developer may include, but is not limited to, diagnostics and advisory information as illustrated in <FIG>.

The flowchart illustrated in <FIG> may include machine readable instructions for a program for execution by processor circuitry. The program may be embodied in software stored on one or more non-transitory computer readable storage media such as a CD (Compact Disk) or DVD (Digital Video Disk), a hard disk drive (HDD), a solid state drive (SSD), a volatile memory (e.g., Random Access Memory (RAM) of any type, etc.), or a non-volatile memory (e.g., FLASH memory, an HDD (Hard Disk Drive), etc.) associated with processor circuitry located in one or more hardware devices. The program or parts thereof may alternatively be executed by one or more hardware devices other than the processor circuitry and/or embodied in firmware or dedicated hardware. The machine readable instructions may be distributed across multiple hardware devices and/or executed by two or more hardware devices (e.g., a server and a client hardware device). For example, the client hardware device may be implemented by an endpoint client hardware device (e.g., a hardware device associated with a user) or an intermediate client hardware device (e.g., a radio access network (RAN) gateway that may facilitate communication between a server and an endpoint client hardware device). Similarly, the non-transitory computer readable storage media may include one or more mediums located in one or more hardware devices. Although the example program is described with reference to the flowchart illustrated in <FIG>, many other methods of implementing may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., processor circuitry, discrete and/or integrated analog and/or digital circuitry, an FPGA (Field-Programmable Gate Array), an ASIC (Application-Specific Integrated Circuit), a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware. The processor circuitry may be distributed in different network locations and/or local to one or more hardware devices (e.g., a single-core processor (e.g., a single core central processor unit (CPU)), a multi-core processor (e.g., a multi-core CPU), etc.) in a single machine, multiple processors distributed across multiple servers of a server rack, multiple processors distributed across one or more server racks, a CPU and/or a FPGA located in the same package (e.g., the same integrated circuit (IC) package or in two or more separate housings, etc.).

The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data or a data structure (e.g., as portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers) located at the same or different locations of a network or collection of networks (e.g., in the cloud, in edge devices, etc.). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc., in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and/or stored on separate computing devices, wherein the parts when decrypted, decompressed, and/or combined form a set of machine executable instructions that implement one or more operations that may together form a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by processor circuitry, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc., in order to execute the machine readable instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, machine readable media, as used herein, may include machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.

<FIG> illustrates an embodiment of an exemplary computing architecture for operations including smart runtime analysis and advisory operation, according to some embodiments. In various embodiments as described above, a computing architecture <NUM> may comprise or be implemented as part of an electronic device.

In some embodiments, the computing architecture <NUM> may be representative, for example, of a computer system that implements one or more components of the operating environments described above. The computing architecture <NUM> may be utilized to provide smart runtime analysis and advisory operation, such as described in <FIG>.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive or solid state drive (SSD), multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the unidirectional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in <FIG>, the computing architecture <NUM> includes one or more processors <NUM> and one or more graphics processors <NUM>, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors <NUM> or processor cores <NUM>. In one embodiment, the system <NUM> is a processing platform incorporated within a system-on-a-chip (SoC or SOC) integrated circuit for use in mobile, handheld, or embedded devices.

An embodiment of system <NUM> can include, or be incorporated within, a server-based gaming platform, a game console, including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In some embodiments system <NUM> is a mobile phone, smart phone, tablet computing device or mobile Internet device. Data processing system <NUM> can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In some embodiments, data processing system <NUM> is a television or set top box device having one or more processors <NUM> and a graphical interface generated by one or more graphics processors <NUM>.

In some embodiments, the cache memory <NUM> is shared among various components of the processor <NUM>.

In some embodiments, one or more processor(s) <NUM> are coupled with one or more interface bus(es) <NUM> to transmit communication signals such as address, data, or control signals between processor <NUM> and other components in the system. The interface bus <NUM>, in one embodiment, can be a processor bus, such as a version of the Direct Media Interface (DMI) bus. However, processor buses are not limited to the DMI bus, and may include one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express), memory buses, or other types of interface buses. In one embodiment the processor(s) <NUM> include an integrated memory controller <NUM> and a platform controller hub <NUM>. The memory controller <NUM> facilitates communication between a memory device and other components of the system <NUM>, while the platform controller hub (PCH) <NUM> provides connections to I/O devices via a local I/O bus.

Memory device <NUM> can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, non-volatile memory device such as flash memory device or phase-change memory device, or some other memory device having suitable performance to serve as process memory. Memory device <NUM> may further include non-volatile memory elements for storage of firmware. In one embodiment the memory device <NUM> can operate as system memory for the system <NUM>, to store data <NUM> and instructions <NUM> for use when the one or more processors <NUM> execute an application or process. Memory controller hub <NUM> also couples with an optional external graphics processor <NUM>, which may communicate with the one or more graphics processors <NUM> in processors <NUM> to perform graphics and media operations. In some embodiments a display device <NUM> can connect to the processor(s) <NUM>. The display device <NUM> can be one or more of an internal display device, as in a mobile electronic device or a laptop device, or an external display device attached via a display interface (e.g., DisplayPort, etc.). In one embodiment the display device <NUM> can be a head mounted display (HMD) such as a stereoscopic display device for use in virtual reality (VR) applications or augmented reality (AR) applications.

In some embodiments the platform controller hub <NUM> enables peripherals to connect to memory device <NUM> and processor <NUM> via a high-speed I/O bus. The I/O peripherals include, but are not limited to, an audio controller <NUM>, a network controller <NUM>, a firmware interface <NUM>, a wireless transceiver <NUM>, touch sensors <NUM>, a data storage device <NUM> (e.g., hard disk drive, flash memory, etc.). The data storage device <NUM> can connect via a storage interface (e.g., SATA (Serial Advanced Technology Attachment)) or via a peripheral bus, such as a Peripheral Component Interconnect bus (e.g., PCI, PCI Express). The touch sensors <NUM> can include touch screen sensors, pressure sensors, or fingerprint sensors. The wireless transceiver <NUM> can be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver such as a <NUM>, <NUM>, Long Term Evolution (LTE), or <NUM> transceiver. The firmware interface <NUM> enables communication with system firmware, and can be, for example, a unified extensible firmware interface (UEFI). The network controller <NUM> can enable a network connection to a wired network. In some embodiments, a high-performance network controller (not shown) couples with the interface bus <NUM>. The audio controller <NUM>, in one embodiment, is a multi-channel high definition audio controller. In one embodiment the system <NUM> includes an optional legacy I/O controller <NUM> for coupling legacy (e.g., Personal System <NUM> (PS/<NUM>)) devices to the system. The platform controller hub <NUM> can also connect to one or more Universal Serial Bus (USB) controllers <NUM> connect input devices, such as keyboard and mouse <NUM> combinations, a camera <NUM>, or other USB input devices.

<FIG> is a block diagram of an example processor platform structured to execute the machine readable instructions or operations, according to some embodiments. As illustrated, a processor platform <NUM> can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, or a tablet), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset (e.g., an augmented reality (AR) headset, a virtual reality (VR) headset, etc.) or other wearable device, or any other type of computing device.

The processor platform <NUM> of the illustrated example includes processor circuitry <NUM>. The processor circuitry <NUM> of the illustrated example is hardware. For example, the processor circuitry <NUM> can be implemented by one or more integrated circuits, logic circuits, FPGAs microprocessors, CPUs, GPUs (Graphics Processing Units), DSPs, and/or microcontrollers from any desired family or manufacturer. The processor circuitry <NUM> may be implemented by one or more semiconductor based (e.g., silicon based) devices.

The processor circuitry <NUM> of the illustrated example includes a local memory <NUM> (e.g., a cache, registers, etc.). The processor circuitry <NUM> of the illustrated example is in communication with a main memory including a volatile memory <NUM> and a non-volatile memory <NUM> by a bus <NUM>. The volatile memory <NUM> may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), Dynamic Random Access Memory, and/or any other type of RAM device. Access to the main memory <NUM>, <NUM> of the illustrated example is controlled by a memory controller <NUM>.

The processor platform <NUM> of the illustrated example also includes interface circuitry <NUM>. The interface circuitry <NUM> may be implemented by hardware in accordance with any type of interface standard, such as an Ethernet interface, a universal serial bus (USB) interface, a Bluetooth® interface, a near field communication (NFC) interface, a PCI interface, and/or a PCIe interface.

In the illustrated example, one or more input devices <NUM> are connected to the interface circuitry <NUM>. The input device(s) <NUM> permit(s) a user to enter data and/or commands into the processor circuitry <NUM>. The input device(s) <NUM> can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, an isopoint device, and/or a voice recognition system.

One or more output devices <NUM> are also connected to the interface circuitry <NUM> of the illustrated example. The output devices <NUM> can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube (CRT) display, an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer, and/or speaker. The interface circuitry <NUM> of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip, and/or graphics processor circuitry such as a GPU.

The interface circuitry <NUM> of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) by a network <NUM>. The communication can be by, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, an optical connection, etc..

The processor platform <NUM> of the illustrated example also includes one or more mass storage devices <NUM> to store software and/or data. Examples of such mass storage devices <NUM> include magnetic storage devices, optical storage devices, floppy disk drives, HDDs, CDs, Blu-ray disk drives, redundant array of independent disks (RAID) systems, solid state storage devices such as flash memory devices, and DVD drives.

The machine executable instructions <NUM>, which may be implemented by the machine readable instructions of <FIG>, may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

<FIG> is a block diagram of an example implementation of processor circuitry. In this example, the processor circuitry is implemented by a microprocessor <NUM>. For example, the microprocessor <NUM> may implement multi-core hardware circuitry such as a CPU, a DSP, a GPU, an XPU, etc. Although it may include any number of example cores <NUM> (e.g., <NUM> core), the microprocessor <NUM> of this example is a multi-core semiconductor device including N cores. The cores <NUM> of the microprocessor <NUM> may operate independently or may cooperate to execute machine readable instructions. For example, machine code corresponding to a firmware program, an embedded software program, or a software program may be executed by one of the cores <NUM> or may be executed by multiple ones of the cores <NUM> at the same or different times. In some examples, the machine code corresponding to the firmware program, the embedded software program, or the software program is split into threads and executed in parallel by two or more of the cores <NUM>. The software program may correspond to a portion or all of the machine readable instructions and/or operations represented by the flowchart of <FIG>.

The cores <NUM> may communicate by an example bus <NUM>. In some examples, the bus <NUM> may implement a communication bus to effectuate communication associated with one(s) of the cores <NUM>. For example, the bus <NUM> may implement at least one of an Inter-Integrated Circuit (I2C) bus, a Serial Peripheral Interface (SPI) bus, a PCI bus, or a PCIe bus. Additionally or alternatively, the bus <NUM> may implement any other type of computing or electrical bus. The cores <NUM> may obtain data, instructions, and/or signals from one or more external devices by example interface circuitry <NUM>. The cores <NUM> may output data, instructions, and/or signals to the one or more external devices by the interface circuitry <NUM>. Although the cores <NUM> of this example include example local memory <NUM> (e.g., Level <NUM> (L1) cache that may be split into an L1 data cache and an L1 instruction cache), the microprocessor <NUM> also includes example shared memory <NUM> that may be shared by the cores (e.g., Level <NUM> (L2) cache) for high-speed access to data and/or instructions. Data and/or instructions may be transferred (e.g., shared) by writing to and/or reading from the shared memory <NUM>. The local memory <NUM> of each of the cores <NUM> and the shared memory <NUM> may be part of a hierarchy of storage devices including multiple levels of cache memory and the main memory. Typically, higher levels of memory in the hierarchy exhibit lower access time and have smaller storage capacity than lower levels of memory. Changes in the various levels of the cache hierarchy are managed (e.g., coordinated) by a cache coherency policy.

Each core <NUM> may be referred to as a CPU, DSP, GPU, etc., or any other type of hardware circuitry. Each core <NUM> includes control unit circuitry <NUM>, arithmetic and logic (AL) circuitry (sometimes referred to as an ALU) <NUM>, a plurality of registers <NUM>, the L1 cache <NUM>, and an example bus <NUM>. Other structures may be present. For example, each core <NUM> may include vector unit circuitry, single instruction multiple data (SIMD) unit circuitry, load/store unit (LSU) circuitry, branch/jump unit circuitry, floating-point unit (FPU) circuitry, etc. The control unit circuitry <NUM> includes semiconductor-based circuits structured to control (e.g., coordinate) data movement within the corresponding core <NUM>. The AL circuitry <NUM> includes semiconductor-based circuits structured to perform one or more mathematic and/or logic operations on the data within the corresponding core <NUM>. The AL circuitry <NUM> of some examples performs integer based operations. In other examples, the AL circuitry <NUM> also performs floating point operations. In yet other examples, the AL circuitry <NUM> may include first AL circuitry that performs integer based operations and second AL circuitry that performs floating point operations. In some examples, the AL circuitry <NUM> may be referred to as an Arithmetic Logic Unit (ALU). The registers <NUM> are semiconductor-based structures to store data and/or instructions such as results of one or more of the operations performed by the AL circuitry <NUM> of the corresponding core <NUM>. For example, the registers <NUM> may include vector register(s), SIMD register(s), general purpose register(s), flag register(s), segment register(s), machine specific register(s), instruction pointer register(s), control register(s), debug register(s), memory management register(s), machine check register(s), etc. The registers <NUM> may be arranged in a bank as shown in <FIG>. Alternatively, the registers <NUM> may be organized in any other arrangement, format, or structure including distributed throughout the core <NUM> to shorten access time. The bus <NUM> may implement at least one of an I2C bus, a SPI bus, a PCI bus, or a PCIe bus.

Each core <NUM> and/or, more generally, the microprocessor <NUM> may include additional and/or alternate structures to those shown and described above. For example, one or more clock circuits, one or more power supplies, one or more power gates, one or more cache home agents (CHAs), one or more converged/common mesh stops (CMSs), one or more shifters (e.g., barrel shifter(s)) and/or other circuitry may be present. The microprocessor <NUM> is a semiconductor device fabricated to include many transistors interconnected to implement the structures described above in one or more integrated circuits (ICs) contained in one or more packages. The processor circuitry may include and/or cooperate with one or more accelerators. In some examples, accelerators are implemented by logic circuitry to perform certain tasks more quickly and/or efficiently than can be done by a general purpose processor. Examples of accelerators include ASICs and FPGAs such as those discussed herein. A GPU or other programmable device can also be an accelerator. Accelerators may be on-board the processor circuitry, in the same chip package as the processor circuitry and/or in one or more separate packages from the processor circuitry.

<FIG> is a block diagram illustrating an example software distribution platform. The example software distribution platform <NUM> may be implemented by any computer server, data facility, cloud service, etc., capable of storing and transmitting software to other computing devices. The third parties may be customers of the entity owning and/or operating the software distribution platform <NUM>. For example, the entity that owns and/or operates the software distribution platform <NUM> may be a developer, a seller, and/or a licensor of software. The third parties may be consumers, users, retailers, OEMs (Original Equipment Manufacturers), etc., who purchase and/or license the software for use and/or re-sale and/or sub-licensing. In the illustrated example, the software distribution platform <NUM> includes one or more servers and one or more storage devices. The storage devices store machine readable instructions <NUM>.

The one or more servers of the example software distribution platform <NUM> are in communication with a network <NUM>, which may correspond to any one or more of the Internet or other network. In some examples, the one or more servers are responsive to requests to transmit the software to a requesting party as part of a commercial transaction. Payment for the delivery, sale, and/or license of the software may be handled by the one or more servers of the software distribution platform and/or by a third party payment entity. The servers enable purchasers and/or licensors to download the machine readable instructions <NUM> from the software distribution platform <NUM> to processor platforms <NUM>. In some examples, one or more servers of the software distribution platform <NUM> periodically offer, transmit, and/or force updates to the software to ensure improvements, patches, updates, etc., are distributed and applied to the software at the end user devices.

The following embodiments pertain to certain aspects of the invention:.

An embodiment of the invention may relate to a method according to claim <NUM>.

Another embodiment of the invention may include a non-transitory computer-readable storage medium according to claim <NUM>.

In a further embodiment of the invention may include a non-transitory computer-readable storage medium wherein the daemon is an optional operation for users of the application.

Another embodiment of the invention may relate to an apparatus according to claim <NUM>.

In a further embodiment of the invention the apparatus wherein the daemon is an optional operation for users of the Android application.

In a further embodiment of the invention the apparatus wherein the one or more user systems are mobile devices.

Another embodiment of the invention may relate to an apparatus including means for receiving code at a platform for an application; means for running the application; means for accessing runtime layer data for the application; means for generating static diagnostic and advisory data based on the runtime layer data, and storing the generated static diagnostic and advisory data in a diagnostic and advisory database; means for receiving dynamic runtime information for the application from operation on one or more user systems; and means for generating dynamic diagnostic and advisory information based on the received dynamic runtime information, and storing the generated dynamic diagnostic and advisory data in the diagnostic and advisory database.

In a further embodiment of the invention the apparatus wherein the application is an Android application.

In a further embodiment of the invention the apparatus wherein the apparatus further includes means for providing access to the static and dynamic diagnostic and advisory data in the diagnostic and advisory database to a developer of the application.

In a further embodiment of the invention the apparatus wherein accessing the runtime layer data for the application includes accessing data for development of the application and data for building a software stack.

In a further embodiment of the invention the apparatus wherein dynamic runtime information for the application is generated by a daemon running on each of the one or more user systems.

In a further embodiment of the invention the apparatus wherein the daemon is an optional operation for users of the application.

In the description above, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the described embodiments. It will be apparent, however, to one skilled in the art that embodiments may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form. There may be intermediate structure between illustrated components. The components described or illustrated herein may have additional inputs or outputs that are not illustrated or described.

Various embodiments may include various processes. These processes may be performed by hardware components or may be embodied in computer program or machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the processes. Alternatively, the processes may be performed by a combination of hardware and software.

Portions of various embodiments may be provided as a computer program product, which may include a computer-readable medium having stored thereon computer program instructions, which may be used to program a computer (or other electronic devices) for execution by one or more processors to perform a process according to certain embodiments. The computer-readable medium may include, but is not limited to, magnetic disks, optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically-erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or other type of computer-readable medium suitable for storing electronic instructions. Moreover, embodiments may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer.

Many of the methods are described in their most basic form, but processes can be added to or deleted from any of the methods and information can be added or subtracted from any of the described messages without departing from the basic scope of the present embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations can be made. The particular embodiments are not provided to limit the concept but to illustrate it. The scope of the embodiments is not to be determined by the specific examples provided above but only by the claims below.

If it is said that an element "A" is coupled to or with element "B," element A may be directly coupled to element B or be indirectly coupled through, for example, element C. When the specification or claims state that a component, feature, structure, process, or characteristic A "causes" a component, feature, structure, process, or characteristic B, it means that "A" is at least a partial cause of "B" but that there may also be at least one other component, feature, structure, process, or characteristic that assists in causing "B. " If the specification indicates that a component, feature, structure, process, or characteristic "may", "might", or "could" be included, that particular component, feature, structure, process, or characteristic is not required to be included. If the specification or claim refers to "a" or "an" element, this does not mean there is only one of the described elements.

Claim 1:
A method comprising:
receiving code at a platform for an application (<NUM>), wherein the application is an Android application;
running the application (<NUM>);
accessing runtime layer data for the application (<NUM>);
wherein the runtime layer data includes internal runtime information from a binary object file of an Android runtime layer;
generating static diagnostic and advisory data based on the runtime layer data (<NUM>), and storing the generated static diagnostic and advisory data in a diagnostic and advisory database (<NUM>);
receiving dynamic runtime information, generated based upon reading in-memory binary object file segments and library details, for the application from operation of the application on one or more user systems (<NUM>);
generating dynamic diagnostic and advisory information based on the received dynamic runtime information (<NUM>), and storing the generated dynamic diagnostic and advisory data in the diagnostic and advisory database; and
wherein dynamic runtime information for the application is generated by a daemon running on each of the one or more user systems,
using the static and dynamic diagnostic and advisory data to recompile the application.