Tag Archives: Apps

Get ready for fall with Back-to-School Discounted Apps Collection in the Windows Store – The Fire Hose

If you’re getting ready for fall classes and activities, the Back-to-School Discounted Apps Collection in the Windows Store has some great deals.

They include 20 percent off Complete Anatomy in-app purchases, 30 percent off Stagelight in-app purchases and 50 percent off Movie Edit Plus Pro Windows Store Edition.

Find the Back-to-School Discounted Apps Collection in the Windows Store. Also, keep up with what’s hot, new and trending in the Windows Store on Twitter and Facebook.

Vanessa Ho
Microsoft News Center Staff

Tags: Windows Store

Mobile data theft a risk from shared app libraries

Researchers said shared third-party libraries used by many mobile apps could increase the risk of mobile data theft through “intra-library collusion.”

The issue was detailed by Alastair Beresford, teaching fellow at Robinson College in Cambridge, England, and Vincent Taylor and Ivan Martinovic, a doctoral student and associate professor, respectively at Oxford University, in the paper, “Intra-Library Collusion: A Potential Privacy Nightmare on Smartphones.”

According to the researchers, the issue has often been overlooked because mobile security “has typically examined apps and third-party libraries in isolation.” However, they claim these shared libraries could cause more damage if used together for mobile data theft.

“This attack, which we call intra-library collusion, occurs when a single library embedded in more than one app on a device leverages the combined set of permissions available to it to pilfer sensitive user data,” the researchers wrote. “The possibility for intra-library collusion exists because libraries obtain the same privileges as their host app and popular libraries will likely be used by more than one app on a device.”

The team studied 30,000 smartphones and found that, because different apps are allowed different permissions, a malicious actor could combine the access granted to each app in order to build a user profile or perform mobile data theft.

Matthew Rose, ‎global director of application security strategy at Checkmarx, an application security software vendor headquartered in Israel, said there were a number of ways a shared library might be infected by a malicious actor.

“Typically third-party libraries are maintained by a group of people who maintain the code base. Since these libraries have many contributors it is sometimes difficult to have one person responsible for the entire library code base which can potentially allow malicious code to be inserted,” Rose told SearchSecurity. “There is also the question of these libraries inheriting functionality from other code bases so there are definite tradeoffs in terms of risk versus the utilization of existing third party libraries.”

The researchers said advertising libraries could be granted additional permissions to make this kind of attack more dangerous. The researchers wrote that libraries can track users without their consent.

The research focused on Android due to “the availability of data on lists of apps installed on Android devices,” but the team noted that they believe their insights would also hold true on iOS “due to similarities in access control and app deployment.”

Neither Google nor Apple responded to requests for comment at the time of this post.

Mobile data theft and permission creep

Unfortunately, the researchers had no easy answers for mitigating the threat of mobile data theft from intra-library collusion. The researchers noted that one approach would be to limit the permissions granted to these libraries, but doing so might hamper the ability of developers to monetize their apps, which “could serve as a deterrent to new app developers entering the market and thus the end users may ultimately suffer from reduced content.”

If the permission request is not in line with what you intend to use the app for then do not install it or grant the permissions.
Matthew Roseglobal director of application security strategy, Checkmarx

Additionally, the team suggested that the companies running the app stores or even nation states could enact policies or laws to detect and remove malicious third-party libraries, but each approach would be problematic. Detection would be difficult because apps can have legitimate reasons for sending data off-device, and enforcement may not scale beyond an app-by-app basis.

John Bambenek, threat intelligence manager at Fidelis Cybersecurity, said “it is very likely that a malicious library would remain undetected,” but noted there are easier paths to mobile data theft.

“In order to perform this attack, a malicious individual would need to create a library that then is used by multiple applications. They would then need to convince users to download an app [or multiple apps] with many permissions,” Bambenek told SearchSecurity. “In the real world, a malicious individual would just get a victim to install an application with a lot of permissions in the first place because it is more direct and easier. I wouldn’t expect this to be weaponized in the short-term by criminals.”

Rose said the more important issue was that “people need to be cognizant of what permissions a mobile app is asking for when they install it.” 

“Does the app really need to have access to your file system, geo location, or camera? Think about what the intended usage is for the mobile app and ask yourself if it is asking for more permissions than it actually needs,” Rose said. “If the permission request is not in line with what you intend to use the app for then do not install it or grant the permissions.”

Bambenek said developers also need to be careful to make sure it doesn’t appear their apps are attempting mobile data theft through permissions overreach.

“Mobile developers, and developers in general for that matter, need to always focus on secure coding and, in particular, least privilege,” Bambenek said. “Adopting a development model that writes code doing only what is necessary for it to do and little else would help greatly.”

Oracle Cloud apps updated as Oracle extends EBS support

Oracle continues to push its cloud business with updates to Oracle Cloud apps. But the company is appeasing customers who prefer on premises by enhancing EBS support.

Oracle has updated its Oracle Cloud Applications with Release 13 to enhance its capabilities in customer experience, finance, HR and supply chain.

Oracle Supply Chain Management (SCM) Cloud received perhaps the biggest face-lift with the latest release, as Oracle introduced 200 features and six new products covering sales and operation planning, demand management, supply planning, collaboration, quality management and maintenance.

The update, analysts said, reiterated how much of a priority the cloud has become for Oracle, not just with these updated cloud applications, but also with other services, such as MySQL Cloud or the Oracle Mobile development platform.

“One of the key improvements across the suite of [Oracle] cloud applications is better insight, along with productivity and collaboration,” said Robert Sheldon, a technical consultant and TechTarget contributor.

“More and more, customers expect cloud-based services to provide ways of confirming how services are being used, what patterns are emerging and where bottlenecks might exist, along with other insights into the applications and users,” Sheldon said.

A major challenge that customers face is the lack of visibility across its business space, so the latest Oracle Cloud apps update aims to help prevent business planning from being exposed, an Oracle spokesperson said. Supply chain collaboration aims to streamline a business initiative through demand, sales and operations planning, and supply planning.

Oracle EBS support remains

As Oracle makes an even bigger push into the cloud, the company also revealed plans to expand its support for its E-Business Suite (EBS) product line until 2030. Oracle said another major release of E-Business Suite is expected at an undisclosed time.

“While we are not announcing a date for the future ’12.X’ release, we are committing to support it through 2030 at least,” the statement, released as a PDF on Oracle’s website said. It went on to say that “this update to the Oracle E-Business Suite roadmap should reassure customers who run critical operations on EBS that their system will continue to be supported and enhanced for years to come.”

For many EBS customers who haven’t yet dipped into the cloud, this comes as a much-welcomed relief.

“Oracle’s messaging and marketing is around cloud, so this is a question we get quite often: whether Oracle would discontinue its EBS support,” said Alyssa Johnson, president of the Oracle Applications Users Group (OAUG) in Dallas. “We’ve been able to reassure customers that are still using EBS products that Oracle is going to continue to support its on-premises products.”

Johnson pointed out that while Oracle’s tone of late has been focused on cloud, the company has also emphasized the hybrid model for its customers as far back as its annual OpenWorld conference last October, so it shouldn’t come as a total shock that Oracle has elected to extend its EBS support.

“We [at the OAUG] have always had a close relationship with [Oracle’s] product app teams, so we knew they were going to continue to support EBS even with their push into cloud products,” Johnson said. “They have a team specifically focused on on-premises licensing, and it helped to clarify with our members that Oracle will have support moving forward.”

Oracle’s central app design

Earlier this year, Oracle came under some heat after it doubled its cloud licensing requirements for Amazon Web Services and Azure customers.

The emphasis for Oracle cloud apps on understanding work flows is central to its design, and that shows in Release 13, Sheldon said.

“Rising expectations demand that customers — and, by extension, users — become a more central consideration when building applications,” he said.

In addition to updates to Oracle SCM, the company also updated its Customer Experience (CX) Cloud Suite, ERP Cloud and Human Capital Management (HCM) Cloud. As of Release 13, Oracle CX Cloud added features to its Oracle Sales Cloud with enhanced mobile and data visualization capabilities, while Oracle ERP Cloud now includes more functionalities, including Dynamic Discounting and Multi-Funding. Oracle HCM Cloud introduced expanded user personalization and branding, as well as tier 1 localization support.

Powered by WPeMatico

Configure your app to start at log-in

For a long time, desktop PC users have been able to configure Win32 apps to start at startup or user log-in. This has also been possible for Desktop Bridge apps since the Windows 10 Anniversary Update (v10.0.14393.0). We’ve now extended this feature to allow regular Universal Windows Apps to take part in this also. This is available in Insider builds from Build 16226 onwards, along with the corresponding SDK. In this post, we’ll look at the code changes you need to make in your manifest and in your App class to handle the startup scenario, and how your app can work with the user to respect their choices.

Here’s a sample app, called TestStartup – the app offers a button to request enabling the startup behavior, and reports current status. Typically, you’d put this kind of option into a settings page of some kind in your app.

The first thing to note is that you must use the windows.startupTask Extension in your app manifest under the Extensions node, which is a child of the Application node. This is documented here. The same Extension declaration is used for both Desktop Bridge and regular UWP apps – but there are some differences.

  • Desktop Bridge is only available on Desktop, so it uses a Desktop-specific XML namespace. The new UWP implementation is designed for use generally on UWP, so it uses a general UAP namespace (contract version 5) – although to be clear, it is currently still only actually available on Desktop.
  • The Desktop Bridge EntryPoint must be “Windows.FullTrustApplication,” whereas for regular UWP it is the fully-qualified namespace name of your App class.
  • Desktop Bridge apps can set the Enabled attribute to true, which means that the app will start at startup without the user having to manually enable it. Conversely, for regular UWP apps this attribute is ignored, and the feature is implicitly set to “disabled.” Instead, the user must first launch the app, and the app must request to be enabled for startup activation.
  • For Desktop Bridge apps, multiple startupTask Extensions are permitted, each one can use a different Executable. Conversely, for regular UWP apps, you would have only one Executable and one startupTask Extension.
Desktop Bridge App UWP App

xmlns:desktop="http://schemas.microsoft.com/
appx/manifest/desktop/windows10"


xmlns:uap5="http://schemas.microsoft.com/
appx/manifest/uap/windows10/5"


<desktop:Extension
  Category="windows.startupTask"
  Executable="MyDesktopBridgeApp.exe"
  EntryPoint="Windows.FullTrustApplication">
  <desktop:StartupTask
    TaskId="MyStartupId"
    Enabled="false"
    DisplayName="Lorem Ipsum" />
</desktop:Extension>


<uap5:Extension
  Category="windows.startupTask"
  Executable="TestStartup.exe"
  EntryPoint="TestStartup.App">
  <uap5:StartupTask
    TaskId="MyStartupId"
    Enabled="false"
    DisplayName="Lorem Ipsum" />
</uap5:Extension>

For both Desktop Bridge apps and regular UWP apps, the user is always in control, and can change the Enabled state of your startup app at any time via the Startup tab in Task Manager:

Also for both app types, the app must be launched at least once before the user can change the Disabled/Enabled state. This is potentially slightly confusing: if the user doesn’t launch the app and then tries to change the state to Enabled in Task Manager, this will seem to be set. However, if they then close Task Manager and re-open it, they will see that the state is still Disabled. What’s happening here is that Task Manager is correctly persisting the user’s choice of the Enabled state – but this won’t actually allow the app to be activated at startup unless and until the app is launched at least once first – hence the reason it is reported as Disabled.

In your UWP code, you can request to be enabled for startup. To do this, use the StartupTask.GetAsync method to initialize a StartupTask object (documented here) – passing in the TaskId you specified in the manifest – and then call the RequestEnableAsync method. In the test app, we’re doing this in the Click handler for the button. The return value from the request is the new (possibly unchanged) StartupTaskState.


async private void requestButton_Click(object sender, RoutedEventArgs e)
{
    StartupTask startupTask = await StartupTask.GetAsync("MyStartupId");
    switch (startupTask.State)
    {
        case StartupTaskState.Disabled:
            // Task is disabled but can be enabled.
            StartupTaskState newState = await startupTask.RequestEnableAsync();
            Debug.WriteLine("Request to enable startup, result = {0}", newState);
            break;
        case StartupTaskState.DisabledByUser:
            // Task is disabled and user must enable it manually.
            MessageDialog dialog = new MessageDialog(
                "I know you don't want this app to run " +
                "as soon as you sign in, but if you change your mind, " +
                "you can enable this in the Startup tab in Task Manager.",
                "TestStartup");
            await dialog.ShowAsync();
            break;
        case StartupTaskState.DisabledByPolicy:
            Debug.WriteLine(
                "Startup disabled by group policy, or not supported on this device");
            break;
        case StartupTaskState.Enabled:
            Debug.WriteLine("Startup is enabled.");
            break;
    }
}

Because Desktop Bridge apps have a Win32 component, they run with a lot more power than regular UWP apps generally. They can set their StartupTask(s) to be Enabled in the manifest and do not need to call the API. For regular UWP apps, the behavior is more constrained, specifically:

  • The default is Disabled, so in the normal case, the user must run the app at least once explicitly – this gives the app the opportunity to request to be enabled.
  • When the app calls RequestEnableAsync, this will show a user-prompt dialog for UWP apps (or if called from a UWP component in a Desktop Bridge app from the Windows 10 Fall Creators Update onwards).
  • StartupTask includes a Disable method. If the state is Enabled, the app can use the API to set it to Disabled. If the app then subsequently requests to enable again, this will also trigger the user prompt.
  • If the user disables (either via the user prompt, or via the Task Manager Startup tab), then the prompt is not shown again, regardless of any requests from the app. The app can of course devise its own user prompts, asking the user to make manual changes in Task Manager – but if the user has explicitly disabled your startup, you should probably respect their decision and stop pestering them. In the sample code above, the app is responding to DisabledByUser by popping its own message dialog – you can obviously do this if you want, but it should be emphasized that there’s a risk you’ll just annoy the user.
  • If the feature is disabled by local admin or group policy, then the user prompt is not shown, and startup cannot be enabled. The existing StartupTaskState enum has been extended with a new value, DisabledByPolicy. When the app sees DisabledByPolicy, it should avoid re-requesting that their task be enabled, because the request will never be approved until the policy changes.
  • Platforms other than Desktop that don’t support startup tasks also report DisabledByPolicy.

Where a request triggers a user-consent prompt (UWP apps only), the message includes the DisplayName you specified in your manifest. This prompt is not shown if the state is DisabledByUser or DisabledByPolicy.

If your app is enabled for startup activation, you should handle this case in your App class by overriding the OnActivated method. Check the IActivatedEventArgs.Kind to see if it is ActivationKind.StartupTask, and if so, case the IActivatedEventArgs to a StartupTaskActivatedEventArgs. From this, you can retrieve the TaskId, should you need it. In this test app, we’re simply passing on the ActivationKind as a string to MainPage.


protected override void OnActivated(IActivatedEventArgs args)
{
    Frame rootFrame = Window.Current.Content as Frame;
    if (rootFrame == null)
    {
        rootFrame = new Frame();
        Window.Current.Content = rootFrame;
    }

    string payload = string.Empty;
    if (args.Kind == ActivationKind.StartupTask)
    { 
        var startupArgs = args as StartupTaskActivatedEventArgs;
        payload = ActivationKind.StartupTask.ToString();
    }

    rootFrame.Navigate(typeof(MainPage), payload);
    Window.Current.Activate();
}

Then, the MainPage OnNavigatedTo override tests this incoming string and uses it to report status in the UI.


protected override void OnNavigatedTo(NavigationEventArgs e)
{
    string payload = e.Parameter as string;
    if (!string.IsNullOrEmpty(payload))
    {
        activationText.Text = payload;

        if (payload == "StartupTask")
        {
            requestButton.IsEnabled = false;
            requestResult.Text = "Enabled";
            SolidColorBrush brush = new SolidColorBrush(Colors.Gray);
            requestResult.Foreground = brush;
            requestPrompt.Foreground = brush;
        }
    }
}

Note that when your app starts at startup, it will start minimized in the taskbar. In this test app, when brought to normal window mode, the app reports the ActivationKind and StartupTaskState:

Using the windows.startupTask manifest Extension and the StartupTask.RequestEnableAsync API, your app can be configured to start at user log-in. This can be useful for apps which the user expects to use heavily, and the user has control over this – but it is still a feature that you should use carefully. You should not use the feature if you don’t reasonably expect the user to want it for your app – and you should avoid repeatedly prompting them once they’ve made their choice. The inclusion of a user-prompt puts the user firmly in control, which is an improvement over the older Win32 model.

Sample Code here.

How to Restart your App Programmatically

For some apps (especially games) it is not uncommon for the app to get into a state where it needs to restart – perhaps after a license update, after installing downloadable content, its caches have become corrupt or unwieldy, or for any other reason where the app needs to refresh state from scratch. In earlier releases, your only option would have been to prompt the user to close and relaunch, or to call CoreApplication.Exit – and both options provide sub-optimal user experience.

We have therefore introduced a new API that enables an app to request immediate termination and restart, and to pass arbitrary arguments into the fresh instance. In this post, we’ll look at how this works and how you can build it into your app. This is available now in Insider builds from Build 16226 onwards, along with the corresponding SDK.

Here’s a sample app, called TestRestart. 

The app provides a ListView of cities on the left, the currently-selected city on the right and a TextBox for providing arguments to the app when it is restarted. When the user taps the Request Restart button, the app will terminate and restart itself, passing in the supplied arguments. The new API, RequestRestartAsync, is exposed as a static method on the CoreApplication object. It takes a string parameter, which can be any string value you like – including input from the user or another external entity. If you do choose to accept input in this way, it is your responsibility to validate it correctly to make sure it conforms to whatever constraints you choose to impose. You should do this validation on input, before passing it to RequestRestartAsync. In this sample app, we’re expecting the user to type in the name of a city.


async private void DoRestartRequest()
{
    bool isValidPayload = false;
    string payload = restartArgs.Text;
    if (!string.IsNullOrEmpty(payload))
    {
        foreach (ImageViewModel imageItem in imageListView.Items)
        {
            if (imageItem.Name == payload)
            {
                isValidPayload = true;
                break;
            }
        }
    }

    if (isValidPayload)
    {
        AppRestartFailureReason result =
            await CoreApplication.RequestRestartAsync(payload);
        if (result == AppRestartFailureReason.NotInForeground ||
            result == AppRestartFailureReason.RestartPending ||
            result == AppRestartFailureReason.Other)
        {
            Debug.WriteLine("RequestRestartAsync failed: {0}", result);
        }
    }
}

To mitigate privacy concerns, an app is only permitted to restart itself if it is in the foreground at the time it makes the request. When the app restarts, it restarts with normal UI – that is, as a normal foreground window. If we were to permit a background task or minimized app to restart, the result would be unexpected to the user. This is why the API is framed as a request. If the request is denied, the app would need to handle the failure – perhaps by waiting until it is in the foreground and trying again. If you were to request a restart and then through some twist of logic managed to request it again before the system started the operation, then you’d get the RestartPending result, although this is an edge case. You’re unlikely to ever get the other result – unless something goes wrong in the platform.

Note that this is the only significant constraint, but you should use this API carefully. For example, you probably should not use it if your app was not originally launched by the user – for example, if it was launched as the result of a share or picker operation. Restarting in the middle of one of those contract operations would certainly confuse the user.

If the request is granted, the app is terminated and then restarted. There are many different ways to activate an app: in addition to a regular launch activation, apps can choose to support file activation, protocol activation, share or picker activation and so on. The list is documented here. For the restart case, the app will be activated as a regular launch – just as if the user had closed the app manually and tapped its tile to launch it again – but including the arbitrary arguments supplied earlier (if any).

In your App class, you should handle this by overriding the OnActivated method. Test the ActivationKind, and if it’s ActivationKind.Launch, then the incoming IActivatedEventArgs will be a LaunchActivatedEventArgs. From this, you can get hold of the incoming activation arguments. For a regular user-initiated launch, the Arguments will be empty, so if it’s not empty you could simply infer that this is a restart activation. You can also check the PreviousExecutionState, which for a restart operation will be set to Terminated.

Although the arguments might have originated from an untrusted source (eg, the user), you should have done the validation before requesting restart. If so, you can consider them trustworthy when you receive them in OnActivated.


protected override void OnActivated(IActivatedEventArgs args)
{
    switch (args.Kind)
    {
        case ActivationKind.Launch:
            LaunchActivatedEventArgs launchArgs = args as LaunchActivatedEventArgs;
            string argString = launchArgs.Arguments;

            Frame rootFrame = Window.Current.Content as Frame;
            if (rootFrame == null)
            {
                rootFrame = new Frame();
                Window.Current.Content = rootFrame;
            }
            rootFrame.Navigate(typeof(MainPage), argString);
            Window.Current.Activate();
            break;
    }
}

What you do with the incoming arguments is entirely up to you. In this app, we’re simply passing them on to the MainPage. In the MainPage in turn, we have an override of OnNavigatedTo which uses the string to select an item in the ListView:


protected override void OnNavigatedTo(NavigationEventArgs e)

{
    string payload = e.Parameter as string;
    if (!string.IsNullOrEmpty(payload))
    {
        foreach (ImageViewModel imageItem in imageListView.Items)
        {
            if (imageItem.Name == payload)
            {
                imageListView.SelectedItem = imageItem;
                break;
            }
        }
    }
}

As you can see, the CoreApplication.RequestRestartAsync method is a simple API. You can use it to terminate your app immediately, and have it restart as if by user action, with the additional option of passing in arbitrary arguments on activation.

Sample Code here.

Windows Store: video trailers, improved Store listings, advanced sales, and other new capabilities

At Build 2017, the Windows Store announced the initial availability of several features. Today, I want to share with you that all accounts have access to these features:

  • More ways to promote your apps and drive user acquisition
  • More ways to manage schedules, prices and sales
  • Debug your apps more effectively by using CAB files
  • Use Dev Center through a modern and efficient dashboard experience

Important: If you have a submission in progress, publish it (or delete it) and your next submission will show these new pricing, sales and store listing options. Also, if you use the Windows Store submission API, be sure to read the info at the bottom of this post.

More ways to promote your apps and drive user acquisition

Many of you told us that video trailers are one of the best ways to attract customers. You can now upload up to 15 trailers to use in your Store listing. When using trailers, make sure to also include the 1920 x 1080 pixel image (16:9) in the promotional images section, which shows up after the video stops playing. Feedback from other developers using videos has been very positive, try them out!

Video trailer as shown in the Store – see it in action here on a Windows 10 PC

Creating and updating Store listings used to take many steps per language and could take hours for a submission with listings in many languages. You can now update all Store listing content (description, images, keywords, etc.), by importing and exporting your listings, reducing the update time to just a few minutes.

Export and import of store listings – Submission overview page

More ways to manage prices and sales

 When a customer makes their first purchase, we’ve found that they typically continue to purchase more add-ons in that initial app or game, as well as in other products in the Store. The new pricing and availability page gives you additional options to drive users to that first purchase:

Schedule when your app or game will be visible (as long as the submission happens with enough time to process—we recommend at least three days in advance). You have the option to specify the schedule when your app should become available and discoverable in the Store, as well as a date when it should no longer be available for new acquisitions.

 Schedule availability – pricing and availability page

Schedule price changes in advance. For example, change the base price a month after the app has been published.

Schedule price changes – pricing and availability page

There are many more options to configure sales, including using percentage values (such as “30% off”), viewing sales options in the currency that makes sense to you, configuring sales globally or for specific markets, offering discounts to customers that own one of your other apps (for example “50% off if you own this other game”) and the ability to target a discount to a segment of customers (such as those that have not made any Store purchases so far).

Sales drive purchases, so try them out!

Configure sales – Pricing and availability page

How sales show up in the Store

We also heard that you wanted a more efficient way to understand all prices, for all markets. You can now view all possible price tiers in Excel. Go to the Pricing and availability page, select view table, and you can view and export the table to CSV.

Viewing all price tiers – Pricing and availability page

Use Dev Center through a modern and efficient dashboard experience

The Dev Center dashboard has been redesigned based on your feedback to help you be more productive. It has a clean new interface, beautiful analytics, new account-level pages, integrated app picker and streamlined program switching. These are a few of the things that make the new dashboard more useful, particularly for accounts with multiple apps, games or programs.

Dev Center redesign

Debug your apps more effectively by using CAB files

 We heard a lot of feedback on having access to CAB files to help debugging apps, and improve the quality and performance of your apps and games. The Health report lets you pinpoint which OS and app version configurations generate the most crashes, and provides links to failure details with individual CAB files. These CAB files are only available for customers running any of the Windows Insider flights of Windows 10 (slow or fast), so not all failures will include the CAB download option. 

Access to failure downloads – health analytics page

Implications of these changes if you are using the Windows Store submission API

If you use the Windows Store submission API to manage your apps and games, please be aware of the following:

  • If you manage prices using the Submission API, you’ll have to use new price tiers. To do that, manually update your app or game once, so you can view the new price tiers, accept them, and then update your Submission API code to use these new price tier values, which can be found in the price table on the pricing and availability page in Dev Center, as described above.
  • The Windows Store submission API does not support all the new Store listing capabilities You can add the new assets using the Dev Center dashboard, and the submission API will be updated later in July to let you manage these new assets through the API. More details about the upcoming API capabilities, including trailers and game options, can be found.
  • If you use the StoreBroker PowerShell module to simplify using the Windows Store submission API, you can keep using it to manage the same listing asset types you are managing today. However, you won’t be able to upload the new asset types using StoreBroker until the StoreBroker team publishes an update in a few more weeks, and you pick up that update.

Read this previous blog post to learn about all the recently added Store features, and try all the features that are live today. If you have any issues finding or using these features, please let us know using the feedback link in Dev Center (upper right of the dashboard).

Announcing UWP Community Toolkit 1.5

Today marks the sixth release of the UWP Community Toolkit – all packages are updated to version 1.5. Thanks to the UWP developer community, the UWP Community Toolkit has seen great improvements and stability to the existing controls and services. The community partnership has led to several new additions to this release.

To highlight a few of the new additions, the UWP Community Toolkit now includes:

  1. Menu: A classic control used by traditional desktop applications, adapted for the Universal Windows Platform. As requested by the community on UserVoice, the Menu allows the developer to provide a hierarchical list of menus and submenus that support any input modality and can adapt to the screen size to provide a natural and fluid interaction.
  2. OrbitView: A new ItemsControl that arranges elements around a center element and provides flexibility for size and distance for each element, as well as the ability to show orbits or anchors for each item.
  3. RadialProgressBar: A XAML Control that displays a value within a range using a circular sector that grows clockwise until it becomes a full ring. A fantastic variation of the ProgressBar.
  4. RoundImageEx: Similar to the ImageEx control, the RoundImageEx control downloads and locally caches images asynchronously while showing loading indicators. In addition, the RoundImageEx allows images to be clipped as circles.
  5. ExpressionBuilder: A type-safe way to build powerful composition ExpressionAnimation.
  6. BluetoothLEHelper: The BluetoothLEHelper class provides functionality to easily enumerate, connect to and interact with Bluetooth LE Peripherals.

For a complete overview of what’s new in version 1.5, please read our release notes on GitHub.

The release of Windows 10 Creators Update (build 10.0.15063) has enabled several new APIs that make it possible to improve several controls used in apps targeting the latest update. Therefore, several packages are now targeting the Windows 10 Creators Update and can take advantage of these new APIs. We encourage all developers using the toolkit to update their apps to the latest version of the UWP Community Toolkit.

As a reminder, the UWP Community Toolkit can be used in any UWP app across PC, Xbox One, mobile, HoloLens and Surface Hub devices. You can get started by following this tutorial, or preview the latest features by installing the UWP Community Toolkit Sample App from the Windows Store.

If you would like to contribute, please join us on GitHub!

UWP App Diagnostics

At Build this year, we gave a sneak preview of a set of new APIs designed to provide diagnostic information about running apps. You can see the videos here and here – but note that these were based on a pre-release implementation. So, while the Build videos are still correct on broad functionality, the final API names are almost all slightly different. Plus, we added a couple of extra features after Build.

The final versions for the upcoming release are available in the Insider builds from Build 16226, along with the corresponding SDK.

At a high level, these APIs allow an app to:

  • Enumerate a list of running apps, including UWP apps, Win32 apps, system services and so on.
  • For each app, get process-specific metrics on:
    • Memory usage (private commit and working set).
    • CPU usage.
    • Disk reads and writes.
  • For each UWP app, get additional metrics on:
    • Memory usage (including shared commit) equivalent to the Windows.System.MemoryManager report previously available to an app for its own usage.
    • State info: running, suspending, suspended, not running.
    • Energy quota info: under or over.
    • Enumerate a list of any background tasks that are active for the app, including name, trigger type and entry point.
    • Enumerate all the processes for the app (using an enhancement to the existing Windows.System.Diagnostics.ProcessDiagnosticInfo class that was previously restricted to an app for its own usage).

The API has a simple hierarchical structure:

  • The AppDiagnosticInfo type represents a single app. Callers would normally request either a single AppDiagnosticInfo for the app you’re interested in or a list of AppDiagnosticInfos if you’re interested in multiple apps.

  • Once you’ve gotten hold of an AppDiagnosticInfo for an app you’re interested in, you’d call GetResourceGroups to get a list of AppResourceGroupInfo objects. Each AppResourceGroupInfo corresponds to a resource group. An app can define resource groups in its manifest as a way to organize its components (foreground app, background tasks) into groups for resource management purposes. If you don’t define any explicit resource groups, the system will provide at least one (for the foreground app) plus potentially more (if you have out-of-proc background tasks, for example).

  • From there, you’d call any of the AppResourceGroupInfo methods to get snapshot reports of memory usage, execution and energy quota state, and the app’s running background tasks (if any) via the AppResourceGroupMemoryReport, AppResourceGroupStateReport and AppResourceGroupBackgroundTaskReport classes.

  • And finally, each group exposes a list of ProcessDiagnosticInfo objects.

As you can see from the class diagrams, the AppDiagnosticInfo and ProcessDiagnosticInfo each have a link to the other. This means you can get all the rich process-specific info for any running process and get the UWP-specific info for any process related to a UWP app (including Desktop Bridge apps).

These APIs are intended to support app developers who either need more diagnostic support during their own app development and testing, or who want to build a general-purpose diagnostic app and publish it in the Windows Store. Exposing information about other apps raises potential privacy concerns, so if your app uses these APIs, you’ll need to declare the appDiagnostics capability in your manifest, along with the corresponding namespace declaration:


<Package
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/ windows10/restrictedcapabilities"
  IgnorableNamespaces="uap mp rescap">
  ...

  <Capabilities>
    <rescap:Capability Name="appDiagnostics" />
  </Capabilities>
</Package>

This is a restricted capability: If you submit an app with this capability to the Windows Store, this will trigger closer scrutiny. The app must be in the Developer Tools category, and we will examine your app to make sure that it is indeed a developer tool before approving the submission.

At run time, the capability also triggers a user-consent prompt the first time any of the diagnostic APIs are called:

The user is always in control: If permission is denied, then the APIs will only return information about the current app. The prompt is only shown on first use, but the user can change his or her mind any time via the privacy pages in Settings. All apps that use the APIs will be listed here, and the user can toggle permission either globally or on a per-app basis:

Given the richness of the APIs, it’s not too much of a stretch to envisage creating a UWP version of Task Manager. There are a few features that we can’t implement just yet (terminating apps and controlling system services, for example), but certainly most of the data reporting is perfectly possible with the new APIs:

The first thing to do is to request permission to access diagnostics for other apps using AppDiagnosticInfo.RequestAccessAsync. The result could be Denied, Limited (which means you can only get information for the current app package) or Allowed.


DiagnosticAccessStatus diagnosticAccessStatus = 
    await AppDiagnosticInfo.RequestAccessAsync();
switch (diagnosticAccessStatus)
{
    case DiagnosticAccessStatus.Allowed:
        Debug.WriteLine("We can get diagnostics for all apps.");
        break;
    case DiagnosticAccessStatus.Limited:
        Debug.WriteLine("We can only get diagnostics for this app package.");
        break;
}

Then, to emulate Task Manager, you’d start with a list of the ProcessDiagnosticInfo objects for all running processes.


IReadOnlyList<ProcessDiagnosticInfo> processes = ProcessDiagnosticInfo.GetForProcesses();

For each running process, you can extract the top-level process-specific information such as the ExecutableFileName and the ProcessId. You can also get the more detailed process information from each of the three reports for CpuUsage, MemoryUsage and DiskUsage.


if (processes != null)
{
    foreach (ProcessDiagnosticInfo process in processes)
    {
        string exeName = process.ExecutableFileName;
        string pid = process.ProcessId.ToString();

        ProcessCpuUsageReport cpuReport = process.CpuUsage.GetReport();
        TimeSpan userCpu = cpuReport.UserTime;
        TimeSpan kernelCpu = cpuReport.KernelTime;

        ProcessMemoryUsageReport memReport = process.MemoryUsage.GetReport();
        ulong npp = memReport.NonPagedPoolSizeInBytes;
        ulong pp = memReport.PagedPoolSizeInBytes;
        ulong peakNpp = memReport.PeakNonPagedPoolSizeInBytes;
        //...etc

        ProcessDiskUsageReport diskReport = process.DiskUsage.GetReport();
        long bytesRead = diskReport.BytesReadCount;
        long bytesWritten = diskReport.BytesWrittenCount;
        //...etc
    }
}

For any process associated with a UWP app, the IsPackaged property is true. So, for each of these, you can get from the ProcessDiagnosticInfo to the AppDiagnosticInfo. It might seem strange that we can get AppDiagnosticInfos (plural) from a process – but this is to allow for the possibility that a single process is associated with more than one app. That’s an extremely uncommon scenario, but it is possible in the case of VoIP apps where two or more apps in the same package can share a component running in a separate process at run time. In almost all cases, though, there will only be one AppDiagnosticInfo per process.


if (process.IsPackaged)
{
    IList<AppDiagnosticInfo> diagnosticInfos = process.GetAppDiagnosticInfos();
    if (diagnosticInfos != null && diagnosticInfos.Count > 0)
    {
        AppDiagnosticInfo diagnosticInfo = diagnosticInfos.FirstOrDefault();
        if (diagnosticInfo != null)
        {
            IList<AppResourceGroupInfo> groups = diagnosticInfo.GetResourceGroups();
            if (groups != null && groups.Count > 0)
            {

From the AppDiagnosticInfo, you can walk down the hierarchy and get a collection of AppResourceGroupInfos. Then, for each AppResourceGroupInfo, you can get the UWP-specific state and memory information:


AppResourceGroupInfo group = groups.FirstOrDefault();
if (group != null)
{
    string name = diagnosticInfo.AppInfo.DisplayInfo.DisplayName;
    string description = diagnosticInfo.AppInfo.DisplayInfo.Description;
    BitmapImage bitmapImage = await GetLogoAsync(diagnosticInfo);

    AppResourceGroupStateReport stateReport= group.GetStateReport();
    if (stateReport != null)
    {
        string executionStatus = stateReport.ExecutionState.ToString();
        string energyStatus = stateReport.EnergyQuotaState.ToString();
    }

    AppResourceGroupMemoryReport memoryReport = group.GetMemoryReport();
    if (memoryReport != null)
    {
        AppMemoryUsageLevel level = memoryReport.CommitUsageLevel;
        ulong limit = memoryReport.CommitUsageLimit;
        ulong totalCommit = memoryReport.TotalCommitUsage;
        ulong privateCommit = memoryReport.PrivateCommitUsage;
        ulong sharedCommit = totalCommit - privateCommit;
    }
}

Note: to get the packaged logo from the app, there’s a little extra work. You call GetLogo from the AppDisplayInfo to return the data as a stream; if there are multiple logos available, this will return the largest one that is within the specified size.


private async Task<BitmapImage> GetLogoAsync(AppDiagnosticInfo app)
{
    RandomAccessStreamReference stream = 
        app.AppInfo.DisplayInfo.GetLogo(new Size(64, 64));
    IRandomAccessStreamWithContentType content = await stream.OpenReadAsync();
    BitmapImage bitmapImage = new BitmapImage();
    await bitmapImage.SetSourceAsync(content);
    return bitmapImage;
}

Once you’ve collected all the various detailed metrics you’re interested in, it’s a simple matter to populate your viewmodel for data-binding purposes, to perform data analytics or to do whatever other processing you might want.

In a later post, we’ll look at how you can integrate the diagnostic APIs with existing developer tools such as Visual Studio and Appium.

Monetizing your app: Set your COPPA settings for your app

The Children’s Online Privacy Protection Act (COPPA) prohibits operators of commercial websites and online services (including mobile apps) from targeting children below the age of 13 using targeted ads. The Dev Center provides an option for an app developer to specify whether an app or ad unit is targeted to children.

We reminded our developer community back in 2015 to set their application COPPA settings, but several developers have not set their COPPA settings correctly. Doing so greatly affects the revenue that a developer can earn on apps that are not targeted to children under the age of 13.

If a developer selects the COPPA compliance option that his app is directed at children under 13, Microsoft will disable its behavioral advertising services when delivering advertising to the app. If a developer’s app is directed at children under the age of 13, he or she must select this option in “Monetize with ads” under the Monetization section in Dev Center for that specific application.

However, if your app does not target children under 13, then targeted ads are a great way to monetize, so make sure you select the right COPPA setting depending on your app’s content and target audience.

Note that developers may have other legal obligations under COPPA. You should review the FTC’s guidance and consult with your legal counsel regarding COPPA obligations.

Stay tuned for additional tips to increase ad monetization!

How to distribute your existing Desktop Applications via Windows Store to Windows 10 PCs – including the new Windows 10 S configuration

Overview

Windows 10 S is a specific configuration of Windows 10 Pro that offers a familiar, productive Windows experience that’s streamlined for security and performance. By exclusively using apps in the Windows Store and ensuring that you browse safely with Microsoft Edge, Windows 10 S keeps you running fast and secure day in and day out. Windows 10 S was inspired by students and teachers and it’s the best Windows ever for schools. It’s also a great choice for any Windows customer looking for consistent performance and advanced security. By limiting apps to those in the Windows Store, Windows 10 S is ideal for people who have everything they need in the Windows Store and prefer the peace of mind that comes with removing the risk of downloading apps from other places.

What do I do with my existing non-Store app? Desktop Bridge is the answer

With the Desktop Bridge you can easily package your current desktop application or game as an .appx, distribute through the Windows Store and target all Windows Desktop devices including Windows 10 S to increase your user reach and easier monetization.

You can package any desktop application such as: WPF, WinForms, MFC, VB6, etc.

Once completed, your users will enjoy from smooth installation and update experiences: Clean, simple and fast install/uninstall updates via differential packages, streaming and many more.

Now you can also modernize your app with the Universal Windows Platform (UWP) to increase user engagement and reach all Windows devices.

We have a lot of customers that already went through the process such as: Kodi, Slack, Evernote, Adobe Photoshop Elements 15 and many others.

Here are few customers that shared their stories:

  1. MusiXmatch is the world’s largest lyrics platform with millions of lyrics available online and more than 50 million users on various platforms
  2. Tale of Wuxia (侠客风云传) is a traditional desktop Win32 role-playing game (RPG) that was created by Heluo Studio
  3. CLIP STUDIO PAINT is the leading paint tool software that supports creation of animation and manga

A quote from Evernote:

“The Desktop Bridge vastly simplifies our [Evernote] installer and uninstaller. It also opens up UWP APIs including Live Tiles and notifications. And having the full-featured Evernote app in the Windows Store means future improvements will reach users faster.”

—Seth Hitchings, VP Engineering, Evernote

What should I do next?

  1. Register as an app developer in the Windows Dev Center
  2. Prepare to package your application
  3. Sign up and get started using the Desktop Bridge
  4. Package your current desktop application as an .appx
  5. Test your Windows app for Windows 10 S, you can also check out this blog post for more details
  6. Submit your app to the Windows Store

Resources

Did you find this post helpful? Please let us know in the comments below—and also let us know if there’s anything else you’d like us to dig into for you about this topic.

Enjoy!