* [Build] Remove submodule
* [Build] Use GitInfo to set Assembly metadata
* [Build] Remove extra prop
* [Build] Update version
* [Build] Update versions to be consistent with existing Build.Tasks
* [Build] Update build number
* [Build] make sure build tasks gets info
* [Build] Add assembly info unit test
* [Test] Refactor test for gitinfo on vsts
Context: https://github.com/xamarin/xamarin-android/issues/2982
The Blank Xamarin.Forms app template in VS 2019 takes longer to build
than in VS 2017. A little research is showing that this is due to use
of the 28.x support libraries... For example, the build includes ~20
*more* jar files in the template from 2019 than 2017. The
`_CompileDex` step alone goes from ~15.2s to ~18.2s.
This lead me down the road of investigating if we can remove any
support libraries by default in Xamarin.Forms apps. I am also seeing
if there is more we can do in Xamarin.Android for this problem, in
general.
It looks like we can remove:
* Xamarin.Android.Support.v7.MediaRouter
* Xamarin.Android.Support.Media.Compat
Neither of these appear to be used, but have been listed as
dependencies of Xamarin.Forms for a long time.
~~ Results ~~
I made these changes, then did a `Debug` build of
`Xamarin.Forms.ControlGallery.Android.csproj` for comparison.
Comparing dex file sizes (in bytes):
Before:
3428092 classes.dex
3265616 classes2.dex
6693708 total
After:
4938000 classes.dex
1098772 classes2.dex
6036772 total
This looks like it could potentially save ~600KB of compiled dex code
on every Xamarin.Forms app.
Comparing methods:
Before:
classes.dex 11,492 methods
classes2.dex 19,451 methods
total 30,943 methods
After:
classes.dex 22,171 methods
classes2.dex 7,635 methods
total 29,806 methods
~1,137 methods removed, which should help with the dex limit.
Comparing APK sizes (in bytes):
Before:
26442597 AndroidControlGallery.AndroidControlGallery-Signed.apk
After:
25741701 AndroidControlGallery.AndroidControlGallery-Signed.apk
~700KB smaller APK, due to less .NET assemblies & dex code.
Comparing build time (this was using dx):
Before:
19785 ms CompileToDalvik 1 calls
After:
18532 ms CompileToDalvik 1 calls
Looks like it saved over a second of build time for this project.
Seems like an "easy win", let's do this!
* Enable "treat warnings as errors"
* Remove unnecessary for loop
* Remove properties which already exist in base class
* Make property hiding explicit and obsolete hiding property
* Move Treat Warnings as Errors setting to props file
* Fix weird quotation changes in Xamarin.Forms.Build.Tasks.csproj
* Scrub empty WarningsAsErrors tags
* Remove unused variable
* Fix TearDown method hiding in UI tests
* Fix Id member hiding in test for Bugzilla32871
* Fix RootPage member hiding in Bugzilla51503
* Fix RooPage member hiding in Issue1483
* Disable warnings for deprecated OpenGL calls
* Fix member hiding in test view models
* Fix RootPage member hiding in Issue1931
* Fix Id member hiding in Bugzilla42620
* Fix AutomationId member hiding in Bugzilla57114
* Fix Layout member hiding in Bugzilla40911
* Remove unused variables from Bugzilla31114
* Remove unused variable
* Fix various unused variable warnings
* Disable warning to leave example code for reference
* Fix unused variable from macOS test
* Remove unused members
* Fix unused variable warnings
* Fixed unused property warnings
* Fix warnings for unused code
* Disable 'await' warning
* Remove unused variable
* Adding pragma directives for await warnings
* Remove member hiding
* Turn off global "Treat warnings as errors" in other platforms
* Use MarkerId instead of obsolete Id member
* Fix await warnings in WPF GeocoderBackend
* Add missing await
* Disable warning for unused event
* Use the auto-generated constants
* [Visual] Work on the Material Frame
* Improving the code for the sample
* Added a controller to help with frames that have additional padding
- Android MaterialCardView does not use the default padding to determine where the content starts, rather it uses the content padding of the view because there is a border that does not affect the content
* [Visual] Added a few extra checks on Android to reduce unnecessary interop
* [Visual] A few more frame changes and some button tweaks
* [Visual] use the themers on iOS and save default properties
* [Visual] Add placeholders for themer and cache defaults
* [Visual] Added the material slider for iOS
- Android does not have a custom control, so uses the existing renderer
* [enhancements] Move from duplicate LoadImageAsync code to GetNativeImageAsync
* [visual] Updated the controls to use the new iOS bits
* [visual] some fixes for material components
* [visual] Added hacks for material alerts
* [visual] removing the alert changes for the main branch
* [visual] Update the MaterialComponents NuGet
* [visual] Rework the theming/customization of Material controls on iOS
* [visual] fix the places where the user colors were being changed
* [visual] Improve the ColorStateList management for Android
* [visual] Re-implemented the Android ProgressBar as a fast, material renderer
* Material Entry
* [visual] Add Android ActivityIndicator
* filter out material layouts for 8.1
* remove folder
* fix __ANDROID_28__
* MaterialContextThemeWrapper
* [visual] remove the `IFrameController` interface
* [visual] reverting the changes to the Frame layout
* [visual] reverting whitespace
* [visual] make sure to raise both property changed
* formatting changes
* fixing colors on android to match with ios themes
* Update Xamarin.Forms.Platform.Android/Material/MaterialButtonRenderer.cs
Co-Authored-By: mattleibow <mattleibow@live.com>
* fix sizing of entry with infinite width size request
* update to release 28 of support
* Update Xamarin.Forms.Platform.Android/Resources/values/styles.xml
Co-Authored-By: PureWeen <shane94@hotmail.com>
* Update Xamarin.Forms.Platform.Android/Resources/values/styles.xml
Co-Authored-By: PureWeen <shane94@hotmail.com>
* PR Comment changes
* Visual
* add progress bar and fix ui tint color
* Progress Bar Updates
* ios padding fixes
* padding fix and button image positioning fixes
* added button themes
* disable tint and open up material android button
* change image to bank
* add overrides for Material Frame Renderer
* remove commented out code
* change back to Full linker
* applying comment fixes
* change comparison
Currently, on the first build of a "Hello World" Xamarin.Forms app,
you will see this in the build log:
ConvertDebuggingFiles
Parameters
Files
C:\Users\myuser\.nuget\packages\xamarin.forms\3.1.0.697729\lib\MonoAndroid10\FormsViewGroup.pdb
C:\Users\myuser\.nuget\packages\xamarin.forms\3.1.0.697729\lib\MonoAndroid10\Xamarin.Forms.Platform.Android.pdb
OutputItems
_ConvertedDebuggingFiles
C:\Users\myuser\.nuget\packages\xamarin.forms\3.1.0.697729\lib\MonoAndroid10\FormsViewGroup.dll
C:\Users\myuser\.nuget\packages\xamarin.forms\3.1.0.697729\lib\MonoAndroid10\Xamarin.Forms.Platform.Android.dll
The logging is a little weird here, but this `ConvertDebuggingFiles`
MSBuild task takes about 100ms on my machine.
What is it doing?
The Mono debugger can support two types of debugging files:
- `mdb` files
- "portable" `pdb` files
If Xamarin.Android's build finds a "non-portable" `pdb` file, we have
to run it through this task to convert to an `mdb` file... This gives
us proper stacktraces for `FormsViewGroup.dll` and
`Xamarin.Forms.Platform.Android.dll`.
You can change the type of debugging symbols in your project with the
`DebugType` setting, which has these options:
- Blank or `None`: don't generate symbols. (Although Xamarin.Android
has funny behavior here, see:
https://github.com/xamarin/xamarin-android/issues/2282)
- `Full` generates an `mdb` file, this is a Windows-proprietary format
for debug builds
- `PdbOnly` generates a "non-portable" `pdb` file, a
Windows-proprietary format for release builds
- `Portable` generates a "portable" pdb file, which is the new
standard that works for debug and release builds. New SDK-style
MSBuild projects use this option by default.
These values are not case sensitive, I have mostly seen them lower
case in newer projects.
So what does Xamarin.Forms need to do?
Use `<DebugType>portable</DebugType>` in any Android class library or
app project. Other platforms, this is optional, not as much benefit. I
have heard that `DebugType=portable` might cause a problem on UWP.
* Xamarin.Forms will ship "portable" `pdbs` in its NuGet package for
`FormsViewGroup.dll` and `Xamarin.Forms.*.Android.dll`. Developers
won't pay the 100ms on initial build.
* Initial build times for `Xamarin.Forms.sln` will be slightly better
for development, although I didn't measure the difference here.
* Disable AndroidUseLatestPlatformSdk in VS so VS stops auto-updating Android projects;
Remove XF.targets imports from projects which don't need it;
Make XF.targets imports conditional on existence of XFBT DLL in VS to avoid errors
* More consistent check for VS
* Apply nicer VS check logic to Xamarin.Forms.Xaml.UnitTests.csproj
* Fix missing "'"
* Re-add XF.targets imports to PagesGallery native projects
* Update repro to include header/footers with bound props
* [Android] Clear renderers of ListView header/footers
And don't call `RemoveAllViews`, because that causes the ObjectDisposedExceptions.
* Android AppLinks updated packages and refactor to comply with Firebase packages
* made nested classes internal
* removed notimplementedexception and added a Console log when on Failure
* removed Firebase init method. Changed Console for Android's native Exception logging
* formatted code styling with Visual Studio Community 2017 for Mac
* [Android] Update nuspec and gallery
* [Packages] Update android support packages for 25.4.0.2
Rui Marinho
Jonathan Peppers
Matthew Leibowitz
E.Z. Hart
Shane Neuville
Sean Davies
E.Z. Hart
Stephane Delcroix
Samantha Houts
Samantha Houts
kingces95
Paul DiPietro
Jason Smith