xamarin-android/.gitignore

*.userprefs
bin
Configuration.Override.props
Configuration.OperatingSystem.props
msfinal.pub
obj
packages
.DS_Store
.nuget
TestResult.xml
TestResult-*.xml
TestResult-*.csv
.vs/
Resource.designer.cs
logcat-*.txt
apk-sizes-*.txt
[android-toolchain] Permit zero-configuration builds. This might be a suspect idea, but lets see if we can make this work. [The Joel Test: 12 Steps to Better Code][0] outlines 12 steps to better code. The first two steps are: 1. Do you use source control? 2. Can you make a build in one step? github is being used for source control, so (1) is handled, but how simple can we make (2)? How easy can we make it to build Xamarin.Android upon a fresh checkout? The ideal to strive for is simple: Load Xamarin.Android.sln into your IDE and Build the project. I know we're not going to be able to do this, if only because we're going to be using git submodules, which will require a separate `git submodule init` invocation [1]. Knowing we can't reach that level of simplicitly doesn't mean we shouldn't try to reach it for all other parts of the build system. Which brings us to the Android NDK and SDK. The Android NDK will be required in order to build native code, such as libmonodroid.so, while the Android SDK will be required in order to compile Java Callable Wrappers (née Android Callable Wrappers [2]) and eventual samples and unit tests. There are three ways we can deal with the Android NDK and SDK: 1. Complicate the "build" process by requiring that developers go to the Android SDK Download Page [3], download and install "somewhere" the required bits, and then configure the Xamarin.Android build to use these bits. 2. Complicate the "build" process by requiring that developers run the Xamarin Unified Installer [4], let it install everything required, then configure the Xamarin.Android build to use those bits. 3. Painstakingly determine which files are actually required, then automatically download and extract those files into a "well-known" location known by the Xamarin.Android build process. (1) and (2) can be infuriating. Let's give (3) a try. :-) Add a Xamarin.Android.Tools.BootstrapTasks project which contains MSBuild tasks to facilitate downloading the Android SDK and NDK files. Add an android-toolchain project which uses Xamarin.Android.Tools.BootstrapTasks to download a painstakingly determined set of files and install them "somewhere". Unfortunately [5] the "somewhere" to download and install these files needs to be in a known absolute path, so I've arbitrary decided to download the files into $(HOME)\android-archives and install them into $(HOME)\android-toolchain. On windows, this is %HOMEDRIVE%%HOMEPATH%\android-archives and %HOMEDRIVE%%HOMEPATH%\android-toolchain. These locations may be modified by creating a Configuration.Override.props file; see README.md for details. TL;DR: This setup is able to magically download the Android NDK and SDK files and install them for later use in a reasonably overridable location, all within MSBuild. [0]: http://www.joelonsoftware.com/articles/fog0000000043.html [1]: Though maybe there's some MSBuild-fu we can use to address that. [2]: https://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/android_callable_wrappers/ [3]: http://developer.android.com/sdk/index.html [4]: https://www.xamarin.com/download [5]: Because I couldn't find a reliable way to use $(SolutionDir) when only building a project, and relative paths would require an in-tree installation location, which might not work. 2016-04-19 03:33:04 +03:00			`*.userprefs`
			`bin`
			`Configuration.Override.props`
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) The commit implements building of LLVM and cross-compilers to support Xamarin.Android/Mono AOT. LLVM and cross-compilers can be built for both the host platform (Linux and OS/X at the moment) as well as cross-compiled for 32-bit and 64-bit Windows platforms. Windows builds are done with MXE toolchain on OS/X and with the packaged mingw-w64 toolchain on Linux (tested on Ubuntu 16.04 ONLY). Also introducing a new set of MSBuild properties that contain information about the host system. Some of those properties (HostOS, HostCC, HostCXX for instance) have been moved from Configuration.props to better support auto-detection. A new script, build-tools/scripts/generate-os-info, is invoked as part of `make prepare` to generate file that contains the new properties. The generated file is required for the build to work and is also host-specific (it mustn't be moved between different machines) Cross compiler builds require access to a configured Mono build tree, in order to generate C structure offsets header file that is used by the AOT compilers to properly generate AOT-ed binaries. Therefore, even if a JIT target is not enabled in the configuration, enabling a cross-compiler for some target will configure Mono for that JIT target but it will NOT build it, to save time. To facilitate this, the _MonoRuntimes items defined in build-tools/mono-runtimes/mono-runtimes.projitems gain an additional metadata item called `DoBuild` which will be set to `true` if the runtime actually needs to be built, as opposed to just configured. MXE builds are disabled on Linux as mingw-w64 works just fine. A `make prepare` warning is issued for Linux hosts which have the binfmt_misc module enabled and either Wine of Mono (cli) registered as PE32/PE32+ binary interpreters. In such instance building of the Windows cross-compilers will fail because Autotools determine whether software is being cross compiled by building a test program and attempting to execute it. In normal circumstances such an attempt will fail, but with Windows cross-compilation and either Wine or Mono registered to handle the PE32 executables this attempt will succeed thus causing the cross compilation detection to fail. Currently to build cross compilers on Linux you need to generate the C structure offsets header file on OS/X and copy the resulting headers to appropriate places on Linux. The header files should be placed in build-tools/mono-runtimes/obj/Debug/cross-*/ directories. The header files are: {cross-arm,cross-arm-win}/aarch64-v8a-linux-android.h {cross-arm64,cross-arm64-win}/armv5-none-linux-androideabi.h {cross-x86,cross-x86-win}/i686-none-linux-android.h {cross-x86_64,cross-x86_64-win}/x86_64-none-linux-android.h Offsets header generation doesn't work on Linux atm because of missing support for it in the Mono utility used to generate the offsets. Hopefully this limitation will be removed in the near future and a start-to-end build of everything will be possible on Linux. It is now mandatory to run at least `make prepare-props` before Xamarin.Android can be built. The target generates the OS-specific props file which is required by the build. `make prepare` depends on the target. 2016-07-26 16:27:31 +03:00			`Configuration.OperatingSystem.props`
[System.Drawing.Primitives] Add System.Drawing.Primitives.dll Facade (#121) Xamarin.Android needs to support [.NET Standard 1.6][0], which mentions a [`System.Drawing.Primitives.dll` assembly][1] which has not previously been supported or shipped. `System.Drawing.Primitives.dll` contains `System.Drawing.Point` and related typees, which Xamarin.Android places into `Mono.Android.dll`. Add a new `System.Drawing.Primitives.dll` assembly to use as a facade assembly, which contains [type forwarders][2] to "redirect" the types from `System.Drawing.Primitives.dll` to the corresponding types within `Mono.Android.dll`. [0]: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries [1]: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version [2]: https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx 2016-07-15 23:42:03 +03:00			`msfinal.pub`
[android-toolchain] Permit zero-configuration builds. This might be a suspect idea, but lets see if we can make this work. [The Joel Test: 12 Steps to Better Code][0] outlines 12 steps to better code. The first two steps are: 1. Do you use source control? 2. Can you make a build in one step? github is being used for source control, so (1) is handled, but how simple can we make (2)? How easy can we make it to build Xamarin.Android upon a fresh checkout? The ideal to strive for is simple: Load Xamarin.Android.sln into your IDE and Build the project. I know we're not going to be able to do this, if only because we're going to be using git submodules, which will require a separate `git submodule init` invocation [1]. Knowing we can't reach that level of simplicitly doesn't mean we shouldn't try to reach it for all other parts of the build system. Which brings us to the Android NDK and SDK. The Android NDK will be required in order to build native code, such as libmonodroid.so, while the Android SDK will be required in order to compile Java Callable Wrappers (née Android Callable Wrappers [2]) and eventual samples and unit tests. There are three ways we can deal with the Android NDK and SDK: 1. Complicate the "build" process by requiring that developers go to the Android SDK Download Page [3], download and install "somewhere" the required bits, and then configure the Xamarin.Android build to use these bits. 2. Complicate the "build" process by requiring that developers run the Xamarin Unified Installer [4], let it install everything required, then configure the Xamarin.Android build to use those bits. 3. Painstakingly determine which files are actually required, then automatically download and extract those files into a "well-known" location known by the Xamarin.Android build process. (1) and (2) can be infuriating. Let's give (3) a try. :-) Add a Xamarin.Android.Tools.BootstrapTasks project which contains MSBuild tasks to facilitate downloading the Android SDK and NDK files. Add an android-toolchain project which uses Xamarin.Android.Tools.BootstrapTasks to download a painstakingly determined set of files and install them "somewhere". Unfortunately [5] the "somewhere" to download and install these files needs to be in a known absolute path, so I've arbitrary decided to download the files into $(HOME)\android-archives and install them into $(HOME)\android-toolchain. On windows, this is %HOMEDRIVE%%HOMEPATH%\android-archives and %HOMEDRIVE%%HOMEPATH%\android-toolchain. These locations may be modified by creating a Configuration.Override.props file; see README.md for details. TL;DR: This setup is able to magically download the Android NDK and SDK files and install them for later use in a reasonably overridable location, all within MSBuild. [0]: http://www.joelonsoftware.com/articles/fog0000000043.html [1]: Though maybe there's some MSBuild-fu we can use to address that. [2]: https://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/android_callable_wrappers/ [3]: http://developer.android.com/sdk/index.html [4]: https://www.xamarin.com/download [5]: Because I couldn't find a reliable way to use $(SolutionDir) when only building a project, and relative paths would require an in-tree installation location, which might not work. 2016-04-19 03:33:04 +03:00			`obj`
			`packages`
[Xamarin.Android.Build.Tasks] Import from monodroid/301e7238 Added Xamarin.Android.Build.Tasks and its supporting Libraries. Code has also been updated to make uses of the new libraries in the Java.Interop repository Note : Xamarin.Android.Build.Tasks has a compile time code generation step which generates Profile.g.cs. This file contains the list of SharedRuntimeAssemblies. If building manually you will need to make sure that Xamarin.Android.Tools.BootstrapTasks is built first. 2016-04-25 18:44:32 +03:00			`.DS_Store`
[Xamarin.Android.Build.Tasks] First Pass at adding Unit tests for the MSBuild Tasks (#26) This commit adds basic support for the MSBuild Unit Tests. The goal of these tests is to ensure that the build of an android applicaition works consistently on all the supported platforms. The basic layout of a Unit test is as follows [Test] public void BuildReleaseApplication () { var proj = new XamarinAndroidApplicationProject () { IsRelease = true, }; using (var b = CreateApkBuilder (Path.Combine ("temp", TestContext.CurrentContext.Test.Name))) { Assert.IsTrue (b.Build (proj), "Build should have succeeded."); } } It is a standard Unit test. First we create a XamarinAndroidApplicatonProject and set its properties. You can use the proj to add new source files, references, assets, resources and nuget packages. By default you will get a standard "HelloWorld" android application. Once you have the project you will need to create either a Apk or Dll builder via the helper methods CreateApkBuilder CreateDllBuilder CreateApkBuilder will create an apk and by default will execute the `SignAndroidPackage` build target. the CreateDllBuilder will produce a dll. The source files are created in a temp directory relative to the build output of the unit tests. By default this is src/Xamarin.Android.Build.Tasks/UnitTests/Xamarin.Android.Build.Tests/bin/$(Configuraiton)/temp Once you have a builder you can then call Build passing in the project. There are also methods available for Clean and Save. Running any of these will cause the Unit test to shell out to xbuild/msbuild and attempt to build the project. Test results are written to a build.log file. If a unit test passes then the test directory is removed. If a test fails the directory and the build.log will be left in place for investigation. 2016-05-12 21:54:03 +03:00			`.nuget`
			`TestResult.xml`
[tests] Run .apk unit tests and collect TestResults.xml (#305) What do we want? Execution of unit tests! When do we want it? Uh...4 months ago? The `Xamarin.Android.NUnitLite` assembly allows writing NUnit-based unit tests that execute on-device, and the `Mono.Android-Tests.csproj` project contains a number of such unit tests. The problem is that these unit tests aren't executed as part of the Jenkins build process, so there's no way to know if a given commit actually breaks anything. In short, the existence of those unit tests is meaningless. The task, then, is to fix the `make run-all-tests` target so that it runs on-device unit tests...on an Android device. Which raises all manner of problems. :-) (Hence 4+ months!) For starters, our internal tooling is a horrible mish-mash of make(1), ruby(1), bash(1), which creates an emulator, launches it, installs the test .apk onto the emulator, and runs the tests. I don't want all of that "cruft" in this repo, which means it needs to be rewritten in a form more amenable to this repo: MSBuild tasks....and some make(1). :-) Add a new `build-tools/scripts/UnitTestApks.targets` file, which will process an `@(UnitTestApk)` Item Group to permit deploying, running, and undeploying test .apks from an attached Android device. Add a slew of MSBuild tasks to support `@(UnitTestApk)`. Update the default `$(AndroidSupportedTargetJitAbis)` value to be `armeabi-v7a:x86`. The created Android emulator is x86. 2016-11-21 23:44:37 +03:00			`TestResult-*.xml`
[build] Remove autogenerated resource files and clean a bit (#831) And add them to .gitignore. It will make the 'git diff' output lucider. Added few more performance measurement files to .gitignore as well 2017-09-08 18:26:12 +03:00			`TestResult-*.csv`
[android-toolchain] Windows build support (#743) * Bump LibZipSharp for Windows fixes Problems fixed on Windows: - Many `RequiredPrograms` are n/a on Windows - Setup `AndroidSdkItem` for Windows downloads - `AcceptAndroidSdkLicenses` should run `.bat` file on Windows - `UnzipDirectoryChildren` was running `/bin/mv` and hitting `PathTooLongException` while using `ZipFile.ExtractToDirectory` - references to `libzip.mdproj` are conditional on Windows, will be getting `libzip` from NuGet in the future UnzipDirectoryChildren: - on Windows we are using `System.IO.Compression` to extract directly into the destination and avoid `%TEMP%` to workaround `MAX_PATH` - Other platforms continue to use `unzip`, in order to preserve file attributes General changes: - gitignore for VS 2017 2017-08-23 18:27:35 +03:00			`.vs/`
[build] Remove autogenerated resource files and clean a bit (#831) And add them to .gitignore. It will make the 'git diff' output lucider. Added few more performance measurement files to .gitignore as well 2017-09-08 18:26:12 +03:00			`Resource.designer.cs`
			`logcat-*.txt`
			`apk-sizes-*.txt`