Mango supports a gyroscope, but it is optional. The reason for this is that all current phones will support Mango, but they don't have gyros. All new devices should have a gyro. Also support for another SoC was added. Otherwise the requirements are the same as they were for 7.0
In the API front there are new HW APIs: access to camera, motion sensor, compass and gyro.
The camera can be accessed via two APIs: PhotoCamera API supports HQ photos, flash/focus modes etc. Webcam API allows recording video and audio. The former works with a pull model and the latter with a push model.
Compass is available on some pre-Mango phones, but not all. It works if it works, like usual. With my iPhone and Google Maps I usually get an error that's like 30 degrees. So it's useless. I probably should use it only in some deep forest?
Motion Sensor is a virtual sensor that combines gyro, compass and accelerometer. It's more accurate, faster in response and has low drift. it can also disambiguate motion types and has fall-back if there is no gyro in the device. Microsoft recommends using Motion Sensor when available. If you don't have a compass, the API does not work and you should use accelerometer directly.
The OS checks if calibration is needed, the application should show a UI for it. There is a reference implementation that can be copy&pasted directly.
Mango runs Silverlight 4. No breaking changes for apps that work with 7.0. Implicit styles, RichTextBox, ViewBox, more touch events (tap, double tap). If you recompile the app for Mango, there are some changes that have to be taken into account, like WebClient (returns in the thread it was called in, not in UI thread) and background running.
Sockets, Clipboard, IME, IE9 Browser, VideoBrush.
Performance: Gen GC means much faster garbage collecting and less lag, Input Thread means better touch input since it's different from the UI thread, Working set, Profiler tool is available with the SDK. Don't profile the emulator, it's naturally useless. And you can't profile 7.0 apps.
Sockets support TCP, UDP with uni/multicast on wifi. Connection manager control overrides and/or sets preferences e.g. if you always need to communicate through wifi. WebClient allows full HTTP header access and returns in the originating thread and not the UI thread.
XNA inside Silverlight App. Integration at the page level, XNA takes over the rendering. Integration at element level, Silverlight elements in XNA pipeline via UIElementRenderer. Input is shared. So now you can do XNA-3D in your Silverlight app or do your XNA game UIs with Silverlight.
Local database! SQL Compact Edition. LINQ to SQL to query, filter, sort. Object model for CRUD. Application level access, so it's sandboxed from other applications. Background agents can access the database. And there's a DatabaseSchemaUpdater APIs for upgrades since there is no direct SQL access.
Fast Application Resume. Apps are not thrown out of memory immediately, at most five apps are held in memory and only "tombstoned" if memory is low etc. So now switching apps is faster. And old apps will continue working, no problem.
Multi-tasking is available, but Microsoft wants to make sure the power usage is minimal and user experience is good. This is why there is no "real" multi-tasking.
The options are: bg transfer service, bg audio, bg agents (periodic and on idle), alarms and reminders.
Using BG audio you have to start playing the sound from a foreground application. A bg app cannot start play but can continue playing. Application will be shut down, but a separate agent will continue running and provide the sound and handle next/prev etc.
BG audio app types: URL PlayList and Stream Source. Former just tells which URLs to play, the latter will provide audio buffers and can have custom decryption/decompression.
BG agents are periodic or on idle. They are initialized in foreground but run on background. They persist across reboots! User controls through control panel and there can be at maximum 18 running periodic agents. Agent runs for up to 14 days but it can be renewed. This is just because if you don't run the application in two weeks, you probably won't even be using it. You can set a smaller run time limit if you want to. The timer is reset every time the app is run.
Periodic agent runs around every 30 minutes and they get around 15 seconds of time. It must have less than 6MB of memory and less than 10% CPU (limits subject to change before RTM).
On Idle agents run when on external power and non-cell network. They can run for 10 minutes and can use more CPU but less than 6MB of memory.
BG agent functionality allowed: tiles, toast, location, network, R/W isolated storage, sockets, most framework APIs.
BG agent functionality disallowed: display UI, XNA, microphone, camera, sensors, play audio (only BG audio APIs).
Agents continue running until the agent itself aborts it, the time limit (default 14 days) is met or the user removes it via the control panel. If you try to add a bg agent and there are already 18 running, there is an exception. The user must remove some agent to allow your app to create one.
One application can have only one idle agent, one bg agent and one bg audio handler. The agents can run whatever tasks they like, but there can only be one of each.
Time-based on-phone notifications. Supports alerts and reminders, persist across reboots and adheres to user settings. Alarms are modal, snooze/dismiss, sound customization, no app invocation, no stacking. Reminders have rich information, integrate with other reminders, snooze/dismiss, launches app if clicked.
Background Transfer Service
Start transfer in foreground, complete in background, even if app is closed. Queue persists across reboots and has a limit of 5. Single service for all applications, FIFO. Upload limit around 4MB, downloading more than 20MB only when using wifi. The files are transferred to isolated storage. The 5 file limit is per application, so other apps can download even if your app has its queue full. The FIFO system is global.
Local tile APIs have full control of ALL properties. You can update the tile information from your app or background agent and don't have to use push notifications etc.
You can also create multiple tiles per application. The tiles can deep link, which means you can add parameters to the tiles so that they start the application in some other place than the front page.
No API changes, but lots of enhancemens on the reliability, efficiency and performance. Better radio usage, faster state machine, smarter queuing etc. Nothing for the developer itself.
The user can have 30 applications using push notifications at one time now, previously the limit was 15.
This is one of the great things. You can integrate Bing Search results with your app. There are four item types: movies, places, events and products. The search will show a card for the item and any application can register itself as being able to handle this information. You can e.g. tell the system that you can handle movies and the user can start your application to e.g. buy the movie online directly from the search results.
You can read contacts and calendar entries, but you can't write data. You can start a launcher that saves data, but that requires user interaction.
7.0 apps will run nicely with Mango. But if you really want to get the nice features, target Mango already and be ready. Especially the fast task switching is nice for any application.