From e23031c974c9b051ba639f9ad68f891e2ae87da3 Mon Sep 17 00:00:00 2001
From: David Friedman downloads
\ No newline at end of file
+ndk.win64_download=android-ndk-r10e-windows-x86_64.exe
+ndk.win64_bytes=419616132
+ndk.win64_checksum=8412bb4991a95e08fda50b5a44d95df7
+
+ndk.win32_download=android-ndk-r10e-windows-x86.exe
+ndk.win32_bytes=396563176
+ndk.win32_checksum=1a82445baaf62aec3a46386ab1e5772c
+
+page.title=NDK Downloads
+@jd:body
\ No newline at end of file
diff --git a/docs/html-ndk/ndk/guides/abis.jd b/docs/html-ndk/ndk/guides/abis.jd
new file mode 100644
index 000000000000..81604b5eefeb
--- /dev/null
+++ b/docs/html-ndk/ndk/guides/abis.jd
@@ -0,0 +1,493 @@
+page.title=ABI Management
+@jd:body
+
+ Different Android handsets use different CPUs, which in turn support different instruction sets.
+Each combination of CPU and instruction set(s) has its own Application Binary Interface, or
+ABI. The ABI defines, with great precision, how an application's machine code is supposed to
+interact with the system at runtime. You must specify an ABI for each CPU architecture you want
+your app to work with. A typical ABI includes the following information: This page enumerates the ABIs that the NDK supports, and provides information about how each ABI
+works. Each ABI supports one or more instruction sets. Table 1 provides an at-a-glance overview of
+the instruction sets each ABI supports. More detailed information about each ABI appears below. This ABI is for ARM-based CPUs that support at least
+the ARMv5TE instruction set. Please refer to the following documentation for
+more details: The AAPCS standard defines EABI as a family of similar
+but distinct ABIs. Also, Android follows the little-endian
+
+ARM GNU/Linux ABI. This ABI does not support hardware-assisted floating point
+computations. Instead, all floating-point operations use software helper
+functions from the compiler's {@code libgcc.a} static library. The armeabi ABI supports ARMâs
+
+Thumb (a.k.a. Thumb-1) instruction set. The NDK generates Thumb
+code by default unless you specify different behavior using the
+ This ABI extends armeabi to include several
+
+CPU instruction set extensions. The instruction extensions that this Android-specific
+ABI supports are: Other extensions that the v7-a ARM spec describes, including
+
+Advanced SIMD (a.k.a. NEON), VFPv3-D32, and ThumbEE, are optional
+to this ABI. Since their presence is not guaranteed, the system should check at runtime
+whether the extensions are available. If they are not, you must use alternative code paths. This
+check is similar to the one that the system typically performs to check or use
+MMX,
+SSE2, and other specialized
+instruction sets on x86 CPUs. For information about how to perform these runtime checks, refer to
+CPU Features.
+Also, for information about the NDK's support for building
+machine code for NEON, see
+NEON Support. The {@code armeabi-v7a} ABI uses the {@code -mfloat-abi=softfp} switch to
+enforce the rule that the compiler must pass all double values in core register pairs during
+function calls, instead of dedicated floating-point ones. The system can perform all internal
+computations using the FP registers. Doing so speeds up the computations greatly. Although the requirement to use core register pairs produces a modest performance hit, it ensures
+compatibility with all existing armeabi binaries. If you need the additional
+performance, you can specify your ABI as {@code armeabi-v7a-hard} instead. Doing so
+allows you to use hard floats, while still linking with Android native APIs
+that use {@code softfp}. For more information, refer to the comments in
+{@code $NDK/tests/device/hard-float/jni/android.mk}. Note: You cannot specify {@code APP_ABI} as both
+{@code armeabi-v7a} and {@code armeabi-v7a-hard}. In either case, the build system places the
+shared libraries in the {@code armeabi-v7a/} directory. This variant of the {@code armeabi-v7a} ABI is unique to the NDK. The NDK build
+system adds the following flags in addition to those that it uses for the
+{@code armeabi-v7a} ABI: The compiler compiles all code with hard-float, and links it with {@code libm_hard.a}.
+This math library is the same one as {@code libm.a}, except that it follows hard-float ABI
+conventions. In the APK, the generated shared libraries reside in {@code /lib/armeabi-v7a/}. This ABI is for ARMv8-based CPUs that support AArch64. It also includes the NEON and
+VFPv4 instruction sets. For more information, see the
+ARMv8
+Technology Preview, and contact ARM for further details. This ABI is for CPUs supporting the instruction set commonly
+referred to as "x86" or "IA-32". Characteristics of this ABI include: These flags target the the Pentium Pro instruction set, along with the
+the MMX,
+SSE,
+SSE2,
+SSE3, and
+SSSE3 instruction set extensions.
+The generated code is an optimization balanced across the top Intel 32-bit
+CPUs. For more information on compiler flags, particularly related to performance optimization,
+refer to GCC
+x86 Performance. The ABI does not include any other optional IA-32 instruction set
+extensions, such as: You can still use these extensions, as long as you use runtime feature-probing to
+enable them, and provide fallbacks for devices that do not support them. The NDK toolchain assumes 16-byte stack alignment before a function call. The default tools and
+options enforce this rule. If you are writing assembly code, you must make sure to maintain stack
+alignment, and ensure that other compilers also obey this rule. Refer to the following documents for more details: This ABI is for CPUs supporting the instruction set commonly referred to as
+"x86-64." It supports instructions that GCC typically generates with the following
+compiler flags: These flags target the x86-64 instruction set, according to the GCC
+documentation. along with the
+MMX,
+SSE,
+SSE2,
+SSE3,
+SSSE3,
+SSE4.1,
+SSE4.2, and
+POPCNT
+instruction-set extensions. The generated code is an optimization balanced
+across the top Intel 64-bit CPUs. For more information on compiler flags, particularly related to performance optimization,
+refer to GCC
+x86 Performance. This ABI does not include any other optional x86-64 instruction set
+extensions, such as: You can still use these extensions, as long as you use runtime feature probing to
+enable them, and provide fallbacks for devices that do not support them. Refer to the following documents for more details: This ABI is for MIPS-based CPUs that support at least the MIPS32r1 instruction set. It includes
+the following features: For more information, please refer to the following documentation: The MIPS-specific documentation is available
+here, with
+further information
+here. This ABI is for MIPS64 R6. For more information, see
+MIPS Architecture. By default, the NDK generates machine code for the armeabi ABI. You can
+generate ARMv7-a-compatible machine code, instead, by adding the following line
+to your {@code Application.mk} file. To build machine code for two or more distinct ABIs, using spaces as delimiters. For
+example: This setting tells the NDK to build two versions of your machine code: one
+for each ABI listed on this line. For more information on the values you can specify for the
+{@code APP_ABI} variable, see Android.mk.
+ When you build multiple machine-code versions, the build system copies the libraries to your
+application project path, and ultimately packages them into your APK, so creating
+a fat binary. A fat binary
+is larger than one containing only the machine code for a single system; the tradeoff is
+gaining wider compatibility, but at the expense of a larger APK. At installation time, the package manager unpacks only the most appropriate
+machine code for the target device. For details, see Automatic
+extraction of native code at install time. This section provides details about how the Android platform manages native
+code in APKs. Both the Play Store and Package Manager expect to find NDK-generated
+libraries on filepaths inside the APK matching the following pattern: Here, {@code <abi>} is one of the ABI names listed under Supported ABIs,
+and {@code <name>} is the name of the library as you defined it for the {@code LOCAL_MODULE}
+variable in the {@code Android.mk} file. Since
+APK files are just zip files, it is trivial to open them and confirm that the shared native
+libraries are where they belong. If the system does not find the native shared libraries where it expects them, it cannot use
+them. In such a case, the app itself has to copy the libraries over, and then
+perform In a fat binary, each library resides under a directory whose name matches a corresponding ABI.
+For example, a fat binary may contain: Note: ARMv7-based Android devices running 4.0.3 or earlier
+install native libraries from the {@code armeabi} directory instead of the {@code armeabi-v7a}
+directory if both directories exist. This is because {@code /lib/armeabi/} comes after
+{@code /lib/armeabi-v7a/} in the APK. This issue is fixed from 4.0.4. The Android system knows at runtime which ABI(s) it supports, because build-specific system
+properties indicate: This mechanism ensures that the system extracts the best machine code from
+the package at installation time. For best performance, you should compile directly for the primary ABI. For example, a
+typical ARMv5TE-based device would only define the primary ABI: {@code armeabi}. By contrast, a
+typical, ARMv7-based device would define the primary ABI as {@code armeabi-v7a} and the secondary
+one as {@code armeabi}, since it can run application native binaries generated for each of them. Many x86-based devices can also run {@code armeabi-v7a} and {@code armeabi} NDK binaries. For
+such devices, the primary ABI would be {@code x86}, and the second one, {@code armeabi-v7a}. A typical MIPS-based device only defines a primary abi: {@code mips}. When installing an application, the package manager service scans the APK, and looks for any
+shared libraries of the form: If none is found, and you have defined a secondary ABI, the service scans for shared libraries of
+the form: When it finds the libraries that it's looking for, the package manager
+copies them to If there is no shared-object file at all, the application builds and installs, but crashes at
+runtime. This page describes the syntax of the {@code Android.mk} build file,
+which glues your C and C++ source files to the Android NDK. The {@code Android.mk} file resides in a subdirectory of your project's {@code jni/} directory,
+and describes your sources and shared libraries to the build system. It is really a tiny GNU
+makefile fragment that the build system parses once or more. The {@code Android.mk} file is useful
+for defining project-wide settings that {@code Application.mk}, the build system, and your
+environment variables leave undefined. It can also override project-wide settings for specific
+modules. The syntax of the {@code Android.mk} allows you to group your sources into
+modules. A module is either a static library, a shared library, or a standalone
+executable. You can define one or more modules in each {@code Android.mk} file, and
+you can use the same source file in multiple modules. The build system only places shared libraries
+into your application package. In addition, static libraries can generate shared libraries. In addition to packaging libraries, the build system handles a variety of other details for you.
+For example, you don't need to list header files or explicit dependencies between generated files in
+your {@code Android.mk} file. The NDK build system computes these relationships automatically for
+you. As a result, you should be able to benefit from new toolchain/platform support in future NDK
+releases without having to touch your {@code Android.mk} file. The syntax of this file is very close to that used in the {@code Android.mk} files distributed with
+the full Android Open Source Project. While the
+build system implementation that uses them is different, their similarity is an
+intentional design decision aimed at making it easier for application
+developers to reuse source code for external libraries. Before exploring the syntax in detail, it is useful to start by understanding the basics
+of what a {@code Android.mk} file contains. This section uses the {@code Android.mk} file in the
+Hello-JNI sample toward that end, explaining the role that each line in the file plays. An {@code Android.mk} file must begin by defining the {@code LOCAL_PATH} variable:
+
+ This variable indicates the location of the source files in the development tree. Here, the macro
+function {@code my-dir}, provided by the build system, returns the path of the current directory
+(the directory containing the {@code Android.mk} file itself). The next line declares the {@code CLEAR_VARS} variable, whose value the build system provides.
+
+ The {@code CLEAR_VARS} variable points to a special GNU Makefile that clears many
+{@code LOCAL_XXX} variables for you, such as {@code LOCAL_MODULE}, {@code LOCAL_SRC_FILES}, and
+{@code LOCAL_STATIC_LIBRARIES}. Note that it does not clear {@code LOCAL_PATH}. This variable must
+retain its value because the system parses all build control files in a single GNU Make execution
+context where all variables are global. You must (re-)declare this variable before describing each
+module. Next, the {@code LOCAL_MODULE} variable stores the name of the module that you wish to build.
+Use this variable once per module in your application. Each module name must be unique and not contain any spaces. The build system, when it
+generates the final shared-library file, automatically adds the proper prefix and suffix to
+the name that you assign to {@code LOCAL_MODULE|. For example, the example that appears above
+results in generation of a library called {@code libhello-jni.so}. Note: If your module's name already starts with {@code lib}, the
+build system does not prepend an additional {@code lib} prefix; it takes the module name as-is, and
+adds the {@code .so} extension. So a source file originally called, for example, {@code libfoo.c}
+still produces a shared-object file called {@code libfoo.so}. This behavior is to support libraries
+that the Android platform sources generate from {@code Android.mk} files; the names of all such
+libraries start with {@code lib}. The next line enumerates the source files, with spaces delimiting multiple files: The {@code LOCAL_SRC_FILES} variable must contain a list of C and/or C++ source files to build
+into a module. The last line helps the system tie everything together: The {@code BUILD_SHARED_LIBRARY} variable points to a GNU Makefile script that collects all the
+information you defined in {@code LOCAL_XXX} variables since the most recent {@code include}. This
+script determines what to build, and how to do it. There are more complex examples in the samples directories, with commented
+{@code Android.mk} files that you can look at. In addition, the
+walkthrough of the native-activity sample
+disucsses that sample's {@code Android.mk} file in some detail. Finally, the next section explains
+the variables from this section in a bit more detail.
+
+
+ The build system provides many possible variables for use in the the {@code Android.mk} file.
+Many of these variables come with preassigned values. Others, you assign. In addition to these variables, you can also define your own arbitrary ones. If you do so, keep
+in mind that the NDK build system reserves the following variable names: If you need to define your own convenience variables in an {@code Android.mk} file, we
+recommend prepending {@code MY_} to their names.
+
+
+ This section discusses the GNU Make variables that the build system defines before parsing your
+{@code Android.mk} file. Under certain circumstances, the NDK might parse your {@code Android.mk}
+file several times, using a different definition for some of these variables each time. This variable points to a build script that undefines nearly all {@code LOCAL_XXX} variables
+listed in the "Developer-defined variables" section below. Use this variable to include
+this script before describing a new module. The syntax for using it is: This variable points to a build script that collects all the information about the module
+you provided in your {@code LOCAL_XXX} variables, and determines how to build a target shared
+library from the sources you listed. Note that using this script requires that you have already
+assigned values to {@code LOCAL_MODULE} and {@code LOCAL_SRC_FILES}, at a minimum (for more
+information about these variables, see Module-description variables). The syntax for using this variable is: A shared-library variable causes the build system to generate a library file with a {@code .so}
+extension. A variant of {@code BUILD_SHARED_LIBRARY} that is used to build a static library. The build
+system does not copy static libraries into your project/packages, but it can use them to build
+shared libraries (see {@code LOCAL_STATIC_LIBRARIES} and {@code LOCAL_WHOLE_STATIC_LIBRARIES},
+below). The syntax for using this variable is: A static-library variable causes the build system to generate a library with a {@code .a}
+extension. Points to a build script used to specify a prebuilt shared library. Unlike in the case of
+{@code BUILD_SHARED_LIBRARY} and {@code BUILD_STATIC_LIBRARY}, here the value of
+{@code LOCAL_SRC_FILES} cannot be a source file. Instead, it must be a single path to a prebuilt
+shared library, such as {@code foo/libfoo.so}. The syntax for using this variable is: You can also reference a prebuilt library in another module by using the
+{@code LOCAL_PREBUILTS} variable. The following example shows an example of using
+{@code LOCAL_PREBUILTS}:
+
+
+
+ For more information about using prebuilts, see
+NDK Prebuilt Library Support. The same as {@code PREBUILT_SHARED_LIBRARY}, but for a prebuilt static library. For more
+information about using prebuilts, see NDK Prebuilt
+Library Support. The name of the target CPU architecture as the Android Open Source Project specifies it.
+For any ARM-compatible build, use {@code arm}, independent of the CPU architecture revision or
+ABI (see TARGET_ARCH_ABI, below). The value of this variable is taken from the APP_ABI variable that you define in the
+{@code Android.mk} file, which the system
+reads ahead of parsing the {@code Android.mk} file. The Android API level number for the build system to target.
+For example, the Android 5.1 system images correspond to Android API level 22: {@code android-22}.
+For a complete list of platform names and corresponding Android system
+images, see Android NDK Stable APIs.
+The following example shows the syntax for using this variable: This variable stores the name of the CPU and architecture to target when the build system
+parses this {@code Android.mk} file. You can specify one or more of the following values, using
+a space as a delimiter between multiple targets. Table 1 shows the ABI setting to use for each
+supported CPU and architecture.
+
+ The following example shows how to set ARMv8 AArch64 as the target CPU-and-ABI combination: Note: Up to Android NDK 1.6_r1, this variable is defined as
+{@code arm}. For more details about architecture ABIs and associated compatibility
+issues, refer to
+
+Android Native CPU ABI Management New target ABIs in the future will have different values. A concatenation of target Android API level and ABI, it is especially useful when you want to test against
+a specific target system image for a real device. For example, to specify a 64-bit ARM device
+running on Android API level 22: Note: Up to Android NDK 1.6_r1, the default value was
+{@code android-3-arm}. The variables in this section describe your module to the build system. Each module description
+should follow this basic flow:
+ This variable is used to give the path of the current file. You must define
+it at the start of your {@code Android.mk} file. The following example shows how to do so: The script to which {@code CLEAR_VARS} points does not clear this variable. Therefore, you only need
+to define it a single time, even if your {@code Android.mk} file describes multiple modules. This variable stores the name of your module. It must be unique among all module names,
+and must not contain any spaces. You must define it before including any scripts (other than
+the one for {@code CLEAR_VARS}). You need not add either the {@code lib} prefix
+or the {@code .so} or {@code .a} file extension; the build system makes these modifications
+automatically. Throughout your {@code Android.mk} and {@code Application.mk} files, refer to
+your module by its unmodified name. For example, the following line results in the generation of a
+shared library module called {@code libfoo.so}: If you want the generated module to have a name other than {@code lib} + the value of
+{@code LOCAL_MODULE}, you can use the {@code LOCAL_MODULE_FILENAME} variable to give the
+generated module a name of your own choosing, instead. This optional variable allows you to override the names that the build system
+uses by default for files that it generates. For example, if the name of your {@code LOCAL_MODULE}
+is {@code foo}, you can force the system to call the file it generates {@code libnewfoo}. The
+following example shows how to accomplish this: For a shared library module, this example would generate a file called {@code libnewfoo.so}. Note: You cannot override filepath or file extension. This variable contains the list of source files that the build system uses to generate the
+module. Only list the files that the build system actually passes to the compiler, since the build
+system automatically computes any associated depencies. Note that you can use both relative (to {@code LOCAL_PATH}) and absolute file paths.
+
+ We recommend avoiding absolute file paths; relative paths make your
+{@code Android.mk} file more
+portable. Note: Always use Unix-style forward slashes (/) in build files.
+The build system does not handle Windows-style backslashes (\) properly. You can use this optional variable to indicate a file extension other than {@code .cpp} for your
+C++ source files. For example, the following line changes the extension to {@code .cxx}.
+(The setting must include the dot.)
+
+ From NDK r7, you can use this variable to specify multiple extensions. For instance: You can use this optional variable to indicate that your code relies on specific C++ features.
+It enables the right compiler and linker flags during the build process. For prebuilt binaries,
+this variable also declares which features the binary depends on, thus helping ensure the final
+linking works correctly. We recommend that you use this variable instead of enabling
+{@code -frtti} and {@code -fexceptions} directly in your {@code LOCAL_CPPFLAGS} definition. Using this variable allows the build system to use the appropriate flags for each module. Using
+{@code LOCAL_CPPFLAGS} causes the compiler to use all specified flags for all modules, regardless
+of actual need.On this page
+
+
+
+
+
+Supported ABIs
+
+
+
+
+
+
+
+ABI
+Supported Instruction Set(s)
+Notes
+
+
+
+{@code armeabi}
+
+No hard float.
+
+
+
+{@code armeabi-v7a}
+
+
+Hard float when specified as {@code armeabi-v7a-hard}.
+Incompatible with ARMv5, v6 devices.
+
+
+
+{@code arm64-v8a}
+
+
+
+
+
+{@code x86}
+
+No support for MOVBE or SSE4.
+
+
+
+{@code x86_64}
+
+
+
+
+
+{@code mips}
+
+Uses hard-float, and assumes a CPU:FPU clock ratio of 2:1 for maximum
+compatibility. Provides neither micromips nor MIPS16.
+
+
+{@code mips64}
+
+
+armeabi
+
+
+
+LOCAL_ARM_MODE
variable in your Android.mk
+file.armeabi-v7a (armeabi-v7a-hard)
+
+
+
+armeabi-v7a-hard
+
+TARGET_CFLAGS += -mhard-float -D_NDK_MATH_NO_SOFTFP=1
+TARGET_LDFLAGS += -Wl,--no-warn-mismatch -lm_hard
+
+
+arm64-v8a
+x86
+
+
+
+
+-march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32
+
+
+
+
+
+
+
+x86_64
+
+-march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel
+
+
+
+
+
+
+
+
+mips
+
+
+
+
+
+
+mips64
+Generating Code for a Specific ABI
+
+APP_ABI := armeabi-v7a
+
+
+
+APP_ABI := armeabi armeabi-v7a
+
+
+ABI Management on the Android Platform
+Native code in app packages
+
+/lib/<abi>/lib<name>.so
+
+
+dlopen()
.
+/lib/armeabi/libfoo.so
+/lib/armeabi-v7a/libfoo.so
+/lib/arm64-v8a/libfoo.so
+/lib/x86/libfoo.so
+/lib/x86_64/libfoo.so
+/lib/mips/libfoo.so
+/lib/mips64/libfoo.so
+
+
+Android Platform ABI support
+
+
+
+Automatic extraction of native code at install time
+
+
+lib/<primary-abi>/lib<name>.so
+
+
+
+lib/<secondary-abi>/lib<name>.so
+
+
+/lib/lib<name>.so
, under the application's
+{@code data} directory ({@code data/data/<package_name>/lib/}).On this page
+
+
+ Overview
+Basics
+
+LOCAL_PATH := $(call my-dir)
+
+
+
+include $(CLEAR_VARS)
+
+
+
+LOCAL_MODULE := hello-jni
+
+
+
+LOCAL_SRC_FILES := hello-jni.c
+
+
+
+include $(BUILD_SHARED_LIBRARY)
+
+
+Variables and Macros
+
+
+NDK-defined variables
+CLEAR_VARS
+
+include $(CLEAR_VARS)
+
+
+BUILD_SHARED_LIBRARY
+
+include $(BUILD_SHARED_LIBRARY)
+
+
+BUILD_STATIC_LIBRARY
+
+include $(BUILD_STATIC_LIBRARY)
+
+
+PREBUILT_SHARED_LIBRARY
+
+include $(PREBUILT_SHARED_LIBRARY)
+
+
+PREBUILT_STATIC_LIBRARY
+TARGET_ARCH
+TARGET_PLATFORM
+
+TARGET_PLATFORM := android-22
+
+
+TARGET_ARCH_ABI
+
+
+
+
+
+ CPU and architecture
+ Setting
+
+
+ ARMv5TE
+ {@code armeabi}
+
+
+ ARMv7
+ {@code armeabi-v7a}
+
+
+ ARMv8 AArch64
+ {@code arm64-v8a}
+
+
+ i686
+ {@code x86}
+
+
+ x86-64
+ {@code x86_64}
+
+
+ mips32 (r1)
+ {@code mips}
+
+
+ mips64 (r6)
+ {@code mips64}
+
+
+All
+ {@code all}
+
+TARGET_ARCH_ABI := arm64-v8a
+
+
+TARGET_ABI
+
+TARGET_ABI := android-22-arm64-v8a
+
+
+Module-description variables
+
+
+
+
+
+LOCAL_PATH
+
+LOCAL_PATH := $(call my-dir)
+
+
+LOCAL_MODULE
+
+LOCAL_MODULE := "foo"
+
+
+LOCAL_MODULE_FILENAME
+
+LOCAL_MODULE := foo
+LOCAL_MODULE_FILENAME := libnewfoo
+
+
+LOCAL_SRC_FILES
+LOCAL_CPP_EXTENSION
+
+LOCAL_CPP_EXTENSION := .cxx
+
+
+
+LOCAL_CPP_EXTENSION := .cxx .cpp .cc
+
+
+LOCAL_CPP_FEATURES
+
+
+LOCAL_CPP_FEATURES := rtti ++ +
To indicate that your code uses C++ exceptions, write:
+ ++LOCAL_CPP_FEATURES := exceptions ++ +
You can also specify multiple values for this variable. For example:
+ ++LOCAL_CPP_FEATURES := rtti features ++ +The order in which you describe the values does not matter. + + +
You can use this optional variable to specify a list of paths, relative to the +NDK {@code root} directory, to add to the include search path when compiling all sources +(C, C++ and Assembly). For example:
+ ++LOCAL_C_INCLUDES := sources/foo ++ +
Or even:
+ ++LOCAL_C_INCLUDES := $(LOCAL_PATH)/+ +/foo +
Define this variable before setting any corresponding inclusion flags via {@code LOCAL_CFLAGS} +or {@code LOCAL_CPPFLAGS}.
+ +The build system also uses {@code LOCAL_C_INCLUDES} paths automatically when launching native +debugging with ndk-gdb.
+ + +This optional variable sets compiler flags for the build system to pass when building C +and C++ source files. The ability to do so can be useful for specifying additional macro +definitions or compile options.
+ +Try not to change the optimization/debugging level in your {@code Android.mk} file. +The build system can handle this setting automatically for you, using the relevant information +in the {@code Application.mk} file. Doing it this way allows the build system to generate useful +data files used during debugging.
+ +Note: In android-ndk-1.5_r1, the corresponding flags only applied +to C source files, not C++ ones. They now match the full Android build system behavior. +(You can now use {@code LOCAL_CPPFLAGS} to specify flags for C++ sources only.)
+ +It is possible to specify additional include paths by writing: + +
+LOCAL_CFLAGS += -I<path>, ++ +It is better, however, to use {@code LOCAL_C_INCLUDES} for this purpose, since +doing so also makes it possible to use the paths available for native debugging with ndk-gdb. + + +
An optional set of compiler flags that will be passed when building C++ +source files only. They will appear after the LOCAL_CFLAGS on the +compiler's command-line.
+ + +Note: In android-ndk-1.5_r1, the corresponding flags applied to +both C and C++ sources. This has been corrected to match the full Android build system. +To specify flags for both C and C++ sources, use {@code LOCAL_CFLAGS}.
+ + +This variable stores the list of static libraries modules on which the current module depends.
+ +If the current module is a shared library or an executable, this variable will force +these libraries to be linked into the resulting binary.
+ +If the current module is a static library, this variable simply indicates that other +modules depending on the current one will also depend on the listed +libraries.
+ +This variable is the list of shared libraries modules on which this module depends at +runtime. This information is necessary at link time, and to embed the corresponding information +in the generated file.
+ +This variable is a variant of {@code LOCAL_STATIC_LIBRARIES}, and expresses that the linker +should treat the associated library modules as whole archives. For more information +on whole archives, see the GNU linker's +documentation for the +{@code --whole-archive} flag.
+ +This variable is useful when there are circular dependencies among +several static libraries. When you use this variable to build a shared library, it will force +the build system to add all object files from your static libraries to the final binary. The same +is not true, however, when generating executables.
+ + +This variable contains the list of additional linker flags for use in building your shared +library or executable. It enables you to use the {@code -l} prefix to pass the name of specific +system libraries. For example, the following example tells the linker to generate a module that +links to {@code /system/lib/libz.so} at load time:
+ ++LOCAL_LDLIBS := -lz ++ +
For the list of exposed system libraries against which you can link in this NDK release, see +Android NDK Stable APIs.
+ +Note: If you define this variable for a static library, +the build system ignores it, and {@code ndk-build} prints a warning.
+ +The list of other linker flags for the build system to use when building your shared library +or executable. For example, the following example uses the {@code ld.bfd} linker on ARM/X86 GCC +4.6+, on which {@code ld.gold} is the default
+ ++LOCAL_LDFLAGS += -fuse-ld=bfd ++ +
Note: If you define this variable for a static library, the build +system ignores it, and ndk-build prints a warning.
+ +By default, when the build system encounters an undefined reference encountered while trying to +build a shared, it will throw an undefined symbol error. This error can help you catch +catch bugs in your source code.
+ +To disable this check, set this variable to {@code true}. Note that this setting may cause the +shared library to load at runtime.
+ +Note: If you define this variable for a static library, +the build system ignores it, and ndk-build prints a warning.
+ +By default, the build system generates ARM target binaries in thumb mode, where each +instruction is 16 bits wide and linked with the STL libraries in the {@code thumb/} directory. +Defining this variable as {@code arm} forces the build system to generate the module's object +files in 32-bit {@code arm} mode. The following example shows how to do this:
+ ++LOCAL_ARM_MODE := arm ++ +
You can also instruct the build system to only build specific sources in {@code arm} mode by +appending {@code .arm} suffix to the the source filenames. For example, the following example +tells the build system to always compile {@code bar.c} in ARM mode, but to build +{@code foo.c} according to the value of {@code LOCAL_ARM_MODE}.
+ ++LOCAL_SRC_FILES := foo.c bar.c.arm ++ + + +
Note: You can also force the build system to generate ARM binaries +by setting {@code APP_OPTIM} in your +Android +NDK & ARM NEON Instruction Set Extension Support and Android +NDK CPU Features Detection Library.
+ +Alternatively, you can use the {@code .neon} suffix to specify that the build system only +compile specific source files with NEON support. In the following example, the build system compiles +{@code foo.c} with thumb and neon support, {@code bar.c} with thumb support, and +{@code zoo.c} with support for ARM and NEON:
+ ++LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon ++ + +
If you use both suffixes, {@code .arm} must precede {@code .neon}.
+ +Android NDK r4 added support for the "NX bit" security feature. It is +enabled by default, but you can disable it by setting this variable to {@code true}. We do not +recommend doing so without a compelling reason.
+ +This feature does not modify the ABI, and is only enabled on kernels +targeting ARMv6+ CPU devices. Machine code with this feature enabled +will run unmodified on devices running earlier CPU architectures.
+For more information, see Wikipedia: NX bit +and The GNU stack kickstart. + +
By default, the NDK compiles code with read-only relocations and GOT +protection. This variable instructs the runtime linker to mark certain regions of memory +as read-only after relocation, making certain security exploits (such as GOT overwrites) +more difficult. Note that these protections are only effective on Android API level 16 and higher. +On lower API levels, the code will still run, but without memory protections.
+ +This variable is turned on by default, but you can disable it by setting its value to +{@code true}. We do not recommend doing so without a compelling reason.
+ +For more information, see +RELRO: +RELocation Read-Only and Security +enhancements in RedHat Enterprise Linux (section 6).
+ +By default, the build system compiles code with format string protection. Doing so forces a +compiler error if a non-constant format string is used in a {@code printf}-style function.
+This protection is off by default, but you can disable it by setting its value to +{@code true}. We do not recommend doing so without a compelling reason.
+ + +This variable records a set of C/C++ compiler flags to add to the {@code LOCAL_CFLAGS} definition +of any other module that uses this one via the {@code LOCAL_STATIC_LIBRARIES} or +{@code LOCAL_SHARED_LIBRARIES} variables.
+ +For example, consider the following pair of modules: {@code foo} and {@code bar}, which depends +on {@code foo}:
+ ++include $(CLEAR_VARS) +LOCAL_MODULE := foo +LOCAL_SRC_FILES := foo/foo.c +LOCAL_EXPORT_CFLAGS := -DFOO=1 +include $(BUILD_STATIC_LIBRARY) + + +include $(CLEAR_VARS) +LOCAL_MODULE := bar +LOCAL_SRC_FILES := bar.c +LOCAL_CFLAGS := -DBAR=2 +LOCAL_STATIC_LIBRARIES := foo +include $(BUILD_SHARED_LIBRARY) ++ +
Here, the build system passes the flags {@code -DFOO=1} and {@code -DBAR=2} to the compiler when +building {@code bar.c}. It also prepends exported flags to your your module's {@code LOCAL_CFLAGS} +so you can easily override them.
+ +In addition, the relationship among modules is transitive: If {@code zoo} depends on +{@code bar}, which in turn depends on {@code foo}, then {@code zoo} also inherits all flags +exported from {@code foo}. + +Finally, the build system does not use exported flags when building locally (i.e., building the +module whose flags it is exporting). Thus, in the example above, it does not pass {@code -DFOO=1} +to the compiler when building {@code foo/foo.c}. To build locally, use {@code LOCAL_CFLAGS} +instead.
+ +This variable is the same as {@code LOCAL_EXPORT_CFLAGS}, but for C++ flags only.
+ +This variable is the same as {@code LOCAL_EXPORT_CFLAGS}, but for C include paths. It is useful +in cases where, for example, {@code bar.c} needs to include headers from module {@code foo}.
+ +This variable is the same as {@code LOCAL_EXPORT_CFLAGS}, but for linker flags.
+ +This variable is the same as {@code LOCAL_EXPORT_CFLAGS}, telling the build system to pass names +of specific system libraries to the compiler. Prepend {@code -l} to the name of each library you +specify.
+ +Note that the build system appends imported linker flags to the value of your module's +{@code LOCAL_LDLIBS} variable. It does this due to the way Unix linkers work.
+ +This variable is typically useful when module {@code foo} is a static library +and has code that depends on a system library. You can then use {@code LOCAL_EXPORT_LDLIBS} to +to export the dependency. For example:
+ ++include $(CLEAR_VARS) +LOCAL_MODULE := foo +LOCAL_SRC_FILES := foo/foo.c +LOCAL_EXPORT_LDLIBS := -llog +include $(BUILD_STATIC_LIBRARY) + +include $(CLEAR_VARS) +LOCAL_MODULE := bar +LOCAL_SRC_FILES := bar.c +LOCAL_STATIC_LIBRARIES := foo +include $(BUILD_SHARED_LIBRARY) ++ +
In this example, the build system puts {@code -llog} at the end of the linker command when it +builds {@code libbar.so}. Doing so tells the linker that, because {@code libbar.so} depends +on {@code foo}, it also depends on the system logging library.
+ +Set this variable to {@code true} when your module has a very high +number of sources and/or dependent static or shared libraries. Doing so forces the +build system to use {@code @} syntax for archives containing intermediate object files +or linking libraries.
+ +This feature can be useful on Windows, where the command line accepts a maximum of only +of 8191 characters, which can be too small for complex projects. It also impacts the compilation of +individual source files, placing nearly all compiler flags inside list files, too.
+ +Note that any value other than {@code true} will revert to the +default behaviour. You can also define {@code APP_SHORT_COMMANDS} in your +{@code Application.mk} file to force this +behavior for all modules in your project.
+ +We do not recommend enabling this feature by default, since it makes the build slower.
+ + +Set this variable to {@code true} when building static libraries. +Doing so will generate a thin archive, a library file that does not contain +object files, but instead just file paths to the actual objects that it would normally +contain.
+This is useful to reduce the size of your build output. The drawback is that +such libraries cannot be moved to a different location (all paths +inside them are relative).
+Valid values are {@code true}, {@code false} or empty. A +default value can be set in your {@code Application.mk} file through the {@code APP_THIN_ARCHIVE} + +variable.
+Note: This is ignored for non-static library modules, or prebuilt +static library ones.
+ +Define this variable as a shell command that the build system will use to filter the +assembly files extracted or generated from the files you specified for {@code LOCAL_SRC_FILES}.
+Defining this variable causes the following things to occur:
+ +For example:
+ ++LOCAL_SRC_FILES := foo.c bar.S +LOCAL_FILTER_ASM := + +foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o +bar.S --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o ++ +
"1" corresponds to the compiler, "2" to the filter, and "3" to the assembler. The filter must +be a standalone shell command that takes the name of the input file as its first argument, and the +name of the output file as the second one. For example:
+ ++myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S +myasmfilter bar.S $OBJS_DIR/bar.S ++ +
This section explains GNU Make function macros that the NDK provides. Use +{@code $(call <function>)} to evaluate them; they return textual information.
+ +This macro returns the path of the last included makefile, which typically is the +current {@code Android.mk}'s directory. {@code my-dir} is useful for defining +{@code LOCAL_PATH} at the start of your {@code Android.mk} file. For example:
+ ++LOCAL_PATH := $(call my-dir) ++ +
Due to the way GNU Make works, what this macro really returns is the +path of the last makefile that the build system included when parsing the build scripts. For this +reason, you should not call {@code my-dir} after including another file.
+ +For example, consider the following example:
+ ++LOCAL_PATH := $(call my-dir) + +# ... declare one module + +include $(LOCAL_PATH)/foo/`Android.mk` + +LOCAL_PATH := $(call my-dir) + +# ... declare another module ++ +
The problem here is that the second call to {@code my-dir} defines +{@code LOCAL_PATH} as {@code $PATH/foo} instead of {@code $PATH}, because that was where its +most recent include pointed.
+ +You can avoid this problem by putting additional includes after everything +else in the {@code Android.mk} file. For example:
+ ++LOCAL_PATH := $(call my-dir) + +# ... declare one module + +LOCAL_PATH := $(call my-dir) + +# ... declare another module + +# extra includes at the end of the Android.mk file +include $(LOCAL_PATH)/foo/Android.mk + ++ +
If it is not feasible to structure the file in this way, save the value of the first +{@code my-dir} call into another variable. For example:
+ ++MY_LOCAL_PATH := $(call my-dir) + +LOCAL_PATH := $(MY_LOCAL_PATH) + +# ... declare one module + +include $(LOCAL_PATH)/foo/`Android.mk` + +LOCAL_PATH := $(MY_LOCAL_PATH) + +# ... declare another module ++ +
Returns the list of {@code Android.mk} files located in all subdirectories of +the current {@code my-dir} path. + +
You can use this function to provide deep-nested source directory hierarchies to the build +system. By default, the NDK only looks for files in the directory containing the +{@code Android.mk} file.
+ +Returns the path of the current makefile (from which the build system called the function).
+ +Returns the path of the parent makefile in the inclusion tree (the path of the makefile that +included the current one).
+ +Returns the path of the grandparent makefile in the inclusion tree (the path of the makefile that +included the current one).
+ +A function that allows you to find and include the {@code Android.mk} +of another module by name. A typical example is as follows:
+ ++$(call import-module,<name>) ++ +
In this example, the build system looks for the module tagged <name> in the list of +directories referenced that your {@code NDK_MODULE_PATH} environment variable references, and +includes its {@code Android.mk} file automatically for you.
+ +For more information, see Android Module Paths (Sharing Code). +
diff --git a/docs/html-ndk/ndk/guides/application_mk.jd b/docs/html-ndk/ndk/guides/application_mk.jd new file mode 100644 index 000000000000..be82fbe513dc --- /dev/null +++ b/docs/html-ndk/ndk/guides/application_mk.jd @@ -0,0 +1,241 @@ +page.title=Application.mk +@jd:body + + + +This document explains the syntax of the {@code Application.mk} build file, which describes the +native modules that your app requires. A module can be a static library, a shared library, +or an executable.
+ +We recommend that you read the Concepts and +Android.mk pages before this one. Doing so will +help maximize your understanding of the material on this page.
+ ++$NDK/apps/<myapp>/Application.mk ++ +
Here, {@code <myapp>} is a short name used to describe your app to the NDK build system. It +doesn't actually go into your generated shared libraries or your final packages.
+ +This variable stores the absolute path to your app's project-root directory. The build system +uses this information to place stripped-down versions of the generated JNI shared libraries +into a specific location known to the APK-generating tools.
+ +If you place your {@code Application.mk} file under {@code $NDK/apps/<myapp>/}, you must +define this variable. If you place it under {@code $PROJECT/jni/}, it is optional. + +
Define this optional variable as either {@code release} or {@code debug}. You use it to +alter the optimization level when building your application's modules.
+ +Release mode is the default, and generates highly optimized binaries. Debug mode generates +unoptimized binaries that are much easier to debug.
+ +Note that you can debug either release or debug binaries. Release binaries, however, provide less +information during debugging. For example, the build system optimizes out some variables, +preventing you from inspecting them. Also, code re-ordering can make it more difficult to step +through the code; stack traces may not be reliable.
+ +Declaring {@code android:debuggable} in your application manifest's {@code <application>} +tag will cause this variable to default to {@code debug} instead of {@code release}. Override this +default value by setting {@code APP_OPTIM} to {@code release}.
+ + +This variable stores a set of C compiler flags that the build system passes to the compiler +when compiling any C or C++ source code for any of the modules. You can use this variable to change +the build of a given module according to the application that needs it, instead of having to modify +the {@code Android.mk} file itself.
+ + +All paths in these flags should be relative to the top-level NDK directory. For example, if you +have the following setup:
+ ++sources/foo/Android.mk +sources/bar/Android.mk ++ +
To specify in {@code foo/Android.mk} that you want to add the path to the {@code bar} sources +during compilation, you should use: + +
+APP_CFLAGS += -Isources/bar ++ +
Or, alternatively:
+ ++APP_CFLAGS += -I$(LOCAL_PATH)/../bar ++ +
{@code -I../bar} will not work since it is equivalent to +{@code -I$NDK_ROOT/../bar}.
+ +Note: This variable only works on C, not C++, sources in +android-ndk-1.5_r1. In all versions after that one, {@code APP_CFLAGS} matches the full Android +build system.
+ +This variable contains a set of C++ compiler flags that the build system passes to the compiler +when building only C++ sources.
+ +Note: In android-ndk-1.5_r1, this variable works on both C and +C++ sources. In all subsequent versions of the NDK, {@code APP_CPPFLAGS} now matches the full +Android build system. For flags that apply to both C and C++ sources, use {@code APP_CFLAGS}.
+ +A set of linker flags that the build system passes when linking the application. This variable +is only relevant when the build system is building shared libraries and executables. When the +build system builds static libraries, it ignores these flags.
+ +By default, the NDK build system looks under {@code jni/} for a file named +{@code Android.mk}.
+ +If you want to override this behavior, you can define {@code APP_BUILD_SCRIPT} to point to an +alternate build script. The build system always interprets a non-absolute path as relative to the +NDK's top-level directory.
+ +By default, the NDK build system generates machine code for the +{@code armeabi} ABI. This machine code +corresponds to an ARMv5TE-based CPU with software floating point operations. You can use +{@code APP_ABI} to select a different ABI. Table 1 shows the {@code APP_ABI} +settings for different instruction sets.
+ + +Instruction set | +Value | +
---|---|
Hardware FPU instructions on ARMv7 based devices | +{@code APP_ABI := armeabi-v7a} | +
ARMv8 AArch64 | +{@code APP_ABI := arm64-v8a} | +
IA-32 | +{@code APP_ABI := x86} | +
Intel64 | +{@code APP_ABI := x86_64} | +
MIPS32 | +{@code APP_ABI := mips} | +
MIPS64 (r6) | +{@code APP_ABI := mips64} | +
All supported instruction sets | +{@code APP_ABI := all} | +
Note: {@code all} is available starting from NDKr7.
+ +You can also specify multiple values by placing them on the same line, delimited by spaces. +For example:
+ ++APP_ABI := armeabi armeabi-v7a x86 mips ++ +
For the list of all supported ABIs and details about their usage and limitations, refer to +Android Native CPU ABI Management.
+ +This variable contains the name of the target Android platform. For example, {@code android-3} +specifies the Android 1.5 system images. For a complete list of platform names and corresponding +Android system images, see Android NDK Stable APIs +.
+ +By default, the NDK build system provides C++ headers for the minimal C++ runtime library +({@code system/lib/libstdc++.so}) provided by the Android system. In addition, it comes with +alternative C++ implementations that you can use or link to in your own applications. +Use {@code APP_STL} to select one of them. Table 2 shows the {@code APP_STL} values to specify +support for different libraries.
+ + +Library | +Value | +
---|---|
Static STLport | +{@code APP_STL := stlport_static} | +
Shared STLport | +{@code APP_STL := stlport_shared} | +
Default C++ runtime | +{@code APP_STL := system} | +
For more information on this subject, see C++ +Support.
+ + +The equivalent of {@code LOCAL_SHORT_COMMANDS} in {@code Application.mk} for your whole project. +For more information, see the documentation for this variable on +{@code Android.mk}.
+ +Define this variable as either {@code 4.9} or {@code 4.8} to select a version of the GCC +compiler. Version 4.9 is the default for 64-bit ABIs, and 4.8 is the default for 32-bit ABIs. +To select a version of Clang, define this variable as {@code clang3.4}, {@code clang3.5}, or +{@code clang}. Specifying {@code clang} chooses the most recent version of Clang.
+ +Starting from Android 4.1 (API level 16), Android's dynamic linker supports position-independent +executables (PIE). Use the {@code -fPIE} flag to build them. This flag makes it harder to exploit +memory corruption bugs by randomizing code location. By default, {@code ndk-build} automatically +sets this value to {@code true} if your project targets {@code android-16} or higher. You may set +it manually to either {@code true} or {@code false}.
+ +This flag applies only to executables. It has no effect when building shared or static +libraries.
+ +Note: PIE executables cannot run on Android releases prior to 4.1. +
This restriction only applies to executables. It has no effect when building shared or static +libraries.
+ +Sets the default value of {@code LOCAL_THIN_ARCHIVE} in the {@code Android.mk} file for all +static library modules in this project. For more information, see the documentation for +{@code LOCAL_THIN_ARCHIVE} on {@code Android.mk}. +
diff --git a/docs/html-ndk/ndk/guides/arch.jd b/docs/html-ndk/ndk/guides/arch.jd new file mode 100644 index 000000000000..875bbd90f5ea --- /dev/null +++ b/docs/html-ndk/ndk/guides/arch.jd @@ -0,0 +1,31 @@ +page.title=Architectures and CPUs +@jd:body + +This section includes detailed information about ABIs and detailed information on support for respective instruction sets. It includes these topics:
+This section explains, in detail, how to use the NDK to build your project. It comprises the following topics:
+This guide assumes that you are:
+This section provides a high-level explanation of how the NDK works. The Android NDK is a set of +tools allowing you to embed C or C++ (ânative codeâ) into your Android apps. The ability to use +native code in Android apps can be particularly useful to developers who wish to do one or more of +the following:
+This section introduces the main components used in building a native application for Android, +and goes on to describe the process of building and packaging.
+You should have an understanding of the following components as you build your app:
+For more information, see the +ndk-build section of this guide.
+When developing Java components, use the {@code native} keyword to indicate methods implemented +as native code. For example, the following function declaration tells the compiler that the +implementation is in a native library:
+ + + ++public native int add(int x, int y); ++
Note: If two libraries implement respective methods with the same +signature, a link error occurs. In C, "signature" means method name only. In C++, "signature" means +not only method name, but also its argument names and types.
+The following two items only apply in cases in which you are using the toolchains provided with +the Android NDK as standalone compilers.
+ +For more information, see the +Application.mk section.
+The general flow for developing a native app for Android is as follows:
+Note: While it is possible to completely avoid Java, you are likely +to find the Android Java framework useful for tasks including controlling the display and UI.
+Note that Eclipse can perform steps 7. through 9. in a single operation.
+ +The Android SDK provides a helper class, {@link android.app.NativeActivity}, that allows you to +write a completely native activity. {@link android.app.NativeActivity} handles the communication +between the Android framework and your native code, so you do not have to subclass it or call its +methods. All you need to do is declare your application to be native in your +{@code AndroidManifest.xml} file, and begin creating your native application.
+ +An Android application using {@link android.app.NativeActivity} still runs in its own virtual +machine, sandboxed from other applications. You can therefore still access Android framework APIs +through the JNI. In certain cases, however–such as for sensors, input events, and +assets–the NDK provides native interfaces that you can use instead of having to call +across the JNI. For more information about such support, see +Stable APIs.
+ +Regardless of whether or not you are developing a native activity, we recommend that you create +your projects with the traditional Android build tools. Doing so helps ensure building and packaging +of Android applications with the correct structure.
+ +The Android NDK provides you with two choices to implement your native activity:
+ +The {@code <ndk_root>/sources/android/native_app_glue/android_native_app_glue.c} source is +also available, allowing you to modify the implementation.
+For more information on how to use this static library, examine the native-activity sample +application and its documentation. Further reading is also available in the comments in the {@code <ndk_root>/sources/android/native_app_glue/android_native_app_glue.h} file.
+ +To implement a native activity with the {@code native-activity.h} interface:
+ +Because your application has no Java code, set {@code android:hasCode} to {@code false}.
+ ++<application android:label="@string/app_name" android:hasCode="false"> ++ +
You must set the {@code android:name} attribute of the activity tag to +{@link android.app.NativeActivity}.
+ ++<activity android:name="android.app.NativeActivity" + android:label="@string/app_name"> ++
Note: You can subclass {@link android.app.NativeActivity}. If you +do, use the name of the subclass instead of {@link android.app.NativeActivity}.
+The {@code android:value} attribute of the {@code meta-data} tag specifies the name of the shared +library containing the entry point to the application (such as C/C++ {@code main}), omitting the +{@code lib} prefix and {@code .so} suffix from the library name.
+ ++ <meta-data android:name="android.app.lib_name" + android:value="native-activity" /> + <intent-filter> + <action android:name="android.intent.action.MAIN" /> + <category android:name="android.intent.category.LAUNCHER" /> + </intent-filter> + </activity> + </application> + </manifest> ++ +
+$ cd <path>/<to>/<project> +$ <ndk>/ndk-build ++ +
You can find further information on using {@code native-activity.h} here.
+ + + diff --git a/docs/html-ndk/ndk/guides/cpp-support.jd b/docs/html-ndk/ndk/guides/cpp-support.jd new file mode 100644 index 000000000000..60541815ff28 --- /dev/null +++ b/docs/html-ndk/ndk/guides/cpp-support.jd @@ -0,0 +1,328 @@ +page.title=C++ Library Support +@jd:body + +The Android platform provides a very minimal C++ runtime support library ({@code libstdc++}). +This minimal support does not include, for example:
+ +The NDK provides headers for use with this default library. In addition, the NDK provides a +number of helper runtimes that provide additional features. This page provides information about +these helper runtimes, their characteristics, and how to use them. +
+ +Table 1 provides names, brief explanations, and features of runtimes available inthe NDK.
+ + + +Name | +Explanation> + | Features + |
---|---|---|
{@code libstdc++} (default) | +The default minimal system C++ runtime library. | +N/A | +
{@code gabi++_static} | +The GAbi++ runtime (static). | +C++ Exceptions and RTTI | +
{@code gabi++_shared} | +The GAbi++ runtime (shared). | +C++ Exceptions and RTTI | +
{@code stlport_static} | +The STLport runtime (static). | +C++ Exceptions and RTTI; Standard Library | +
{@code stlport_shared} | +The STLport runtime (shared). | +C++ Exceptions and RTTI; Standard Library | +
{@code gnustl_static} | +The GNU STL (static). | +C++ Exceptions and RTTI; Standard Library | +
{@code gnustl_shared} | +The GNU STL (shared). | +C++ Exceptions and RTTI; Standard Library | +
{@code c++_static} | +The LLVM libc++ runtime (static). | +C++ Exceptions and RTTI; Standard Library | +
{@code c++_shared} | +The LLVM libc++ runtime (shared). | +C++ Exceptions and RTTI; Standard Library | +
Use the {@code APP_STL} variable in your +{@code Application.mk} file to specify the runtime you wish to use. Use the values in +the "Name" column in Table 1 as your setting. For example:
+ ++APP_STL := gnustl_static ++ +
You may only select one runtime for your app, and can only do in +{@code Application.mk}.
+ +Even if you do not use the NDK build system, you can still use STLport, libc++ or GNU STL. +For more information on how to use these runtimes with your own toolchain, see Standalone Toolchain.
+ +This runtime only provides the following headers, with no support beyond them:
+This runtime provides the same headers as the default runtime, but adds support for RTTI +(RunTime Type Information) and exception handling.
+ + +This runtime is an Android port of STLport +(http://www.stlport.org). It provides a complete set of C++ +standard library headers. It also, by embedding its own instance of GAbi++, provides support for +RTTI and exception handling.
+ +While shared and static versions of this runtime are avilable, we recommend using the shared +version. For more information, see Static runtimes.
+ +The shared library file is named {@code libstlport_shared.so} instead of {@code libstdc++.so} +as is common on other platforms.
+ +In addition to the static- and shared-library options, you can also force the NDK to +build the library from sources by adding the following line to your {@code Application.mk} +file, or setting it in your environment prior to building:
+ ++STLPORT_FORCE_REBUILD := true ++ + +
This runtime is the GNU Standard C++ Library, ({@code libstdc++-v3}). Its shared library file is +named {@code libgnustl_shared.so}.
+ + +This runtime is an Android port of LLVM libc++. Its +shared library file is named {@code libc++_shared.so}.
+ +By default, this runtime compiles with {@code -std=c++11}. As with GNU {@code libstdc++}, you +need to explicitly turns on exceptions or rtti support. For information on how to do this, see +C++ Exceptions and RTTI.
+ +The NDK provides prebuilt static and shared libraries for {@code libc++} compiled by Clang 3.4, +but you can force the NDK to rebuild {@code libc++} from sources by adding the following line to +your {@code Application.mk} file, or setting it in your environment prior to building:
+ ++LIBCXX_FORCE_REBUILD := true ++ +
If you include {@code <atomic>}, it's likely that you also need {@code libatomic}. +If you are using {@code ndk-build}, add the following line:
+ ++LOCAL_LDLIBS += -latomic ++ +
If you are using your own toolchain, use:
+ ++-latomic ++ +
Note: {@code -latomic} is only available for GCC 4.8. +Because Clang 3.5 and Clang 3.6 use GCC 4.8's headers and libraries, as well as its +{@code as} and {@code ld} options, those versions of Clang also get {@code -latomic}.
+ + +Around 99% of tests pass when compiling {@code libc++} with Clang 3.4 for all supported ABIs. +The failures are mostly in the areas of {@code wchar_t} and locales that Android bionic +doesn't support. Switching locale from the default produces the following warning in +{@code logcat}:
+ ++newlocale() WARNING: Trying to set locale to en_US.UTF-8 other than "", "C" or "POSIX" ++ +
We do not recommend using {@code libc++} with GCC 4.6 because of GCC 4.6's limited c++11 +support.
+ +For information on {@code libc++} tests that fail to compile, {@code black_list*} in +{@code $NDK/tests/device/test-libc++-shared-full/jni/Android.mk}. For information about tests +that fail to run correctly, see {@code $NDK/tests/device/test-libc++-shared-full/BROKEN_RUN}. +{@code $NDK}, here, is the your NDK installation's root directory.
+ + +In all versions of the NDK later than NDKr5, the NDK toolchain allows you to use C++ runtimes +that support exception handling. However, to ensure compatibility with earlier releases, it +compiles all C++ sources with {@code -fno-exceptions} support by default. You can enable C++ +exceptions either for your entire app, or for individual modules. + +
To enable exception-handling support for your entire app, add the following line to +your {@code Application.mk} file. +To enable exception-handling support for individual modules', add the following line to +their respective {@code Android.mk} files.
+ ++APP_CPPFLAGS += -fexceptions ++ +
In all versions of the NDK later than NDKr5, the NDK toolchain allows you to use C++ runtimes +that support RTTI. However, to ensure compatibility with earlier releases, it compiles all C++ +sources with {@code -fno-rtti} by default. + +
To enable RTTI support for your entire app for your entire application, add the following line to +your {@code Application.mk} file: + +
+APP_CPPFLAGS += -frtti ++ +To enable RTTI support for individual modules, add the following line to +their respective {@code Android.mk} files: + +
+LOCAL_CPP_FEATURES += rtti ++ +Alternatively, you can use: + +
+LOCAL_CPPFLAGS += -frtti ++ +
Linking the static library variant of a C++ runtime to more than one binary may result in +unexpected behavior. For example, you may experience:
+ +In addition, if you link two shared libraries–or a shared library and an executable– +against the same static runtime, the final binary image of each shared library includes a copy of +the runtime's code. Having multiple instances of runtime code is problematic because of duplication +of certain global variables that the runtime uses or provides internally.
+ +This problem does not apply to a project comprising a single shared library. For example, +you can link against {@code stlport_static}, and expect your app to behave correctly. If your +project requires several shared library modules, we recommend that you use the shared library +variant of your C++ runtime.
+ +If your app targets a version of Android earlier than Android 4.3 (Android API level 18), +and you use the shared library variant of a given C++ runtime, you must load the shared library +before any other library that depends on it.
+ +For example, an app may have the following modules:
+ +You must need to load the libraries in reverse dependency order:
++ static { + System.loadLibrary("stlport_shared"); + System.loadLibrary("bar"); + System.loadLibrary("foo"); + } ++ +
Note: Do not use the {@code lib} prefix when calling +{@code System.loadLibrary()}.
+ +STLport is licensed under a BSD-style open-source license. See +{@code $NDK/sources/cxx-stl/stlport/README} for more details about STLport.
+ +GNU libstdc++ is covered by the GPLv3 license, and not the LGPLv2 or LGPLv3. For +more information, see +License on the GCC website.
+ +LLVM {@code libc++} +is dual-licensed under both the University of Illinois "BSD-Like" license and the MIT license.
\ No newline at end of file diff --git a/docs/html-ndk/ndk/guides/cpu-arm-neon.jd b/docs/html-ndk/ndk/guides/cpu-arm-neon.jd new file mode 100644 index 000000000000..32e9942b8e7c --- /dev/null +++ b/docs/html-ndk/ndk/guides/cpu-arm-neon.jd @@ -0,0 +1,109 @@ +page.title=NEON Support +@jd:body + +The NDK supports the ARM Advanced SIMD, an optional instruction-set extension of the ARMv7 spec. +NEON provides a set of scalar/vector instructions and registers (shared with the FPU) comparable to +MMX/SSE/3DNow! in the x86 world. To function, it requires VFPv3-D32 (32 hardware FPU 64-bit +registers, instead of the minimum of 16).
+ +The NDK supports the compilation of modules or even specific source files with support for NEON. +As a result, a specific compiler flag enables the use of GCC ARM NEON intrinsics and VFPv3-D32 +at the same time.
+ +Not all ARMv7-based Android devices support NEON, but devices that do may benefit significantly
+from its support for scalar/vector instructions. For x86 devices, the NDK can also translate NEON
+instructions into SSE, although with several restrictions. For more information, see
+Using LOCAL_ARM_NEON
+ To have the NDK build all its source files with NEON support, include the following line in
+your module definition: It can be especially useful to build all source files with NEON support if you want to build a
+static or shared library that specifically contains NEON code paths. When listing source files for your {@code LOCAL_SRC_FILES} variable, you have the option of
+using the {@code .neon} suffix to indicate that you want to build binaries with NEON support.
+For example, the following example builds one file with {@code .neon} support, and another
+without it: You can combine the {@code .neon} suffix with the {@code .arm} suffix, which specifies the 32-bit
+ARM instruction set for non-NEON instructions. In such a definition, {@code arm} must come before
+{@code neon}. For example: {@code foo.c.arm.neon} works, but {@code foo.c.neon.arm} does not. NEON support only works with the {@code armeabi-v7a} and {@code x86} ABIs. If the NDK build
+scripts encounter other ABIs while attempting to build with NEON support, the NDK build scripts
+exit. x86 provides partial NEON support via translation header. It is
+important to use checks like the following in your
+{@code Android.mk} file: Your app must perform runtime detection to confirm that NEON-capable machine code can be run on
+the target device. This is because not all ARMv7-based Android devices support NEON. The app can
+perform this check using the
+{@code cpufeatures} library that comes with
+this NDK. You should explicitly check that {@code android_getCpuFamily()} returns {@code
+ANDROID_CPU_FAMILY_ARM}, and that {@code android_getCpuFeatures()} returns a value including the
+{@code ANDROID_CPU_ARM_FEATURE_NEON flag} set. For example: The source code for the NDK's hello-neon sample provides an example of how to use the
+{@code cpufeatures} library and NEON intrinsics at the same time. This sample implements a tiny
+benchmark for a FIR filter loop using a C version, and a NEON-optimized one for devices that
+support it. The NDK provides a small library named {@code cpufeatures} that your app can use at runtime to
+detect the target device's CPU family and the optional features it supports. It is designed to work
+as-is on all official Android platform versions. The {@code cpufeatures} library is available as an import module. To use it, follow the procedure
+below: Here is a simple example of an {@code Android.mk} file that imports the {@code cpufeatures}
+library: The {@code cpufeatures} library provides two functions. The first function returns the family to
+which the device's CPU belongs. Declare it as follows: The function returns one of the following enums, representing the CPU family/architecture that
+the device supports. For a 32-bit executable on a 64-bit system, this function returns only the 32-bit value. The second function returns the set of optional features that the device's CPU supports. Declare
+it as follows:
+
+ The return value takes the form of a set of bit flags, each flag representing one
+CPU-family-specific feature. The rest of this section provides information on features for
+the respective families. The following flags are available for the 32-bit ARM CPU family: This value is equivalent to the {@code VFPv3-D16} instruction set, which provides provides only
+16 hardware double-precision FP registers. The following flags are available for the 64-bit ARM CPU family: The following flags are available for the 32-bit x86 CPU family.
+ {@code android_getCpuFeatures()} returns {@code 0} for CPU families for which there are no
+listed extensions. The following function returns the maximum number of CPU cores on the target device: For the complete change history of this library, see the comments in
+{@code $NDK/sources/android/cpufeatures/cpu-features.c}, where {@code $NDK} is the root of your
+NDK installation.
+LOCAL_ARM_NEON := true
+
+
+Using the .neon Suffix
+
+LOCAL_SRC_FILES := foo.c.neon bar.c
+
+
+Build Requirements
+
+# define a static library containing our NEON code
+ifeq ($(TARGET_ARCH_ABI),$(filter $(TARGET_ARCH_ABI), armeabi-v7a x86))
+include $(CLEAR_VARS)
+LOCAL_MODULE := mylib-neon
+LOCAL_SRC_FILES := mylib-neon.c
+LOCAL_ARM_NEON := true
+include $(BUILD_STATIC_LIBRARY)
+endif # TARGET_ARCH_ABI == armeabi-v7a || x86
+
+
+Runtime Detection
+
+#include <cpu-features.h>
+...
+...
+if (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM &&
+ (android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON) != 0)
+{
+ // use NEON-optimized routines
+ ...
+}
+else
+{
+ // use non-NEON fallback routines instead
+ ...
+}
+
+...
+
+
+Sample Code
+On this page
+
+
+
+ Usage
+
+
+
+
+LOCAL_STATIC_LIBRARIES := cpufeatures
+
+
+$(call import-module,android/cpufeatures)
+
+
+
+<project-path>/jni/Android.mk:
+LOCAL_PATH := $(call my-dir)
+
+include $(CLEAR_VARS)
+LOCAL_MODULE := <your-module-name>
+LOCAL_SRC_FILES := <your-source-files>
+LOCAL_STATIC_LIBRARIES := cpufeatures
+include $(BUILD_SHARED_LIBRARY)
+
+$(call import-module,android/cpufeatures)
+
+Functions
+
+AndroidCpuFamily android_getCpuFamily();
+
+
+
+
+
+
+uint64_t android_getCpuFeatures();
+
+
+32-bit ARM CPU family
+
+
+
+
+64-bit ARM CPU family
+
+
+
+
+32-bit x86 CPU family
+
+
+
+
+
+int android_getCpuCount(void);
+
+
+MIPS CPU family
+
+
+
+
+Change History
+
This section introduces you to debugging with the NDK. It includes:
+ndk-gdb
, which allows you to launch a native debugging session for your NDK-generated machine code.logcat
in your debugging. DiE;;r&VsjtM3->+w%BrKT=m%B`(EP!MIHFiy_r&Ul_Haj%!p6 znq#dwns-`zcz^F&D$}EPnqCJ<(@hZ$@awq}6Cs!K$1G**<+mXH+WG#5a4g4}uIh$! z_nzbZo;K3wIS&$hg$b#kmddpS0R2|lBG@XNw@gH<%u!Pc>u;P>f|+)~24KEWDN$`n zsiCqJ&lE4-B3A`X8Qgqoz9J~J%Bp(7moup^xO!Qip*J>`GUIDp>uHdjorUp_qQN=`xo;XDlC%OdYaT#>ecj z?f;AxydU-|ecm@*#E_?x`5;R7{j%4Ll-JlW5U&j?T(qT~)%o%1clZ4N>^Cs}N)YuB zUXM@v^B aQNwn&iZUG?8j4*>E?Xv!Bj!rL410 z3t$kCWI;fr42A%nU7j9j|Kx-9r<;qD3j;xnEdu$&Em|J}(GT@^|3vai`^^Wd_xoXi z0@<{-uh7%@(}p@IM-=@Vr#4LdXl#RN{DZe!`oocTOHE_=R#Q4zpj1}1aU^l` yu;0{A4@sGl`&a+VH%6|2UXX( z+iKCo(ei^eVLT6W>9R*!+L&4s6Cyly64JH7jYAjMY_MD(yhV65EO`o921p&(906K` zP#wP42r^U3tcpC`A?-_s9+c$O?d)E#iKCYffFPYPR|D=5?;!3<5T!D>{0c)LzM(1b zf8+Ub%*&f@i0HBH$+4~ufa{`GQ2Yfot4OKrqhze%%98 mZy`nxBG z&{s_!Cei>X*wLpPii?QrN!nc(Q|yh95=BdSpBJY1PE;b1bypSsvZ8DnPP}L6dEZDo zYZ8&Eu|-KbHp|=@C0rK%2PYZR?2yR;SV)AQg_c>Idi|jxF5@0rK9-pJEmInj@r-@q zOQ#YFij;!g%KT)qo31h+CRt|Q4e-JW&eHcIq(6U^=kq;%4v_<2jt(#GXIj_dK)hL9 z&}3vz{P&(xo ?S6m1qsOX0c>OA_O;Ba(izmj*us3Xt?i4^;w0q~+DyX}P`;^PRNg!Cye zm00dzqcyl{nhV+{=jQ0S+OtBe+Yg+vhKQ@b(*KM>u(Y JNbL} !Fra}7hC$N`;$Af7@lD;Lm z{PB_O1@op{g)T_$aqoT8Rz#gt&~UP+=n^sn5~CZPi0|m`v0< RbJF!bgca0$hbpf w@|LCTsEaX(R?B4vIS-h$slpZcPJ zyksDA-xUlCrgVb33QEQI*HwP|*Vf9 fuMXeUhL#@Q zZ}Hx5hQ4j#bvH#B!ULHI?=tu(dfxWUfnMt3&?3~jd#E;jSNvPx-7r_J*>BagN%}0) z1X!qlt@VNV<^ebnr?;*~DDo-Dj$;DRi2Pb_%@ cjRp7wO0m{U0 zb&Jx?jgrW4{k=%kp~Nj);n_LWi#3 JI|rUtlCkKP2aE3^xml z@88qNEH$#wv3rTIXkeZ(d3~r8lQA-fw{Ns=*fZd>3dY5t%K153^QhU|q6CTYQsF+F zUOP#qL#~*fo)I7MmW|+v5&{mQ=Nmp^jnL7OlmJLdGzsMlba}rr o|txZh5AcQBBOHi@Q9J4hue4(eZjg~-aHp1MyT`E z=Z53v5G!Fdh1KMsh#1UMoVK_nM~xH63?}>A>oS)v0~L?_%!N&R!d+J|_ji S ziX1IbI=8obwP0E;Toy^2PNf|zS2#n<#+6#EG`#oeJPjHp Xs`WRUZy~2l>9loPQ5$h VgS+`+M}#N%Sfpum(^F6B2~G;Yhra{bz4-_mBLBswRKuSrYa zqVd+P(0da8iRU`stYV)W1M{p_qIsDq{~F4F1A|fJ<3?X!VNH#lr)E7t+O56Nv&wzm z5xg~=!aL`Ra`_({B;8mebORRr;Zcg-N|c(dk2iWg(~tdx$0WiEWSFQG)aILeKZ!*# zmFF!lqoDLOXU6`DJE`9k^WBX9j0x4^l)sKjUDH}Om9anwybTkWX2mmZ_|HK9F@JCZ zV`GI_uD)^iFwuXlu^ynf`Ie%0hxnx#*x1yRHBKB49Jf^Z$kuUY%;+j+!Jho2 0IEmDd<~MV>lW
M~xRUHjbS4OcDNr(0#1!V0Hv53_}G zTeoLuendoxLdyLyi%U2($y^Wxt*V7@6zTm_#l|nLWeI_n(_PoJII%KmdYK2G(N|*E zWi^;g1m4oO-Qlto)zyDD$$c;n``UOenU?y6%ISQP*&gfp%%G=iNgrtMvfXC9x8HTf zcPJYVErF? Wn61ofL-RMY7j9XFb)i8Qp$@IT>bm0{XpW7((-pDMD(4yHD&p zuWEbs(%DTA*+*7x2U5GbuV5xaX@vN!hWAh
+^F-otZah_R1t( zjw0LvnQC+T@u$zTKmF)z224W-K%E99R%erD&cv>$r#?3*pg_T8qR-?xC0FewPwAf! z{ICKSU;Zjs&42j>EU3Ld%f@oK`vs#_TN4RsWPM%>Z{h1xR>gDde}-au6|UW2Ycf9N zA@uW~?#tUEC#*7Zfy>8jp;EG`X#Tx#19-Mr+#tzu|Jp}044!yBW}pih+{;${HjD>< z%McCc%L+VjzYtqv;4;KX`81&^pWIT!@i-}tM~>tOH8 CWIIqX@> z=I@{H-7xN&4*p*NXcm|0n6r-Q$25*JxXg3A5Az1HwM+{2kLsZ5+%u RfKhKEubsXB*ju_Z3H5sf|RZkIB9U~hzgc$)ZKM?-yrimh)cGj$5E)isfA z1ZHl)9BOGOkFvR0s>q{vX#Z^|&0LHy*71@EK^zSLcVo|c_e9ybPa=rX-eWDrA*zn| zS1$&;48dT1pPFrZd49B`Rxxu)^`p0QIw_Z|kL!md?=>=hX83*mM*d2E=M3ZbesFYZ zMtV|Rg-RfB*yuwCv<;8#XeJKJ=3+=>!0$&s*flan|Mc^-jQSuIvuGZZ%3^_0zfavw z6O&l 6V{>))!vW!dY6bRN~z bdUT}ug$=RQ-6-+6;&|K4vR RB-FRFkc{+M7~DDe@opBQ<+NeIbv;WAN2qheX|Upoo?B(AgZd3Peusc~ zy7*mJQv(-&>t1=Co2JcV-CftnXp`99$eU)Rjg>ZbajQdeb&dJyA$^l;367rQ2;!u3 z6G8f{FJJ(_&mkN&=XeB}cejdIHF)YsEv84dCerL&WxP`ude%-;YZ^rDWV-}AUiEke z_?fU>>1Sr`-gEaoWNAsP(y$PbP{{H!81i7toe2=EqUtc-0 z%I_b&^6%IF;+@tokbddKzp1>k-vC*`7 gpKYo1mjUOuS zy{vs)<$#@kZMgC0mI0QgS7fs^t`5(}`WcY3s 1e1gvD)8!^Q{` ^ zEt9f~LZpwu^MCrnB_><84`qH V zmrVB>4u;!fmXSAJemyVfjPWH5
!IRtB8F(qO=d{0yTnqA1}XqczBeRl`SqVDx#{|I@h&76(ESEh6A#Q z`_oT =Ep62I$reHGI)Na>9cq_l z$xE_KV-ndcjOGXDmPYbz{m4MQ=MShmC9JLhYxE+rckfR5W@ZbJ-?s`~17!C+T4>pT zKs3%9l{_<$OfPVSW6#nVK|B$FegS$1=p&$~tnU6qq2}e~&CSjI!2APh1of_e`Rdm5 zJD;z78Iv?U{Pvex=8Ge^*!1GclCmWPY42#3Z7eg`nOnBYc5#nhk&LHZD;F*+u0Tz<*m4t7O^N3;)cK(V}ps0jqoGnBo(Pr~RI zEg*BFL(!4Z{mhAHmEY-Wdq7ej!zPZK+Enm+T NJ&2!OIB0(!@KerM1b zwY9b1Z&CLIpDkK@{}GwO{H~sWdKC}4{{ZVFml-tr *&8mXb4wgW<;n}HKkwoweF(A_zAi#KuH+~(Kt`&4gG5N7t~g}WQ{)4f4~T^nz9 z6C#6w34h1c`|Uk}zH3=#Z+b_{GE|gFkrj)5`*wY?Gp|c_i#{h#roUr*RcWL ^ zy&9$$=fNnUC-uPI{U4t`FT!W--L>mhZubJEst7N8_g8*gG&lxcH2U<@9j-xf8$2nF zy?FP2gR_$pBqk`2iQj8#YZliDBI^9o%70}U@wYIcEw7eZT4nax(uxM9sb(+J*0o&~ z-3*M86-Dk9#q5PF@U;T!{lWMhu8;hl{Lba{ojGk*VXf^^jE#?q @XkyJV} N*8DoZBG1ED;Ck{JjttNYU);;e)<>xTj8SNeu_mQ?M2v-!B0m3iM z>*97d0?zh!umnmkv!g0|KJHoll_mWx3Ki8j+IBBgf~;t%*~wO69sQ_r61jcJ%}?ui z-^5oVoOlPd{uyLutZV;nOG<)Wl>9~R*l3$H4s!Hg|DGo$D&E`WWpCYn*CMn^mOL{% zyWwkEnq%77L|uUV4rPl3^o|YuUR_;1J3BkGCiBb4>Eo&(r@pq~EUPyvKJK)p({z8< z=f@7A@wiJ4QLLWE*!%ZP9Q|- k0Ib@%VbNRdm{WC#|24oHw$;-Z z<@K0pU%#$vjunaQ^tB7!)q^TY$#$w)a(>68yPWn)WKyVU&gTLv@bw{ft{E8BogXo2 z9dGY4?ay*^&%qx#y^qACtGv6LGmxcWkWC!yN%gbP@u@I4dZuKMe$Gs%+*5PSCUc;- zkG#$q1-~cM6Tt~4I-V^Un6o;4X_|1?ErTp>@D1&nb+o!{ZK5@@h_n`^hJ=MhBo{37 zr`kl-&JV=ehmySP%n@YV)hZGbV2NHvyzQ-e15MM3EA`&S?W_DgcI{%yiBDedNKGC? zRy5SCfoh(RWSdMd-S^@l3%~WBaIAxRk5m@W(9@@vxgT&1&8_JnXP-ZE(P!r|yP2No zyK 1J8RnLW8A=BVpn@R*RwBLn%U^> z2~Nqp8k`~>VK^HfcMFc2n3xz7izX%}MWdq0iHXtC2WkQJKFsf1`FxY7r)O+z?DX{N zZwz(SlMl1=#!u(Ek(EzaM8LHU`qa0YW6G^W`&cx6H36`)`Bc`^JbpiY+=yOzUe%&N z@3iVr*^M(s!PoUHWc;qDU3BrBS2e{$Yj=Ts6UTuPUlr?cK9in*MfGwqxyH-zYSDn5 zo|aH{Rk()Dxpp}ZzkW|gLz|NK-`GKGjW)bit#j(Ud~-+3au3xto6LcJ>_&diUFG*k zyGvsT0tW0;gMrTB^v*!rXzZMwwNH%4xwzJm#o3uDATzU5eTmNL^rap@hb)e*zVZA} zjDb@+CeRx2yO+IHpTAKU1qrk~(xX@q1=!Xq5*h3GIqL6A$g+;QJy03G{%0`uzJ9@} zHSxS_RG#t^zVDzmw1S8SVvd} Nx1Kz;moAu8~J_f*GFEze!Zzl)|X`a1CzR962q)7 zMcEpf0*$q$3AL{(?%rjWV8tzng;QsYl*OHnsD%4pcMZ!Z@OIEMx^r~*TQ>r3YT5Xc z^S#b!fuAi0aEr)IcQ =-|#gxmuDm;#_m3C42cQKmI&w_8~DAfv`iwAh#wR%>IKKK@rmi_DXCN{8K0Px zi~+@@bV4#QDc4EI$0ujy0kKFlDV2)EW6~K}%GkJ6rXH7o{}U4N6fh+M2B$>p?1LIX zy^o#WfwZ)=D5AQW8uWsg@S<`TEn9KPEuZvs{m{0|D35~50!#aNMV>DX>8ue0LCrY< z{I}E9N_KV!zqD;MZ-J bmXOI}Lv01AgyWS^46XJ;iB(wJjoR>+8?b z{QGuWAL*7$OKK!N!4I~rGP|fCKPj ~SY|Q+-O-h4;=He){R5X%My1 z@4IW%IDsVko;rN|SVF_Fq0S}9?~e(+gXC*PRM)J5_ #05yTS# z=og@OfIb3xin7<>hwzmZmASdOdAWH%3_x9=Mo{k$wtuAbs=aMq)5hDa-(i+qaeG#N zY&~z#IseERd}PaS<3fI41Cc;3=_KDQrg-L4As`?g2Iw82kAR-?Ft`4YfcpbOe*az+ zPb6c9$UTD)5D=RH^bR8N$FaW{ `4snV)a zps6fxU=3BAIB}XHo>vsnIJvq~ZJb(f>fo+xXO9R521X{nc>YDlfCOZQbK=;sHimST zH&|01kx EJ$vJK4x7{2(b %_&_XR9ObI+c|6^_Z;{=gb4hKj%ul`{x3d(Oya784cNK5eBg zd%1_|!BgOP_Jqn5E-^^HyT~)f?*J?&3qOP(!VN({KtOCE0I>ji`5JQnZv4(*FxG<8 z L#;{R(IdX`%$rr2vSs(0}?3BrM{8LQ4y=-_xi$w8`rO=mNn8EOWcEF8f%)D zM+bX(a}&(g+wny!<79VN*G7_fVPpU(pGkg)fPjE_Quu!BXO?h%15eZKQONHQ5D<{x z;rd9(?+_3WKW={icKZWM_>Y`+`7X;NSDyHCO33dJ5D-72@w=+(u?P8j69T?%XD)uE zfl1ZlCf~RbL1D3MT0c4`>U&)no*I7Vad{6ZIRe25XEl`zTPg$u#1F^svi*SxEv_Dp zjyKb6P0WGD*4mPU&cEoW>lN3=uS`8_Z1KTcyOt0{?bw$VHrgpw! iB=e;g|F58dbH(p6BCI;3W}~g5 z!b1@KJ%7LKeD3_c@~4g8IqmtW`E5fWP@9v~+)rCwCeIVziSQHh9w2cVI@iMb%Kexa z)(F!tES9?^-#2G?WSC3q%FOJb!ln-a0r~xrqN}Mf(v%mOTi~o^$IrYPR9dQir=}(+ zIHxe(+$q&o-)Ip*?z{N#IK@tWL ;2$a3JYopsB^z9fH9BOa zxPKdb*(> 3n?;h1TC*S6k(LE0WFO!TtaN@hssxJm2)t z{ESwr=MhuSJ3HR`0z_Xzp=J@p{rHJ10p4$ZVoWRw{o 5JzW}z_R5_`qQrVdA=)2RbJEp}EHS*`IN z{!PT{u+UnDy}7 7gus=XR!14Q}kArn=QT?~tANUdT<(sKj zzUhYUR}=j|@GSgR@q3iVHT*!;3m<7Q+Y+M6n>4j;bKPxfsgjE~Ja1T9G!C(?O$-J| zBr=&=6YO3|7>V-mQSf`LhgDwd0G>$Zu-V*U;dvVa9Ij8(!G+lpZR?ju7#bQT*1G%E z5~`!ZYH1216e`R8g8ztkG{{b~5 L`#%mMAR?fmbeVuiC@nDoB_tK;n9|ZxBR7x|5KvJ%1f;ur6OfM44Wnzo z7`2U!?TfE?f8L+p_xs21+&p-kbGG|F_qqCdUe_XYv{dLWvt1@5BcoGOefElsjAEON zj9mEAh4VXR%Ed)wWJNV<&lFyJ&+MMz{TL^wNwI^F@-n1fK 2d3AsWvLsPgW*a z9?QOPw1NcJPDSwbJ5Rr5iriDm3Mi{lUitEH`Z2jhd%#8jzq-T3yNQoUlXFm8I!TS) zwouxA>1Uei{ f0LZ+|t^GGh(v6!|baYD71=RNWN9=xd}R~KOrk$?*d zB0u53)V8?Db9XUrt^8u2thUqV a@AC z!To;?Kp&2JrCM$5`h^;u`6Q(YhRfiyA^-^wGa{ZLcwQa^-F%E^jDKaW-frvX*EGAk z(CCTuwf`Jg=H%pbdQeQc3;K2CF*|&MIluycHq${m4(I)(&JFS0T^`7o`Y=E@gC1hr zLLx^uo|-w`EiRvknpkOY->81zD9l5iG^6zn##@pVAGlXNKh`*kl1JV+F!J2BEg?l9 zXUFP9yokCQ0vQ8@JgaS6n>O5J!WaYlUvB_u9Dsm2g3?TC9dWB4%TUCA2+$#P)@;;^ z9$KrPkPvT>(T)HR|DignmEgXSUqM%VOZ7Db{BzR)W{x8ffV0E^eVlN*{K?U1N0<@h z3`i>4Y}g>E%oS^J*SOOJ_b)7%tG+fcU}k29?6*=kflw#jvOs@yN2yuUBC^(L_Kj}u z#~QBbr?GlmW{qBG2mw3+Um%qk$m4dGTi~S0Mqc9CxC+ouIFDeJ A0<>hKE3r$?@091VeBC(a1esu(<>7MM^AAR_wz6ksFEc}KF(#fW_b-D zQwW6<5{OPj2%!r?z+{n#u|Q|LmN*=0>Tsh2;+4vlwpywSF(Dvp@D!{Yu$8C=5}F&? zYuw!<%kULx(wPQ9q}RZV2nwDUZx{r&;sV1RF3=OsR&dmR@c}3aE=@6(di$APA0Nde zYkLMElnJN vCf}X1c%@t6g;xdL4E%bb{WrEWrgqb_`^= zQN7AWwDLY~NuY?XDHdVpWx*GUch9^vF{1Zxn=%xB7=F_-#qh%AD*qCN_&1(Lo&!g_ zc4ohLQ-Z!do}sr-nVOnnnaZs=EZYrTsD3bm9UX+}YZT?s-Hgo9Fz6*X_?2i@O1L?3 zxt>c9_a@F|zIhQs+V}u~VipkQB1GN_grj4l_8}s`aU-1jJC^YfVQfW!X9Tz|`}LEi z2^nXo(C0M?LS~I_IHWu1G07 {8i)?P6(3xC~l}c-vHx7AlH_hd?%+f(W`M zOvDYi{5A`SC=m6d#kSA53xAd&6!w_%)_;?m#DO#^qVTfY_46UEkU0F^v}92&-o#TZ z-XVhL3ua-F(f!Tnk|(le*rDc$jLfY7?Ec%70k7>bey0aDw-jv@6cpaQD}dhiS9~r( z8R~aHI@7L-H-NtKc}MDj)c2O|P$*o03YGN-X{LC&yg93U;A^Ry%X#Yzt_Yc`);bo= z(X-NRg;uuBpwv?CrEeVTPM3(DIsOu=q8WylfIk-poQPW!YeJv_XR*p8q*@ZhY5$GL z>$8x}Sq&Ld@wJH EaR%@V>o5sN bi9V0{fZt|lgL903jgGX^gz1MmTTCn)8Lxw@X`G7eSrS)T?*+=#p z99pYxl2#x@Bnj_=4uy9D&&&wXlMy@>`$pXlNdO|;jCA%;py&R_T@4i#>YsH^v$YTs zF*!N8v$Io&Z%l#i`u@$wnB7@w$|s&wf_7%4Td42S9ooc(_eKiZdnbpKeqm8hXW=g0 zsKFXBAwP@RIGv~LKlRnwX=a@!c+PFRa>}(575(d-@gp|`vOQa`JA$hbArqncPm2;O zbx*(8QKv_TYci+&`iA3{QFThM0lMenCVj^k3<0$_M&U59%GBp6{Q$Oel_UkFlZN6q zz=YJ2RQiH0TL`WT03KwtUpVQkQkRsH_g^XCCSeOks&pQ&o(>&Yj=R+cfWvkd(Xk8O zC$T2 {u1b8RyF1V+OGs<=$NP8R}x^ z=0xo{&eR@F=WzQ>nHz8ub&9}0q0!OJZlo|<#^9+{>6B(&O%u1Ncpsg-so9bFdE-~u zjb~_s+D3=z)nAFs%`Z1+YA?HG80#j>k}?NG*i%}v4-uZ%ZB`Aqx$=N1Cndn%WRvQN z>F#w{&2j@bX-c0fr0u)NcK~9fctSJn(Zm;!Xf?*|Ic-u-q@ar|zEdUrtEP5^gn{(- zmWY=BQKznY-9 w$@ zBOJklb_v6h2r!!S+f!`m`3EeZ>RgHk&HF*RRJWCN7joN=nwf3clzc+JA81#z)q{ z6IVl4!?LWjY~TQf<}XjWfF7E#6AzW&9 ;r(=TVxwH5M%%`?&sg}hwW`c`#ZhEtUj0Q%ak;+R z4x#E+#aCm8;-9skq;=pdKh~ z^K4xkayklJmGqEsG9yS$X_H gLFIyq&u)Lp7=CK-7e7`UPkz%b3{=~Q-^&30Sb z5iKV@6%Q~IrmBLbpi683KS$A@qysfQ7gQ1kLf62~_9Hmnvh3_APe&58Var>1VIX>K zXkM7OETyNX7r+$bqPtWEK8^ZdsdKeZ=~4c|q(L3g0C2YTLH5n`$xwv#XZ)V6S<9|? zSBxH|?s`TUpz+Hm9K& AQhr;G(Ox^9 zv@Qq(6Y?Pav&TKWO YGz5Hs7wO*#$|b=n=zX!}7duc=Ji z8!O|65Zc`yv!UXFq$6gN!4YZOmMT{K>U_uN1^?n}2eB?;N6QCQKbsEPCc7U3h*4Q^ zZGZhEYQCzT(PzCk&bITknZ=e-+;D&t>Cb4yZB*|~C;mENzmfnxB1OU<|K1pk5XM>) zLZ71(!0eK8?4;>AEQBzdqXMobAxLz+b=B2&mX}`!m!(L$oZ$S)ki`sMMHgwXY*(n> zGTs=niM;n_bDw4$*zLD|oQx>hGO2jS2f~LQ50*)S5A@{k%HJRnG429yMqLim-=0-M z&yDgZb?3-T{tww%nfM_Wi^Hs4;*^Gj) >?@l@dam(I|pGWQEx57n(j*|p7a=7)^rX6kXr0{P}(z&N{w@cAyIn}*`wUk zy_X|^i5lAdNunDOyym#-%sSCA!=n`5bZ=zbA@lD;MW9MHe*FA${fx0)vA(LxcCjzF z?tI#$Pll4i&6LaoV9FgJ-Q|rzhBVM>zt8d{yS=e-%<36i@@aEz=SGoC1*Xh>ov^KA z#y56E$$w^am=LT;Y7jwmxR3@IVbib25eV+R4*`yI7l2M&7karrZ>v!JJVnbvf)?l{ zt7}r_(9|qj7RcezR(XZZtxGxm5Kx&5>+4xxHntsSVrn$5?F|G3GUPlAgJ-Uy1w|qa zv_fEPn TjtLTUHy&~-oU_dTT9R3lH%eO2cM De)X;w*m{6jzvU&m>88oR zjzr+Nb#%GdoQT*<2Rpkr!Q{aj`k!`r*dP4N6jrU$u+g~=Z7Vm*t&OPpb-A6FomZgW zI9NMB=eTYCSy5I^?l|RWC!F~7%VUyb-W1j-S-h{4D&rydc1#*XFf*sdXQH!*jpN+^ zi=?og^mG>QM(LCN@l~y9q_8%GtTbjfYozi{SAgcmoi9YKP4pEjdD2Vkj{}hTVQcpd z`G%SAiKL;fGFjZ}a$9oleeGeFb)uWPt|+^bdq?g@2EqE}nGvLQnRi3+J8#d%Tm#Ji zphvQAP)tDv4#2I3FXa9vOgfv3VQ?R^BXDH`zQi7cBZ2U+pmaR+H=)5D@sRdn%HV+$ zFDHDIz^my3F*ZtgLb8>I`y8m*eeQ?IvAe5T5XT=;C#T4T!jkaKa%1sc#2%J(gz@3H z0Wjd~c#>Jj6nm<;cyq+YXeCKFeqcOyyN6_MQx@DyXD#ycLw3z)S^Xoz9MHKmyunGw zPrDy-c!C%Ra6{Yht@4MQxIyz>Y}PWXV!RGyg2-WyL8ZG cF5WBOdjO@L*dwg3u3gsImEI(e%UBjF6?cx2lCPT#yFg2#63#+h3R8^Uz z)9!%T9--t+m!18A%>InnxUOaUP+m=i_ 9 ?#fy(~iz?Bgz}F(4jm GGi03?Ntb8saZN19+fWe73@V{( ;EdFI}uQ_8fadR=lSMSxat-2ld4_P)BVGaXZHK zDg^aWt9P`)xX;>~n)F|fr&?5H>xEZ)O}@+!k&uXo_daFjH#w%9B1>%DH+&> )h*}MW(WUbY6h!$__%+5JJEIZSwR<5R?DtUKja%Kz;lb~`E5P*l} z?IuhVgNe5oukY}-h5h8zIdLB={EP4PhrlXaXrB4hrdB%1{;Sb`!xK{Uu1X1QhVQn~ zY*6L)HltsOi`?;;?(;P(Vqc_r_)*3ICO!Xvdmc~z6Nu3Dtc5~xM_#I=^;mX!!220c z;qou8jfk1XuwNU(vd6DmH=w@>)U|OlE&;yF9-d@RveIVc!|4Q}oaIY6$pfR~U_Xo> zT JUc?1zhhS%nXuS+s2 zv|;=B8rD0arpj!%-6i|SB#*lnF+JKJYAt1qHEs1cZxM-TLhyM~AA49f05H(ir63iR zl+fuEm6qObGS>GZltBu>_>u*uj)Yi_1_JKOg41lFL3041EWYvaGWUnCfh+qoH#0+x z?RV@HmiL$1zkmO3W@gqeOhJRaoKzm+S*$0mMCTTWefwh#Dl9)mn)JK}ah+J_WI$aA zc!h6eo8*?C!Wd|ezm(`GeqtytZWj_A!phFTB0%L-DQD3hyj|>YqWi}3jp(n!ss &gm5t(#X-%sqr(htQohEk zx?qT{UyP&^8XbL{bKI=~Tlo`5F>Dg>v_SvUj_918LzIB;)>eW mh*7gZFGORL!Ga%JXWCl&^cmP^oFJ0RFIWms(ird z&UDqWE!^MN- ||Dh%P^;*e*i&yWF`?`**DHkP_ zmL3A>F%uQR=CilKIO}@cm41ji%l)i8E(pn+ z*m{nPbm1lk0Ii@m4ijSE0>x6wIy;r?jZ*;-@VNuGv&)CUxS?MGcSkLT#9qG*oi>PX z_x;c)3#YwcDj)XzWymvITi&9g0X7eykx`Eg-AqtfvG|1W>maSn({teU2Y =ux zAo?>%LCngkvaf7A`vK_sU(V5zBzfQA7XZ@EhZ{q10KTdSfW(#AINu_frI5Cb-OfU8 zPxk{-DxPZAlv!XLV1%_Y@bL&Dk{)zY^IzFlTpEP_g#2>r295p0fP+;veeOo9R>|V; zk&&0r1K=N)!s4psav>U6->+ -+2!EU@E6{WBcLAU) zgS1^Je8MSj9(o8ECg8VcLKMn_prxO=|A+e-1cJLGyVz@Ub8sr#-D 6LT9k2$*cAZy1Ti;jUOdjC)fdhLN;(Uxd zhi@ys>Rgk5%c!m--}hFqJW_}9@lp|#`Q+w{%G|^s*70xBDla^whE{S+P_olF=-_*M z%fGZ6=+n+{%*uRvF)LH@M3o)DE-ldGm9#7GXkB9{Q!E=N0r+gBYt|mtn;WWk3!<6l zw9T6oeeo{<`hOQR0C?O6@hA__g6?GBiJMLt<3X#~yL_rx>q~IJeb(x+@=Q_~M3%wm zQw;Cpt@Mtfl@$9z4*2PW@^W1mp>2VrM3MNOlMi~6Y{SVPN^j{RRoQ<|T TC4(ICOr4&L4LEkbLT^h Z9c+v#;DHZ~3^DSy|i zOFC`jq3xHcnbDkoX7JtEZf(W%B?xCoyLX~6nB(K;*~3K!W#%yO8P!a+`2U(h|7cm} zujlZM1qY%6eFH(!(b0GA-1!XkL{99^*1_<5GFQkmpj6=u^tU-)Nd0g%Tv}|q6(;td zY1Lhrm>BvuO?F}r`VQ(4;HVuu4=aa`RI#h;($)4L<$qs1c>xRF8p$avENpF62yDi$ zy-#@J(0j5oz2d~KwmP?0R |Yb+5TA@Zm-l?C&N|#@q3&q&;UgJ z4TWTH+z&ppWZAwfPN}r (@>f;e;QBOW7ZwI|0f%CxWHkm~KPWWiOAa_T?k1-NB7ETo29 z>rv!TOaO5SY5G+Tc<&R_rCmr`O2bz3$#~TYE=es%QZEB00N6VmPw^-jB+SpWaIRQj zB5Hol6*2}ehcd>-vH1k>TN}z_ur%cGuYbfxQS+Wxof`to91Qo1L`{~SSw6Vx{{Tuc za(sL|-}rs{Fu-pL3T^={mNs apX4~^7 z%j&f4KY?_tjoJU%tpqd!fo50kgQJdLkEaz#ds(3#9Qui8>A$h-5}jM|(R wlyZ1vB!-dGZ(3-c5-x|#mHgERE zpX_Rk8PwUzRT1PC9+RP%#Fwq>ZM5IMn=M&l!^a#fZk<(sY{?}(C>r0g9zW0yFWXLO zl6FmA6BT$k_fphfw;f~hCHXjFL5pFIW0oFS8e_#2<`VPO+u{=vlgh;dqD))xKXzb& zn(saYo+Ie9YqK6?;y5IR0ijWH@atc?2tgUrDq=nBcxB3qxHhElNw<{SVc9td_VB_` zMx8~&u!+KtFhUFTJ^Cyuc3ZWl*|uA=Et9^UdkTLdD#{IfsWe+WTV=7{Z|jwMOY({) z9^tp1G|5nNC1=qOcx ofoz-Or=1evZd+mK$!L0t@S|WOZDZ|&d(a>UQwA~ zo;g?TvoPP~D@L(sHHz0y>nCTR>>Dn(y!bM5+`m=ogK%k`I7X_6m%XSPscCQQ1C2*N zB{$2y<23XN?26sid?k3v`oo>NWl21!7zlZCfzqX>ej+Znl>S$_nNxypku1lxeUX)O zSr>v%`ai43plf&^`_{`9N$r6&nO}e7)fhM{bxuu;rwzo%8boZ>O$1=CNV<;>VHYq4 z5}Z@e$X6IY&x=iPm)kA!?HAtI%ijeaXdU0nImRw@U9hR21k8QG^lJQL&vIkzCtMK= z+h-@hfPEb2-ELb%9qG38{&5rJnjWlcp1jH7XSy09d=Vn;0K;{ue~N`A-wwROGp4rU z=j61Tqn^;|XLqa*3phJH0B<9qGgJX%pMJY|UBEXAG1_`bU#;J!hRrCZE!TbcU1hd; zVU|JfP{!qcjiiowBCzv=t+Vf;?!KJ-VoezwGs5<6CUgF~Ij4;BhvU$*Z<}{KSGCFg zRK;HbuDycPG=FYHtIu}o`>5`7(u;BIHGM*T3(UZk-`5RNvWXFe432y`QQA`K--;{q z%qz4nMA~cZkXbFP78Def7Ch0LR8b)LtDB7%BqxiC`ys%oDGkdkH)QnmCf&euQ=mPN z-&FqKYzFJ|{bYuW$tC=uCA#GuL&OTi|0d^QXtM29#LGY8l+1Pj>kGicdGzk+iJ)1V zOVshC^bpj!VyTCi7KeM>_lL1XY3ASf0MA`}e@R~5OFI~qsbhD3$oj*kf%!{*1pWD# zV_fN|^~te}eb~ws#9>R_b%vY^TolkaZ}z4-i1!a}$2VA;N>CFp9JOYN=H!zJLRrq9 zlLo=@7ik D;9D8{o|ap1V$0yVB4J0rgXFo{}p=OgVO0%(*v>1js>42owMDPk&>Q8 znNU<^U$(>8-5MpobE?&;4f%s-^=269()n#EpaF56opbjEck@|U?^hgKry2awlnRvV zk0n=xnSbm>kVw4zRgT`PtYwx6T205$WJJJgQLP>P%G?U?Y3BmXGrMQ!=lz(*uGoM) z$mNfznd#WB!_%?Fq@?i19~zQ$5!?)jB0gvleCC8x3H7%Z)>Yvp_6LA^j^}fN5$5vU z*Pk>b{?K?)qMN5hPTsa5)hfyigNi^$sNfn?ZpI%nZZze!V$OZLgt)j_gPS$SKJsCe zt_47|0q4d~bH_y;TTYHR+}%-lxrqI^{S) |{-1X4+TS&qKT+ zO=AJXq9@Is4GQe6NpOJl@u6ToNzb4tR+~(51=WqZ&s~Obg|hop;VgftLd!w_(1O8h z7i{5fc%hbF02DzatiUXT) Gz5Hbc6PP3T!WW~_!ELeZi^-=YbXbvCbAW*v72Fd;J37X5Btuw9RAZVrKy zSWTs_|K-p5vo6zO<_%_{XTGx_pi7ZqYpcPrXl8{Tl(>x?Y0uf0E>JO$F%AZ*Jj>Mx zLQPl8#xL@A>@kl*J@u}J3=R&WCj(%VUM8L}ilcNcs5sjP#b8_K7m~Vd-7bhm8ZVW> zT@y){=*FEYmyLKL|7&BXw!Bv^avTh$ZLOh7sX53q`iTI*w}j?BeE&_)yPG*FvNer> zZ?EK6D*$mER8{s6-FU2d-I>pe)s !e}Xc_O5b&d;UAjw`5>m-l+>pSi!$wdhx5CfoV)V@AK0EVzLO?fRaesQ zd@wRe87k9=uk?A2oF5833!i4 zosTHHe|+_M=<*vR_V1JP!&wpU=RyBoo)@rwfu6rSZxQm^o0GOO`k(t^zcBvxDlr`A zWqIP4MkD$)R~pg8dH*Y4Fs yJ?s;ix}m`mX~}KTiV{b(i93Z*OOVvP%!P_I+M;qKc`~#WZoaCMGE@uznhG`#PE1 zxWy@Z&;Q c(FE%MgvN(PCshSo0`sm}+Z7&L2+K%fW%1)jR5Ot7$u)y8lcav)S zrGv8`s$Y9l`1?858GQ-ueWg*dq3zP#e`x&?wc>+_(4BwExyU5kcW@Qn^oaQrc9M>K z`7T48tWwOVI_GgD8PG{VTqnJboxEjD1M9r#7BD; VLN9q$y%d$eqPj_#LYo&w8 zie&CZqU>`y#P05=J(d$tGm-F9mSMgGoej7(qszz9`pfS>oc@h@Z;<}z{?oYxTGw<6 zHMV7o%g^#N%p!YUm_|greVO&sISY-Bq{hm1J(u0R?s7{l=u2Zyk3gjzFVsWV?gl~+ zAm=o_xSl=aDyI0s)-5wt?y1YwZ;5yB{LlX7cChjbjVQ4bIkZ?InaDuWyqhWg)Ih}A zU7FCow|TYAKj)b<;ROf!*~ymuo}#kMa}C?=#a`^6o7rS7IXXa_@C5IR@g;6|qU1|> zv*kj5MgN P>N1F!3_`nb99P7y-&vbi#PCGU#juZsQs!U8Qn=8#8rD5&uWmz zLE1m6mH+-?_r=AF*o#-i>08fvG|%YoB0tOFc*P6k*&eIC$vjBAK|RQz@j{2v;jLhC zXiYiOM4Pc8a;bpwpLvvg=Q)KJ5Y4&AwnTp&9J>5N>LQ6Q@;~eU{!Ft^!*f~ZGMaN2 zydpCvLr;IDjp5qAx$gsZe`<1h@@JZQ{sy R*?PqZRldxM+UZv#ogrm*qWrA{i?s1i~Nd>3jdVHwKF&s_8 z*J+GYQ)#VK+-TgXt)A2S6{l_oB-knZrK{4*p_R%ReEgMm)QXaR-@Ik5Bt=yGepAyW z`d?FvK}+0O#*ZCC|D$5_tWX34N+#4^ H_0z0}la}jOB*e4K)^~rAh77w0m#uER@pBTOg1`AM8>F%DlP5a%)}u#M zBG~@pFDmN0Z071-k*LbWWvOg7j ^JFR8M!Ke-`t+^P(l>gG}A-lBI!6#=Bk(NV7pH z;vBGCv0ZZw%36Zo`nn8R0I&JTrCIPX|EgRl77W*nw-~utr2e4tuJyxg)r!Po z9)mkjfX?Nb5Lqtx-h5NtOx=f_zpVaf>y( E)@os+o`ZX*p%uXy4AT1^)R!t3GJfi3Iks7y!yL!L#wu_ZtmSJ1QiwzCKW7DPG zsUVJjmS(7JE#T6^dcXUX9s38OlHaWfz aSCl-sAu^Oag!$szw|ZuMj?gXDa) z Heq=Z`lJEPo0f`)ROPSo**!AtrZN~dO zO^OC30mtmZFoLq08G<4ZReNE!?%l5Pp@s7p(E*Lu+aRKysPG5BFY{H_9WAyNx+83? zNqmd-7 2kU7GTTf}9&1Ti&L0w!GJ5ZuodqD_2Y$cF& z{ 2*3yZ*v{78E_i)l+5K6)9vr&!MB<|Rg2kw>{ Ley^98CY?fr=ZfQ&2V6#syy0y|$Yf|zNQVS`Swg}r#QEgm>N NMi6sBbci|9P9{c*z&F zv4mus_f^SLLaG*{oMv}A- #mIUF zEIp~5bX*4M;rFT`*XjtROSq0`LM+!egwlOxlQJXloka-E>(K&*#ZfN^HVG1@job74 z*YS@*@6f+ID+3Vf?olc4WDHUg P$TRz0C3g&C%!vpj^A z&i{HZ>|{vO?q4MQMOvrHC1_?*oeo$RTMI41*<+xT>KL=H;k3-M#^(^XggIeEy<-SF zKH5>dlihSZMXYJe^pfa%HDx6wrIeBNLmbmX!~IzVkxBkm3F0EJ&jn0eE9NL6Y?#sV zkxUcQ1egw3hWY*rclgq6Jg{s_=%PCF4PRM@EgIieWB5H|+jjNX!o1Dp(aGuWdGMxh z>jP%xi^D1ii-eeOQ8C~f9j=syTdXq8NQyjzLA~&Dq*%){QzwYSo{38Hwzx(67w3Fv z6#d~#8}|)pb!AA}Hom#IONIGiqD+FR)Q^+W2H{-`lUa~pKtX-d-IJD@>hcg%IW9qh zZ~xw1;9_Zf^YMsKEnt$`t0l+0U}45H+5B{5AlAPpE>ZcI%{Nb?AR9v3PlGysUv#dm zsJQI1`pIZnX08`)@$jCg?5T17OMgkXRJotR{Gm!qhWCm3Z8tEwD*ZA%vkz3iUUmH? zWJJLTkh(3UNreo?(HHmyq2|rs$U8$^`*Vr8nq_h&M48#uT(Ws52yV+0e*!yn-_9Z( z6897;+(!FW`|k9E58^Uly3^`P@3&u=gF_r~J@5?h>X)4FW?54vxPv>wqA)OGOB3MZ ztShNDl>v61kD(jt*6wXQeW70jp~Uv|u`e=Zm35|L^N8K|T|m1hIl?Z5Ru~%Vlm#7i zXl+6I$tK=zs}FgygB9gGgu4e+XZO-+ldQ}-tk7qF+TdLln!i{WY-g<2YaU+{%m$Cf z&1I+DR^<0Eobg-h>^Nm!lAQBd>x_=-nv^}=1j4S~`63`$np#qLjYs&EQej5RB@;=x z-n9xZ)fDZCr|I!NC7^+9jsidQat-?y-D!YW8Cc`w=0=rB>I6G;(HmJG@#=slwUZp; zUjz)EDFib4#g+w)+P^FEM)%f49jCl`#ylM(yA}9op?>0WQ~B}E^Q9AkYFNoP}8 zTGF1mqb65xN0t5azl?>W>wVbw@^4j7X2t%o6rWs`10KWClPV39FP0oM7qYdTPc4vD zJB}IaiexFjBsg7e4nA3`))2Zl8B+M5QnNV7eW&Vp_2(Sz#xn0=46xa& )H08&! z4bz`V0fRS1pjS)h>#tuEHNVA+Zcntwa#gWQ#f@K{azN(~-+7zR;fSeMbM6 zfk}jYQ(ae+YPY1wxvFQ~i*ZA)^}Y0FzaFsI{(a>pTdUI}86V|M^6(@_QI?=FT}0y( zCd8U+>98W!l-}eMQ!M ExYit;s1`=)rFv#7uu zC#x(Tl(`I0ibc2BVx-mp^GQ2wEn{`Ui)P;Q-qYX0s8VWw#M9P*w7$tz%5w0}PfvYz zWjHXM@<0_om3$l0oshOnU%5F8l9i_#2&U5{oM4&Maue{fE^>Yi`6FrX_dxr(kIHx1 z+GO7;dMM~{fyqS}PvdyvMUk68V0FH*fNq@tS6Iy7i7meWaG^R@4ESnN@MxkeI7=9H zZ7Rlf&K>z8`NPd}T-xL1Jccx{1aGCd4h(X#4A|hd<`!wT4_~VHhyAd|9&WfEMmePQ zWg_k|mEZep81VJRrB!%R!(drF`&NlmeH9;M-oK_X5fEq6HFL{pP@3O-!aB0!^LG?1 zb((P6DUQ6oQIi#C#{7HTQ&ie{c#t+hSW@P#s(SLV%r(B{dTAo Lu~m_9q*=+=EtapP-rbaYO>Y^keD|N6rWmW>;Al1%P%{;;9u zR310sRQPz+St6~%u!ghGJA;EzvKQi9b4IB!dV6?yD(!&G(v^M*GcKBPi-9enClLze z$k*FjK0oKBXXtl*hX<9tUdnWb{YV?1ej{|(dPH4K9=Wb)d97~@c&S>Q>#mggv>mLc zDb7Dg-Sk*FIrG>vqJ>AWKOAY$h-(;9_3~cNS|0foiuXQ3F+%&^N~tQFM^KYV@n_!m zpE8Y^XO0MYcz5t#r`?ntLw6*{iJ|m3UTF9Om4WI o-m|}^7U5U zxE3^VQ`pJiR)yS8v!u1exuJlEY`VFuP*RAWmC^$!W)ga(>UFMi;p+=`NOKF+SmLER z4 zC9HAA8@`D!Q`V IDTk zpyFwQ)YoTIS&(a~b^0hr$CI-4*H6RU<7Wm#<3zg_{f0T0ng9@a>5_q;+^Y~#^(N(H zkm5$)tZt7VJ<=3((4r%okplF%I%DW|H4?~!7lU;pR6!4hR53JY&U2|sHhTU%blA>+ zyC83oaRkGGXvm^H8u`^aZUIJjuhBl=`JKL`SgzG_HQ)Qeb {>&OdN!czAmko><+HCs3~_wGHDgTi0KacrY;C8AM= zxsZ7cFTD|9dgq?j0i{+urt^8DgG1mqKBmzD22Id+rn39YPt>=%DZ)@U3OTPCG5JeO zDHtRUi7*^Fp&x(rVv#c8%f0F*o=+~C-70$Bap3q7pl11zJ5>tXu+SlymGs}4+of`Q zld8++4oFV&8Ydmjh6ziukB+>%#!? OtR9&yuma+`YBYH#CfW5t3KR&?wtm$m3&q^CenO80M6L~8o(g* z&>Rsx6?ppx3rk}XG~e=;{p!v(bP8? $utErCT2VPTx}ed|*4JyzP1` zN9!vf?(3_gIeB-V3V=?9@1Qp`=fDhuP+nd@=k^`N!=912-KUEeaUiO0DfXoYzjhs= zpX0|yZC-82)iu}m11sV_S aaQg# zIM!=3?6Vzx+gIXXRG*Gcqb6?Rnv}bvwO&F;wby@6LPTJjZzj8s+CcoOX5AFLvd+9Y@%;b{Hd@qZ!TauJgTb|G%eZAnK3fjzT!&O-Za1E-?x ORo1#t{DEsRi(n6 z%fNcSNm2ueUb=J#e+gAHLdF)GufgeGR#t@C+G9oKO#_?0b(X!pNRvR@!g&*aGKsnD zN0yUO1-e>T8gc<1@H*w3Cbq9mA*(f-H_b6J0JVqKqm(8MnhP;do`}vRu;LHXs4TT- zV?%rdCd?=e0lfw*Pj`ww%+%>8pHY7-#J_)kqgljEDtQl)9=fzJ%bPOM0pe) z_5;nw&U;|I4lFuNFP$sSon7Sm5S=KqAW$sM2b!{#@wIze1Tx?MJL5*wb%^Ee16{Ql zVVh12Ay7Uq;bE`k*2tRJUWohg!TOiJft;BsLlv{5^q>^rjUUjsi=nY%ZEEg=jd3#z z`m4gj4{|?Q-9>ll{)x}{oq^{K;Y}zgZH8qJ@q9-EISR3;olg(MxMcI6s6|d8j7Lo` zDZ_Eu-ZSROuOm-uJJu`L4%NQ<+g4CbSPDNm74`VlU<`|&bF&rA@!Cjzb`Bt`Vt;!4 zlo#cM@|IrPwSMk#qYt!K{q+8Gv~r)u%p6Bw XIKvTDP31IuM{kNHS?2#ulp- z{Mgb R#!Yz-4!hfG$wAAgz%acPXD(haC=e=Z%jess8?~Q5oq{wrfcE-?0 zcCdrLQXwRNzV)qW%C*{pa|ab7Yh6ZO?D_0os}-@{YfRAdpY%iEk?uyZv9fhX(y!`1 zNFAt89agb7&wpnZdy1MucWy2|m>maPv%{9sZP8C8hd|)x<&Jva 3aR zztAtnxBP#=FTq*mJLVR9rk1z8?j^()$d*XlL+g8HKjJmp@rxnu!8bo&8Y;p%kKCyY zTJ|%gnbNT2KD(Q_-T5u`t~P9Ql!^Cc8m5_k$a>gzBJ2%=rm5W7lvReHt%r(Tld%rN zz?anfPCn{*Id>>xc2dH#E?n`bMpF&tw!OW#cYTlNBISea5ANwUeZ%DhC|W=MM&o$o z=ON{h$@!FZ>sN{{AkgGI lte(1&B=Mpm(H~>?y|~kdx}@TkO>w^JigS9tZ>P^2h<>+oRxUXdp+_U*feP}q zY;s|1@jTwQ4KF$ycYRp)D(akx=h)lR&cR*Rui?6Ksrz}SIk!&7e>J4X#KgF_4|BVY zWC7_$Umg*DWMkjP5O08y4`!5z6XSlFL}*NW?rG!c5T`T>^0YPa&yQ3|<>6srch3#O zIV3pv4 0W0rZR%_r5;t|ss2rS12QMIe>*4sDsZGkjip`wt|ZEb+fv-bm)T zf8&N Sh`rb+JX-7}C9@XOj|o%IsVBK2`i!T JP za-g%|C=w?b*Slnz9hwk_HoL}YLqT2h>Hg{ES6}&6E{Mg7CZ@fdQJS)TG&@f(`c951 zp*dpmOQG41|7yw8?!`M-PZeJ*bPv5jdJ^PksWWoV!z7^Lx0!J73$dL?g;*hDslnxI z%jmyDV7^Y7OLH6l37P+{nBDm8@Lxrw^X8S9`L)VxnEG~Jn`l(Xn3H{T)6S2i$j$qY zj%?JOorT_dIecDhn(tmay*?j0@LM!v<>&zWL*TzE3Y?U1o%nUm&(+F&KW3F)Ek}%B z!IoaVT319a@&MX*p%v65{5$+(=p8GEZfCJ6k6XuXzme5nvB{>wjfiXiMdHO_y_a8Z z3(< 5?)yt)k1qg{$juXmxvo-9N20le$^8&Us`1ui %(J0Rv`z)*<=LcF1pHBN~?`{A+kQ#oGF^&q9~W{~)zR0-Z35AJ X%Z_0N|vgq&pi3`2n7K{F*nLFwvu|#2{ynl z$FqQ`5)^lO)9sP|{^aSuBUwNJc6W0lARyQ(tS;5A{}z-spe{1Fvv2-IQ40~H*r%&i zeHhHcyDa+xwmen {FE?t3 N=Aja)|e>!kyIg}jW`+WwCaKCiKflb9abBg!3SGjo+A8SINdl!M`jLS(eXji@Z zd<@2-Ll^EUvu_!Gu_1^4i@r<{K>|8ff-y)q-R_S%v9z_cW()G5x1X-ZcF}*5RNX2> zs^n(e&hmyXI=Y-2LlX*?TwKmamKiZjd)yBb-DQ-Aqm%F_#QE<%i&R{Tt;5Dj?@V9j zOreOA<({nZ@SXjOWeL5!#B|%}!^VIN4h~AsUA6W$P_!nKd!up!4`95TS3I%qRdh3C zo~>JBF;*>djSb7o9_y-3w=4nmH4}};NYszM8UbsP%LPE8Hp?xZ*yzS%dM7uQYM0Ba zY{)C>v19>%Q@6x($zOu(?d>5g9vl?_VQax7ivmM|4T<%BY+1A^ wL&@w_{_cVF}Ru`K&4TTf=G7W|yF%Dz(T9-;T6 zw@M2b_?97e#M7$*x7=q 0L=U_&}U!Vq9c5&TS4phsYF3SE|So=R6rc{0qp z$9cxsumOt-ucDL$FB|8t*`*XaERG3339Qi*!Kbt7I|1f$kY95GL@Q}RO-(b9$qhEz zp*9a+_^XkVD7V0GYWK{Q=)Azh# zgS}xR^<)CDbBZg@`yQ7T|HDAQ!Uh+nw3$>N__jU4_y ;-AVy=fZ2-q-|)Is((7W=#V#H7z&{~fsl x`DfJ&HUG(ct6jZM704>ysAl1Ej-J)*?Z9vn6 z3cN>q_QX7WxURPL+y!=ae%^tF{fF6uWvZ3YP)*`w9imz=OFNU2+FKq}B}IOc)3_ z9dtzf6HL~5tzRa!cqkP7kf?UkeZ%}%(q=3y822;AmnE85+d2(`)KDlRKU+o!ME`Wo z>=N}m{a?HgD^hk71Q0?fF-qmfmmnVam)C(7vxum9LJ7GUc)#~z+GfA%pm)BSZp807 zyc+>P_01v%!y)PL&lP&oC_L0tBTwSw4+4wWeLJsc|9(jflebe?!BD9v=Ro*sQ#eD! z4)^{<#C#TZ`ldMpOtE*E+r%s_8K0oxKVOpY7MVUe+1~HJWDUuzplv@ff@j!{jC)Z> zis*ciP6i*8RQ+toj>qLq8vY_db$p?%7cNp{l;~?(*MO;mno)COpLsm`r h8pBcKS^Fg z!WSSxm4Eo0+1@pxGIR!+EX}Yc?~?quT`ihHBA|lljhGqVawtx+@mtw{??&kPWtOpf zqm7xbMTpW5Vu<9E-nq%2Zga78pXpc|;POk^i@rM&*wY+WSkA6H&D$z3Bv_=L()zDS zxKVey``@qn4z5;c=9o(>xYjJFuz5}njvZS7Racn$a>f&60dd6R&6l!7P8oW4ejauB z|IF_Ib6%89?PYjb>p+AiAsX5&jUitsnxAnqaY7t9WWDma<(MVnJM%|Ff vGC?q0P9G%Nk0TabR~8dQxU`e$aewwEDtTL?>+-R4{UCPvgdCNXQ!Cov z8!MnhI09>Xf2NYu>GH9Scqhuk=OIaOKvUL@CkJ?xWYG9_ z&r%^8>O0f5bckO3p)6D{Z$2?dFxARICXc0eP9H7>rhBHPxxhyd;l~;#alB+8CpfZ; zo!@m@0&Epjtq}&u-8 Q@8a-;rH{}5W-#Rzu>VIB0;IwJO^N^g`Tt8>W9WjR%q3`W;)L~>bh+Q4 z1bFhQxEGW)G+dU}FJCP|Kh{4wC?ifEhtS#_uXPKIx@`I0kAh*OugGS7R!lbg0fB{J z;Y0Qvw=?5S|D-|N+y4Tr%KBUp-zM=p`4VqrnKI{KI3-E1W&p5|PS(8l*1d%Q{uK}3 zfFDV=T8W0CSaWet0iN)X*{OATYf^lC04r6EmkHpVWMyT=zb5SeC|VrUW_|f)xoH>Q zgpm$SjKpK;TL >Wv~eTivsW z&N#pdD z;eaQ-*YG!1+f#A}t}Sj<<{JB*>dPpevWtZMLU2ulXj* z3J~!6Nr=8UFN@i+yWF{*Y^k%(NcU`2r5xB5265X|1%D1-;ik_xGkeyyQkRm6x7mx1 zGw+zH=vF>sWmG$NAeMG339M3wZE%bCC&_Ja7Iw20lp-QN>(3DRA-rXZ8Y_m}++U6w zfgS)pliJN4tW6p`scmh&M>hFwWL=ckD;0F)b+O;UK>`qBSl6zLeE3axoRGafZIA>6 znj3Sk=$1d0%zHafkBud9l)@}cjV=4O< 4-|ZDCnnZWpqP&K z IyP19o8AJkU)4ra3y0 ~~({CtqmgwOF6l6sdukBmUr?1ZU{MhQ1 zuPr{YgYFpuI_MZ;5^9UDJlC?vOZW8EDXw_Ehjh*DdeOW5os$^Vh@i+ytKD9EPUm-xKEHLl0+|&0|-DKW;&0^C3 zcv^~(9TQC2r^Mo!=i#` y)%C;4d2@earm{+KOY&aNveJwZ4b=^eB9jL zZSF18?_;91jIc*?P%bh%TYB}hmTAEwsU?#yYP;H1dGU6D>Y!v~-`8MR1tN5ij|&Rg zWAukfwsS2=BR0VDT-Fk0yskU1iOm2?fsUtVaiR`={0lneqs# z{&%<~x{zMGwIAe?L3gBVBO#&3*s`*R2yhFMo^J51>7D(HC3j-a`I<7TKj2AiqgF-J z94*BnLnbiaRgv(L4E|{OGsQjwI K~gjX@c!~si(5(?3bo|tZlX~FXm(f$@hw$vyguk)Qtt(nYNL(O|@Ao z5btIP-*&rQ3$goN-rRtKp%4WV`^yVE3;vVxOCGtKI=z_q8J7(VNLK#%y9x0qZTDBC zJA!Cojp^y*Tto|k5eu_4-W-+@uH3GAEx(3Zs|{YJc(3ldH)Gt3C3m0^{X>J5I$ zjM2z bLZSe-Kst}eii7zOi*_BtjuBW8?|Kwmu;4SH8r0edu6q1 z!-x8UGoZo%0;~(xeD(92k_sLl!Rn4gE*(M*@$idE2VU{m>D=Jt(U&PYJW5&ik#Q?T zRSXJI5i7M_+A{A9M$(CQSil^D#7@RouV=H7Y5DLWtGin{_?#!?tzw}cWD{BgkV=>+ z2^}|@AMvdQ*N>aq7@yUBmtWkDk$JRGbV;rxAQKF&qybSh|9J U!*`?Vs88&GVpN z>N&^QEUgkXxRKnQFM%b81v@#NVcU_MY#*<+?#*jL29{@QR}cNH^UnkF$h=mVPe=Tk z$gV1BW|q8Lc#g|&E`D(zl&9BUD?tMkPipmEbuA@UYF9>W=@F1%@9++5S<&2%#V+~x zyoq;Ice^>|26_n41^%p#GoWSbIQ30+Fo`9;m&@FINNMn-tlNGubg;~stL^w>*TKiz znPryjtl}V2#*esl;;Cb3>LgoEI*!+_GWbr5c|jO7_A6)O()}KHV_%wsWpm}bqn)gy zKX5ZYPkl1&$vT#{jKRi^b-ehc8*yfH{yWkWG;7V`Wa4lNUFDnesf$Esh!t4Q3E9eh zNL9Yg)zjBR*A~JB`=VRJ*yueoo*bTTxdldI!%xCv3v#MW-aswQ%@rG-e{&c4K6ts& z+oMqLe*f3|bvss9@t-;AJnhVQ9~GUI;wfVp=Tzkj@;zqWO$lK(JJjBmHp j)-$)ufnVmIU%&&l|$kHmlKX*{f4z zjt75ljJA8;4ADKA9@ibRIjg;%uF7gaYW`juw76L7Ju{cI^(C712wexz{@ejvE%*mM zFpy;sgZBudI5kOEQ-aU&%uV%}VvMm~n%At 2<-2nZ03;4GK{}*kr%^;K=Ss*Vjs)n_?f65y0v? zL*{lc0|RAH7#0oBfZlNQOfO9cB6JBkom5yyOJuVy>m$O5J6(9W&d^~aTk9d-OTPQq z&$_ltN5@OeMm~n@nLO$d(s{45|J=g~Ms9IiG5A&xn1KX%csB?3K8T<;_Oe^p@ld)z zv~Hxnd)Ddw{XmIiX0K-%2sK-TwOSl=qf?E6Lu*y;wwe^Sk?vuw7g)WcFHkO~22Cf0 znOSZ}l3@2%FIEpvlkl*LBiKwFtF4ycR@7`!ef6mOCe?uO#VRXM(VR`M1k&X=lGQ5C z&6mBIwdhGe>=Wk|herVR-Sz0r{S~2_o>R)>mHYPH#|cUP@GC_n;WTxuun6;doWtAV zV)aitjqH_EQ&USRpE55w2<`9B-6f!6;(&u}h &d4w(~YAr<+$=5t_(E7^HVR zFPY-QT23d9`E8Hu=gU`PH;cgT2r#wGs)=K zQY!{F%cUhr1(=XB(+I6I7)@?$G!PRD=5-nMd&f6>)80nO3}o&@5&fWK2V~h4zixme z+RDc@hg(_ueT2B8X6xy&fGyhmSFGvV$9PRC@Vkt0r&BtA<-#cWowc z{>&Br)*kDyFz9^eRyZ8G`*{84?R;8VWBqmZ@j@*BbobW|?Rx53nlb5{<9kwU&=;@z zNb8razED6WhFsPpSmxOL $aO^+dD5(!CnewXhm?a73B$ULBr z(tUFKeREKkAWB=0PKRJH=PR0Fjl;E=g`mF78E?qC8@K*b#9uM}T4=x7KUk<~jZHA8 zI)EF=sx%(eDp^D(OnH!NiKS?bTlM(Db4%g-%%Hp`0g*6INJ(cKNO+FxmBlOiy_?T< z(xx_})I) j?HMgr;TrM&vgKEx~!xRf80eT+Stu(7v>?(Xjf-vcOr#qB1WPyfgW z8!PJ_Z-6Q8b(YF1u76v=ozn9iiogw-xn2~w(GY8_(bDt!_4-|`3L{RjdW5e&Eqiz? zM-}&Q) dI|Pgp0Nisyfp9IEwa0kT z&Uqw}&2K4H# arY~n?Z`P&tQFH$mPm|VD^5w=s5n=ayJIF{}k8kH{%j5t3s z+dR#Ut0_hu$N*b`$nMj|Uy>-N+s^WsQ9sdm4t2VQRAhz5@?>PZ&9Dd0%G3G6p<4aT ze$aD|jHJ }L_YNI5QEqf`9LMQfY=&Ac~2)YjfBqAq7lpjRDuH&Q(nS9*n zobtW~7jrDGCw5SCt$E6-n}cLth1*{$Q}-dTeHB8Xb1X@;iXR)9B(u`&P8cJgAQZN< zCu=#O;);&9z^=5^;J6Mbyz0y=u $U2+%N3-h0KxXX-|# x=pVt0~qF(_y zPPVi4Q%{Jlo~mnT0xW)b7t40U=4C6z$II1+f*UZwFkkh?(ht8k_N#Y@AHD{Eoj~ME z4uuH`PG5tYO1xk1&&%HQ?0K@)<3`(lL<(xf7Hf$iP?hu%PN2J6Tn_)Wp{dkVTW^DT zPE5!{SIKz#6N;|fMgOU>$Rn_}qL1xUO>%6()_cJ(sqPq%S}rP0E%14*)DcnSnwPNY z-m5`{SK`M`>Wm6QH{q;K@f=iWggwBtpsumO?sR+myojxar;a1!mUQd&h>ChNRPw6D z4Q&g4{&A+rnh`|+)Fy)?v#VERd|^sH 7$#4CES`?;0o()M6;ZUA*Oz-h->6PQ=& zaBmxd_>@t6OzV{BWSGR88AxQZ 3uK_DeH0irMfw$#IA$uC5hT$x{vspd|G20l?%(*GLL?iUxw9j`htF@ zEE$8Pa<%>Ushz#U<3J7e%K0x!&EMKSLGH#kN3njer|mcdb $AgVC{WJ&kW#eWH5;974WC#a?_Cf7^3gF1aseWZC%OlGkL#49 zU{&(CIyJ&Ai{==gaDFg}=7iw_`%s~KDE7kDc~WbT5PoYow@aR^-TA~z8j7L9jlrvK zt;mm9@)clWBpGVfgXq==oA sjR zaFDIs*0pqid0@g)zWze(3ZWfl?vZHah4)*cMidzyAfPZ0@aeZv-wbBFPAA~@5&iXP zzV;EPdYxS?*xFMbi9@8i#+oMm*QahHU#LTQ=s)k}IiPQvPiTj6_;K_d7VUgiEmrI3 z{@5Eu_P|U?9exIm#=XWwax*jZ!b(UWolRG493PKk-@HfytmeG!Wi5Bc^1h(Z6?x@s z_+IE{llSI4lTY|Q)Wc&m^z%(3X-dT_1$#ro)if^a 3|BklD0lp&>ph^A! 50iHI%@kZ_Wxjm}} zJmfs?>VA1+ Ij@^uW%DB;f%-=!wu3_|!km zx1#=jtJ;S$0Cu>P4cJg-xzt@{76L-<5CkuBmxb*EG9j@=@czAx)0E#zM0oggnXUjO zIH2{TXY|J<*n-M@6SU%d0MUeti))>*NN L0dc^!a zH$enE7z+!F(4M8|p?C8DLmZQxx9_(5AzDwD%+*@Y6i#A(Vh@I{KSm?{@VMm6S;-VI z<~5b ^c6dq!%IZFa=wS+XG{i;M61ibCJ4O4NUF