Requisitos do pacote de aplicativos para o aplicativo MSIX
Requisitos
Siga estas diretrizes para preparar os pacotes do seu aplicativo para envio à Microsoft Store.
Antes de criar o pacote do seu aplicativo para a Microsoft Store
Certifique-se de de testar seu aplicativo com o kit de certificação de aplicativos do Windows. Também recomendamos que você teste seu aplicativo em diferentes tipos de hardware. Observe que, até certificarmos seu aplicativo e disponibilizá-lo na Microsoft Store, ele só poderá ser instalado e executado em computadores que tenham licenças de desenvolvedor.
Compilando o pacote do aplicativo usando o Microsoft Visual Studio
Se você estiver usando o Microsoft Visual Studio como seu ambiente de desenvolvimento, já tem ferramentas internas que tornam a criação de um pacote de aplicativo um processo rápido e fácil. Para obter mais informações, confira Pacote de aplicativos.
Observação
Certifique-se de que todos os seus nomes de arquivos usem ANSI.
Ao criar seu pacote no Visual Studio, verifique se você está conectado com a mesma conta associada à sua conta de desenvolvedor. Algumas partes do manifesto do pacote têm detalhes específicos relacionados à sua conta. Essas informações são detectadas e adicionadas automaticamente. Sem as informações adicionais incluídas no manifesto, você pode encontrar falhas de carregamento de pacote.
Quando você cria os pacotes UWP do seu aplicativo, o Visual Studio pode criar um arquivo .msix ou appx ou um arquivo .msixupload ou .appxupload. Para aplicativos UWP, recomendamos que você sempre carregue o arquivo .msixupload ou .appxupload na página Pacotes . Para obter mais informações sobre como colocar aplicativos UWP em pacotes para a Store, consulte Colocar um aplicativo UWP no pacote com o Visual Studio.
Os pacotes do seu aplicativo não precisam ser assinados com um certificado enraizado em uma autoridade de certificação confiável.
Pacotes de aplicativos
Para aplicativos UWP, o Visual Studio pode gerar um pacote de aplicativos (.msixbundle ou .appxbundle) para reduzir o tamanho do aplicativo a ser baixado pelos usuários. Isso pode ser útil se você tiver definido ativos específicos de idioma, uma variedade de ativos de escala de imagem ou recursos que se aplicam a versões específicas do Microsoft DirectX.
Observação
Um pacote de aplicativos pode conter seus pacotes para todas as arquiteturas.
Com um pacote de aplicativos, um usuário baixará apenas os arquivos relevantes, em vez de todos os recursos possíveis. Para obter mais informações sobre pacotes de aplicativos, consulte Colocar aplicativos em pacotes e Colocar um aplicativo UWP no pacote com o Visual Studio.
Compilar o pacote do aplicativo manualmente
Se não usar o Visual Studio para criar seu pacote, você deve criar o manifesto do pacote manualmente.
Certifique-se de revisar a documentação do manifesto do pacote do aplicativo para obter os detalhes e requisitos completos to manifesto. Seu manifesto deve seguir o esquema de manifesto do pacote para passar na certificação.
Seu manifesto deve incluir algumas informações específicas sobre sua conta e seu aplicativo. Você pode encontrar essas informações consultando Ver detalhes da identidade do aplicativo na seção Gerenciamento do produto da página de visão geral do seu aplicativo no painel.
Observação
Os valores no manifesto diferenciam maiúsculas de minúsculas. Espaços e outras pontuações também devem corresponder. Insira os valores cuidadosamente e revise-os para garantir que estejam corretos.
Os pacotes de aplicativos (.msixbundle ou .appxbundle) usam um manifesto diferente. Revise a documentação do Manifesto do pacote para obter os detalhes e os requisitos para manifestos do pacote de aplicativos. Observe que em um .msixbundle ou .appxbundle, o manifesto de cada pacote incluído deve usar os mesmos elementos e atributos, exceto para o atributo ProcessorArchitecture do do elemento Identity.
Dica
Certifique-se de executar o kit de certificação de aplicativos do Windows, antes de enviar seus pacotes. Isso pode ajudar a determinar se o manifesto tem algum problema que possa causar falhas de certificação ou de envio.
Requisitos de formato do pacote
Os pacotes do seu aplicativo devem estar em conformidade com esses requisitos.
Propriedade do pacote do aplicativo | Requisito |
---|---|
Tamanho do pacote | .msixbundle ou .appxbundle: máximo de 25 GB por pacote Pacotes .msix ou .appx destinados ao Windows 10 ou Windows 11: máximo de 25 GB por pacote |
Bloquear hashes de mapa | Algoritmo SHA2-256 |
Versões suportadas
Para aplicativos UWP, todos os pacotes devem ter como destino uma versão do Windows 10 ou do Windows 11 suportada pela Store. As versões suportadas pelo pacote devem ser indicadas nos atributos MinVersion e MaxVersionTested do elemento TargetDeviceFamily do manifesto do aplicativo.
Arquivo XML StoreManifest
StoreManifest.xml é um arquivo de configuração opcional que pode ser incluído em pacotes de aplicativos. Seu objetivo é habilitar recursos, como declarar seu aplicativo como um aplicativo de dispositivo da Microsoft Store ou declarar requisitos dos quais um pacote depende para serem aplicáveis a um dispositivo, que o manifesto do pacote não cobre. Se usado, o StoreManifest.xml é enviado com o pacote do aplicativo e deve estar na pasta raiz do projeto principal do aplicativo. Para obter mais informações, consulte Esquema StoreManifest.
Numeração de versão do pacote
Cada pacote fornecido deve ter um número de versão (fornecido como um valor no atributo Version do elemento Pacote/Identidade do manifesto do aplicativo). A Microsoft Store impõe certas regras relacionadas a números de versão, que funcionam de forma um pouco diferente em diferentes versões do sistema operacional.
Observação
Este tópico refere-se a "pacotes", mas, a menos que indicado, as mesmas regras se aplicam aos números de versão para arquivos .msix/.appx e .msixbundle/.appxbundle.
Numeração de versão para pacotes do Windows 10 e 11
Importante
Para pacotes do Windows 10 ou Windows 11 (UWP), a última (quarta) seção do número da versão é reservada para uso na Store e deve ser deixada como 0 quando você compilar o pacote (embora a Store possa alterar o valor nessa seção). As outras seções devem ser definidas como um inteiro entre 0 e 65535 (exceto a primeira seção, que não pode ser 0).
Ao escolher um pacote UWP do envio publicado, a Microsoft Store sempre usará o pacote com a versão mais alta aplicável ao dispositivo Windows 10 ou Windows 11 do cliente. Isso oferece maior flexibilidade e o coloca no controle sobre quais pacotes serão fornecidos aos clientes em tipos de dispositivos específicos. É importante ressaltar que você pode enviar esses pacotes em qualquer ordem. Você não está limitado a fornecer pacotes com versões mais altas a cada envio posterior.
Você pode fornecer vários pacotes UWP com o mesmo número de versão. No entanto, os pacotes que compartilham um número de versão também não podem ter a mesma arquitetura, porque a identidade completa que a Store usa para cada um dos pacotes deve ser exclusiva. Para obter mais informações, consulte Identidade.
Quando você fornece vários pacotes UWP que usam o mesmo número de versão, a arquitetura (na ordem x64, x86, Arm, neutral) será usada para decidir qual deles é de classificação mais alta (quando a Store determina qual pacote fornecer ao dispositivo de um cliente). Ao classificar pacotes de aplicativos que usam o mesmo número de versão, a classificação de arquitetura mais alta dentro do pacote é considerada: um pacote de aplicativos que contém um pacote x64 terá uma classificação mais alta do que um que contém apenas um pacote x86.
Isso lhe dá muita flexibilidade para evoluir seu aplicativo ao longo do tempo. Você pode carregar e enviar novos pacotes que usam números de versão mais baixos para adicionar suporte a dispositivos Windows 10 ou Windows 11 para os quais você não fornecia suporte anteriormente, pode adicionar pacotes com versões mais altas que têm dependências mais rígidas para aproveitar os recursos de hardware ou sistema operacional ou pode adicionar pacotes com versões mais altas que servem como atualizações para parte ou toda a sua base de clientes existentes.
O exemplo a seguir ilustra como a numeração de versão pode ser gerenciada para entregar os pacotes pretendidos aos seus clientes por meio de vários envios.
Exemplo: Mudando para um único pacote em vários envios
O Windows 10 permite que você escreva uma única base de código que é executada em todos os lugares. Isso torna o início de um novo projeto multiplataforma muito mais fácil. No entanto, por vários motivos, talvez você não queira mesclar bases de código existentes para criar um único projeto imediatamente.
Você pode usar as regras de controle de versão de pacotes para mudar gradualmente seus clientes para um único pacote da família de dispositivos Universal, enquanto envia várias atualizações provisórias para famílias de dispositivos específicas (incluindo aquelas que aproveitam as APIs do Windows 10). O exemplo abaixo ilustra como as mesmas regras são aplicadas consistentemente em uma série de envios para o mesmo aplicativo.
Envio | Contents | Experiência do cliente |
---|---|---|
1 | - Versão do pacote: 1.1.10.0 - Família de dispositivos: Windows.Desktop, minVersion 10.0.10240.0 |
– Dispositivos na compilação Windows 10 e 11 Desktop 10.0.10240.0 e acima receberão 1.1.10.0 - Outras famílias de dispositivos não poderão comprar e instalar o aplicativo |
2 | - Versão do pacote: 1.1.10.0 - Família de dispositivos: Windows.Desktop, minVersion 10.0.10240.0 - Versão do pacote: 1.0.0.0 - Família de dispositivos: Windows.Universal, minVersion 10.0.10240.0 |
– Dispositivos na compilação Windows 10 e 11 Desktop 10.0.10240.0 e acima receberão 1.1.10.0 – Outras famílias de dispositivos (não desktop) que forem introduzidas receberão 1.0.0.0 – Os dispositivos desktop que já têm o aplicativo instalado não verão nenhuma atualização porque já têm a melhor versão disponível, isto é, 1.1.10.0, e são posteriores a 1.0.0.0 |
3 | - Versão do pacote: 1.1.10.0 - Família de dispositivos: Windows.Desktop, minVersion 10.0.10240.0 - Versão do pacote: 1.1.5.0 - Família de dispositivos: Windows.Universal, minVersion 10.0.10250.0 - Versão do pacote: 1.0.0.0 - Família de dispositivos: Windows.Universal, minVersion 10.0.10240.0 |
– Dispositivos na compilação Windows 10 e 11 Desktop 10.0.10240.0 e acima receberão 1.1.10.0 – Outras famílias de dispositivos (não desktop) introduzidas com a compilação 10.0.10250.0 e acima receberão 1.1.5.0 - Outras famílias de dispositivos (não desktop) quando introduzidas com build >=10.0.10240.0 e < 10.010250.0 receberão 1.1.0.0 – Os dispositivos desktop que já têm o aplicativo instalado não verão nenhuma atualização porque eles já têm a melhor versão disponível, isto é, 1.1.10.0, que já é posterior a 1.1.5.0 e 1.0.0.0) |
4 | - Versão do pacote: 2.0.0.0 - Família de dispositivos: Windows.Universal, minVersion 10.0.10240.0 |
– Todos os clientes em todas as famílias de dispositivos na compilação v10.0.10240.0 e acima do Windows 10 e 11 receberão o pacote 2.0.0.0 |
Observação
Em todos os casos, os dispositivos do cliente receberão o pacote que tem o número de versão mais alto possível para o qual eles se qualificam. Por exemplo, no terceiro envio acima, todos os dispositivos desktop receberão a v1.1.10.0, mesmo que tenham a versão do sistema operacional 10.0.10250.0 ou posterior e, portanto, também poderiam aceitar a v1.1.5.0. Como 1.1.10.0 é o número de versão mais alto disponível para eles, esse é o pacote que eles receberão.
Usar a numeração de versão para reverter para um pacote enviado anteriormente para novas aquisições
Se você mantiver cópias de seus pacotes, terá a opção de reverter o pacote do seu aplicativo na Store para um pacote anterior do Windows 10, se descobrir problemas com uma versão. Essa é uma maneira temporária de limitar a interrupção para seus clientes, enquanto você corrige o problema.
Para fazer isso, crie um novo envio. Remova o pacote problemático e carregue o pacote antigo que você deseja fornecer na Store. Os clientes que já receberam o pacote que você está revertendo ainda terão o pacote problemático (já que seu pacote mais antigo terá um número de versão anterior). Mas isso impedirá que qualquer outra pessoa adquira o pacote problemático, permitindo que o aplicativo ainda esteja disponível na Store.
Para corrigir o problema para os clientes que já receberam o pacote problemático, você pode enviar um novo pacote do Windows 10 que tenha um número de versão maior do que o pacote incorreto, assim que puder. Após esse envio passar pelo processo de certificação, todos os clientes serão atualizados para o novo pacote, já que ele terá um número de versão maior.
Idiomas com suporte
Você pode enviar aplicativos para a Microsoft Store em mais de 100 idiomas.
Para saber mais sobre como configurar idiomas em seus aplicativos, consulte Globalização e localização e Compreender os idiomas do perfil do usuário e os idiomas do manifesto do aplicativo. Também temos um kit de ferramentas de aplicativo multilíngue para ajudá-lo a escrever aplicativos compatíveis com vários idiomas.
Lista de idiomas com suporte
Estes são os idiomas suportados pela Microsoft Store. Seu aplicativo deve ser compatível com pelo menos um desses idiomas.
Os códigos de idioma que não estão incluídos aqui não são suportados pela Store. Recomendamos que você não inclua pacotes direcionados a códigos de idioma diferentes dos listados abaixo. Esses pacotes não serão distribuídos aos clientes e podem causar atrasos ou falhas na certificação.
Nome do idioma | Códigos de idioma com suporte |
---|---|
Árabe | ar, ar-sa, ar-ae, ar-bh, ar-dz, ar-eg, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sy, ar-tn, ar-ye |
Africâner | af, af-za |
Albanês | sq, sq-al |
Amárico | am, am-et |
Armênia | hy, hy-am |
Assamês | as, as-in |
Azerbaidjano | az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az |
Basco (País Basco) | eu, eu-es |
Bielorrusso | be, be-by |
Bangla | bn, bn-bd, bn-in |
Bósnio | bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba |
Búlgaro | bg, bg-bg |
Catalão | ca, ca-es, ca-es-valencia |
Cherokee | chr-cher, chr-cher-us, chr-latn |
Chinês (simplificado) | zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg |
Chinês (tradicional) | zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw |
Croata | hr, hr-hr, hr-ba |
Tcheco | cs, cs-cz |
Dinamarquês | da, da-dk |
Dari | prs, prs-af, prs-arab |
Holandês | nl, nl-nl, nl-be |
Português do Brasil | en, en-au, en-ca, en-gb, en-ie, en-in, en-nz, en-sg, en-us, en-za, en-bz, en-hk, en-id, en-jm, en-kz, en-mt, en-my, en-ph, en-pk, en-tt, en-vn, en-zw, en-053, en-021, en-029, en-011, en-018, en-014 |
Estoniano | et, et-ee |
Filipino | fil, fil-latn, fil-ph |
Finlandês | fi, fi-fi |
Francês | fr, fr-be , fr-ca , fr-ch , fr-fr , fr-lu, fr-015, fr-cd, fr-ci, fr-cm, fr-ht, fr-ma, fr-mc, fr-ml, fr-re, frc-latn, frp-latn, fr-155, fr-029, fr-021, fr-011 |
Galego | gl, gl-es |
Georgiano | ka, ka-ge |
Alemão | de, de-at, de-ch, de-de, de-lu, de-li |
Grego | el, el-gr |
Guzerate | gu, gu-in |
Hausa | ha, ha-latn, ha-latn-ng |
Hebraico | he, he-il |
Híndi | hi, hi-in |
Húngaro | hu, hu-hu |
Islandês | is, is-is |
Igbo | ig-latn, ig-ng |
Indonésio | id, id-id |
Inuktitut (Latino) | iu-cans, iu-latn, iu-latn-ca |
Irlandês | ga, ga-ie |
isiXhosa | xh, xh-za |
isiZulu | zu, zu-za |
Italiano | it, it-it, it-ch |
Japonês | ja , ja-jp |
canarim | kn, kn-in |
Cazaque | kk, kk-kz |
Khmer | km, km-kh |
Quiché | quc-latn, qut-gt, qut-latn |
Quiniaruanda | rw, rw-rw |
KiSwahili | sw, sw-ke |
Concani | kok, kok-in |
Coreano | ko, ko-kr |
Curdo | ku-arab, ku-arab-iq |
Kyrgyz | ky-kg, ky-cyrl |
Lao | lo, lo-la |
Letão | lv, lv-lv |
Lituano | lt, lt-lt |
Luxemburguês | lb, lb-lu |
Macedônio | mk, mk-mk |
Malaio | ms, ms-bn, ms-my |
Malaiala | ml, ml-in |
Maltês | mt, mt-mt |
Maori | mi, mi-latn, mi-nz |
Marati | mr, mr-in |
Mongol (Cirílico) | mn-cyrl, mn-mong, mn-mn, mn-phag |
Nepali | ne, ne-np |
Norueguês | nb, nb-no, nn, nn-no, no, no-no, |
Oriá | or, or-in |
Persa | fa, fa-ir |
Polonês | pl, pl-pl |
Português (Brasil) | pt-br |
Português (Portugal) | pt, pt-pt |
Panjabi | pa, pa-arab, pa-arab-pk, pa-deva, pa-in |
Quíchua | quz, quz-bo, quz-ec, quz-pe |
Romeno | ro, ro-ro |
Russo | ru , ru-ru |
Gaélico escocês | gd-gb, gd-latn |
Sérvio (latino) | sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs |
Sérvio (cirílico) | sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs |
Soto setentrional | nso, nso-za |
Setsuana | tn, tn-bw, tn-za |
Sindhi | sd-arab, sd-arab-pk, sd-deva |
Sinhala | si, si-lk |
Eslovaco | sk, sk-sk |
Esloveno | sl, sl-si |
Espanhol | es, es-cl, es-co, es-es, es-mx, es-ar, es-bo, es-cr, es-do, es-ec, es-gt, es-hn, es-ni, es-pa, es-pe, es-pr, es-py, es-sv, es-us, es-uy, es-ve, es-019, es-419 |
Sueco | sv, sv-se, sv-fi |
Tadjique (Cirílico) | tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn |
Tâmil | ta, ta-in |
Tártaro | tt-arab, tt-cyrl, tt-latn, tt-ru |
Télugo | te, te-in |
Tailandês | th, th-th |
Tigrinya | ti, ti-et |
Turco | tr, tr-tr |
Turcomeno | tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr |
Ucraniano | uk, uk-ua |
Urdu | ur, ur-pk |
Uyghur | ug-arab, ug-cn, ug-cyrl, ug-latn |
Uzbeque (latino) | uz, uz-cyrl, uz-latn, uz-latn-uz |
Vietnamita | vi, vi-vn |
Galês | cy, cy-gb |
Wolof | wo, wo-sn |
Ioruba | yo-latn, yo-ng |
Windows developer