Опубликованное приложение – Как опубликовать через RemoteAPP свое приложение

Как опубликовать через RemoteAPP свое приложение

Итого как я начал свое изучение работы системы Server 2012 R2 Std меня пока многое не радует, а именно то что вроде как сложнее стало использование RemoteAPP и разворачивание терминального сервера на этой оси, но отступать ни в коем случае нельзя. Хоть и не удобно работать пока во всяком случае, а изучать нужно — это и повышение квалификации и новые требования к соискателям, да и переходить на новый функционал также необходимо или по крайней мере иметь ввиду. Вот сейчас я для себя разберу как создать свое приложение на терминальном сервере и опубликовать его во всех шагах с которыми мне пришлось столкнуться.

По правильному все нужно настраивать самим чтобы быть уверенным в используемом конечно если Вы такой же как и я ответственный системный администратор.

Как Вы уже помните в прошлой заметке  когда я знакомился с RemoteAPP по умолчанию для всех пользователей домена создана коллекция с дефолтным именование:

QuickSessionCollections, так вот ее нужно будет удалить.

Запускаю оснастку «Server Manager» — Win + X → Control Panel — Administrative Tools, после переходу в апплет Remote Desktop Services — Collections и в правой части через выделение дефолтной коллекции по правом клику нажимаем Remove Collection — Yes

Вот теперь уже лучше ничего дефолтного нет, начну пожалуй с создания своей собственной коллекции. Все также находясь в апплете Remote Desktop Services — Collections — TASKS — Create Session Collection и передвигаюсь за мастером настройки по шагам:

Before You Begin, Next

Collection Name:

• Name: → polygon
• Description: → кто как хочет я же люблю чтобы все было подписано.

И нажимаю Next

RD Session Host:

выделяю текущий сервер и нажатием по стрелочке предопределяю что система выбрана в пуле;

И нажимаю Next

User Groups: нужно указать на кого будет распространена новая коллекция, либо на пользователя и/или же на группу, либо на всех пользователей домена. Лучше будет если только тем кому надо предоставлен доступ, так правильнее.

Add… — ввожу alektest (и себя не забываю ekzorchik) нажимаю Check Names после OK, конечный результат данного шага выглядит так:

И нажимаю Next

User Profile Disks: можно указать местонахождение профиля пользователя и его размер, в моей задачи это пока не требуется, а потому я снимаю галочку Enable user profile disks

И нажимаю Next

Confirmation: проверяю по результирующему выводу настройки сделанные выше и если все

OK, то нажимаю Create

Ожидаю когда моя коллекция — polygon создастся

И нажимаю Close

Теперь когда коллекция создана пора переходить к созданию приложения.

Запускаю оснастку «Server Manager» — Win + X → Control Panel — Administrative Tools, после переходу в апплет Remote Desktop Services — Collections — Polygon — Tasks (RemoteAPP Programs) — Publish RemoteApp Programs и идем по шагам за мастером:

RemoteApp Programs: в правой части будут указаны все приложения которые установлены на данном терминальном сервере если же в списке не оказало того которое необходимо его можно добавить — Add…

(Установил клиент 1С на терминальный сервер версию клиента 8.2.19.121)

у меня при указании местонахождения исполняемого файла 1С => 1cv8.exe

сработал аларм о не возможности :

Дело в том, что я указал путь просто: C:\Program Files (x86)\1cv82\8.2.19.121\bin\1cv8.exe (как я думал наивно что это: 1C Enterprise 8 (thin client), а это не правильный формат об этом как раз ошибка и говорит, нужно указать путь вот в таком вот формате:

\\srv-serv.polygon.local\c$\Program Files (x86)\1cv82\common\1cestart.exe

добавленное приложение будет отмечено в списке как показано на представленном ниже скриншоте

И нажимаю Next

Confirmation: проверяю и после нажимаю Publish

Completion: если Вы как и Я видите надпись: The selected RemoteApp programs were published successfully for the polygon collection, то значит Вы только что опубликовали свое первое приложение.

И нажимаю Close

Теперь проверяю с клиентской станции собственно как выглядит подключение к рабочей области (об это я уже говорил в прошлой заметке) и запуск опубликованного приложения в виде 1С клиента):

Windows 7 Professional SP1 (user&pass: alektest&Aa1234567)— IE — https://srv-serv.polygon.local/rdweb после ввода логина и пароля в рабочую область получаем гордо одинокое приложение клиента 1С доступное этому пользователю:

Когда мы запускаем приложение, то в правом нижнем углу экрана возле часов появляется пиктограмма указывающая, что сейчас мы работаем на удаленном терминальном сервере:

И вот оно долгожданное окно первого запуска клиента 1с, раз первый раз пользователь alektest запускает клиент то он не настроен ни на какой кластер 1с, настроив раз больше уже не понадобиться.

Настроив клиент и авторизовавшись при подключении у кластера 1С получаем запущенное приложение как будто бы оно было запущено локально за одним лишь исключение, что ресурсов на терминальном сервере много больше чем на рабочей станции.

На заметку: первый раз потребуется ввести доменные административные идентификационные данные дабы на сервер прописались ключи и файлы защиты для этого будет выведено специальное окно ввода логина и пароля.

Пример запущенного клиента 1С — он ничем не отличается от локального запуска:

Это конечно все хорошо, а как быть на других рабочих местах, что каждый раз заходить по URL ссылке и оттуда запускать, вот бы как ранее экспортировать приложение в виде rdp или msi

файла. Загвоздка вот в чем, в оснастке Server Manager на терминальном сервере данная функциональная возможность не предусмотрена, а потому дальнейшие шаги проделываем на самом сервере:

Win + X — Control Panel — RemoteApp and Desktop Connections — Access RemoteApp and desktops — указываю URL подключения вида:

Email address or connection URL: https://srv-serv.polygon.local/RDWeb/Feed/WebFeed.aspx

и нажимаем Next, Next вот только не все так просто как кажется на первый взляд, удаленный компьютер отверг мое подключение:

Исправляюсь: — создаю самоподписанный сертификат для текущего сервера:

Запускаю оснастку «Server Manager» — Win + X → Control Panel — Administrative Tools, после переходу в апплет Remote Desktop Services — Collections — TASKS — Edit Deployment Properties — Certificates — выделяю

RD Web Access — Create new certificate…

• Certificate name: srv-serv.polygon.local
• Password: 712mbddr@

Allow the certificate to be added to the Trusted Root Certification Authorities certificate store on the destination computers отмечаю галочкой

Store this certificate: Отмечаю галочкой и указываю путь где куда его нужно сохранить на сервере дабы потом распространить на рабочие станции

Certificate path: c:\srv-serv.pfx

По такому же принципу можно создать сертификаты и для остальных ролей сервисов RD

И нажимаю OK — Apply

И нажимаю OK

Win + X — Command Prompt (Admin) — mmc — File — Add/Remove Snap-in… — находим оснастку Certificates

— нажимаем Add Computer Account — Next — Finish и OK, здесь нужно перенести текущий сертификат сервера srv-serv.polygon.local из Personal в Trusted Root Certification Authorities\Certificates

Далее повторяем шаги по подключению через Панель управления на самом сервере к RemoteAPP (Control Panel — RemoteApp and Desktop Connections) и вот уже другое разнообразие запрашивается

И вуаля все проходит успешно

 

Нажимаю Finish

И вот к чему я так стремился:

После того, как было настроено удаленное подключение к RemoteAPP в системе становится доступным следующий каталог:

Вот собственно и всё по шагам которые нужно сделать, что опубликовать свое собственное приложение целью которого будет организовать в последствии терминальный сервер с собственным набором приложений которые используют ресурсы самого сервера, а не ресурсы рабочих станций. Да и управлять единым способом намного удобнее чем каждый раз бегать и вручную что-то проделывать. Да интересно, но когда одну и туже операцию проделываешь не один десяток раз хочется добавить в свою жизнь автоматизации. Пока я подведу черту в этой заметке она работоспособна и практична. На этом я прощаюсь и до новых встреч, с уважением автор блога — ekzorchik.

www.ekzorchik.ru

Доступ к приложениям в окне через RemoteAPP

Итак всем привет и хорошего дня, сегодня я покажу на практике, как сделать следующее:

Задача: на терминальном сервере активировать службу RemoteAPP

и опубликовать приложение клиента 1С на подключение к развернутому кластеру 1C.

Предварительные действий:

На сервер установлен гипервизор ESXi, а уже внутри него под каждую задачу развернуты виртуальные системы:

Но пока как заготовка, терминальный сервер я разверну на сервере базы данных и кластере 1С (все на одной машине).

На терминальном сервере рекомендую пользовательский профили вынести на отдельный диск вместо системного:

Для чего нужен RemoteAPP – это технология расширения функционала терминального сервера посредством которой можно вместо того, чтоб каждому пользователю настраивать удаленное подключение где он будет работать с приложениями (Почта, 1С, печать и другими) сделать так чтобы у него на компьютере был вынесен ярлык через который запускается удаленная сессия с запуском опубликованного приложения.

К примеру: у меня сейчас два офиса, в одном (он же главный) располагается кластер 1с + база и терминальный сервер и вместо того, чтобы пользователи через удаленный рабочий стол заходили на терминальный сервер из другого офиса (это каждому нужно настраивать профиль: вывести ярлыки программ, организовать печать, обеспечить интернетом (а по соображениями безопасности я этого сделать не могу, просто так надо) у них на своих рабочих компьютерах настроен ярлык на запуск только опубликованного приложения. В рамках этой заметки я покажу на практике как это выглядит.

Создаю приложение которое будет опубликовано с использованием RemoteAPP на терминальном сервере:

Start – Control Panel – Administrative Tools – Server Manager – Roles – Remote Desktop Services – RemoteApp Manager (srv-host.nemdomb.local) – запускаю мастер: Add RemoteApp Programs, нажимаю Next, следующим шагом показывается какие текущие установленные приложения на терминальном сервере могут выступить в роли опубликованных через RemoteAPP, выбираю самое первое 1С Предприятие через нажатием на кнопку Properties можно:

• переименовать добавляемое приложение
• Изменить путь запуска до исполняемого файла
• Изменить алиас
• Настроить запуск клиента 1С с опциями запуска (к примеру подключение к опеределенной базе под определенным пользователем и паролем: /ENTERPRISE /S “1ccluster\base” /N “test” /P “test” — Здесь подключение к кластеру с именем 1ccluster, base – название базы, test test – пользователь и пароль в этой базе)

Я же в рамках этой заметки не буду настраивать ничего в свойствах, а просто выбираю приложение: —

Нажимаю на кнопку Next и перехожу к этапу мастера где отображается результирующая информация по настройкам публикуемого приложения, если все правильно и ничего не нужно изменять нажимаю Finish

Следующим шагом нужно экспортировать RemoteAPP созданное приложение с целью распространить на компьютеры пользователям которые будут с ним работать, делает это так, выделяется приложение и через правый клик на нем вызываются свойства.

Опубликованное приложением можно экспортировать, как rdp файл настроенного подключение так и как msi пакет (можно поставить локально его на компьютере пользователя или же через GPO установить)

Если выбрать экспорт в виде RDP файла: Create .rdp File, по умолчанию путь куда предлагает мастер экспорта сохранить rdp файл подключения: C:\Program Files\Packaged Programs, но никто не мешает изменить данный путь на любой другое более удобный. Я оставляю по умолчанию

Следующим шагом также выводится результирующая информация – если все хорошо то нажимаем кнопку Finish и откроется explorer местонахождения экспортированного файла опубликованного приложения 1С, если открыть свойства данного rdp файла, то можно обнаружить что в настройки подключения к терминальному сервере уже автоматически подставляются аутентификационные данные текущей сессии на компьютере:

Теперь копирую данный файл: 1cv8s.rdp на рабочую станцию с которой пользователь alektest будет взаимодействовать клиентом 1С Предприятие.

На заметку: чтобы передать файл простым копирование через проводник:

\\w7x86\с$ на рабочей станции в настройках брандмауера должны быть включены входящие правила:

• Общий доступ к файлам и принтерам (входящий трафик SMB) – Профиль (Домен).
• Общий доступ к файлам и принтерам (эхо-запрос – входящий трафик ICMPv4) – Профиль (Домен)

На заметку: пользователи которые задействуют RemoteAPP приложения на терминальном сервере должны быть в группе Remote Desktop Users

Запускаю на рабочей станции Windows 7 (W7X86) переданный файл предварительно авторизовавшись в системе под учетной записью alektest

На следующем шаге ввожу пароль на авторизацию на терминальном сервере: (Практичнее будет использовать SSO, т.е. авторизация на терминальном сервере с использование доменной учетной записи, а на терминальном сервере в группу “Пользователи удаленного рабочего стола” (Remote Desktop Users) добавить группу “Пользователи домена”).

На заметку: если задействовать SSO то вводить ничего не придется, будет задействована доменная аутентификация без какого либо ввода пароля.

Ожидаю… Идет подключение к приложению

Видите, раз в приложении когда я его подготавливал для RemoteAPP я не указал базу и сервер, то первый раз когда пользователь подключается у него запускается информационное окно, что список информационных баз пуст и нужно настроить:

Нажимаю “Да” — после выбираю: “Добавление в список существующей информационной базы” —

• Укажите наименование информационной базы: zup
• Выберите тип расположения информационной базы: На сервере 1С:Предприятия

Затем на следующем шаге указываю параметры информационной базы:

• Кластер серверов 1С:Предприятия: 10.7.8.63
• Имя информационной базы в кластере: zup

Затем на следующем шаге все выбранное мастеров оставляю по дефолту

На этом установка клиента 1С на подключение завершена.

В итоге будет так:

Подключаюсь к данной базе zup нажатием на 1С:Предприятие и происходит подключение к базе путем ввода логина и пароля выданного Администратором 1С (хотя может и Вы можете совмещать две должности вместе: системный администратор + администратор 1С).

И вот вы внутри:

 

Работа с клиентом 1С на рабочем столе ничем особым не отличается если бы пользователь работал на терминальном сервере, теже самые окна, чтобы распечатать документы задействуется технология EasyPrint когда принтер с рабочей станции пробросится на терминальный сервер, и пользователь выбрав документ – печать также увидит и выбрав его распечатает.

Ниже скришот демонстрирует, открытое окно клиента 1С и “Диспетчер задач” во вкладке “Процессы” которого присутствует подключение к терминальному серверу через (mstsc.exe).

Чтобы задейстовать технологию EasyPrint и не ставить драйвера на терминальный сервер к рабочим станциям в домене предъявляются следующие требования:

Версия RDP клиента должна быть 6.1 или выше, посмотреть c:\windows\system32\mstsc.exe открыть свойства и посмотреть версию
Либо через командную строку
C:\Users\aollo>wmic datafile where name='c:\\windows\\system32\\mstsc.exe' get version
Version
6.1.7601.17514

Должен быть установлен .NET Framework 3.5 и выше, посмотреть что установлено в системе, так.: Открыть командную строку (c правами Администратора) и набрать следующую команду:
wmic product where "name like 'Microsoft .NET Framework%'" get name,version

На заметку: когда пользователь закрывает 1С нажатием на крестик (или Файл — Выход), то его сессия на терминальном сервере не закрывается, а все еще находится в состоянии подключения

он может снова подключиться, но теперь введя пароль не забыть поставить галочку “Запомнить учетные данные” чтобы больше не видеть данное окно.

Если же по каким бы то ни было причинам, пароль был введен и сохранен, а в последствии пользователь его изменил (обычно по централизованной политике раз в 3 месяца), то он не сможет подключиться, т.к. пароль запомнен изменить его можно вот так:

На рабочей станции пользователя: Windows 7 – Пуск – Панель управления – Диспетчер учетных записей, находим сохраненное подключение

Нажимаем “Изменить” — и меняем пароль поле которого выделено на представленном скрипншоте ниже:

Согласитель, не хорошо, что когда клиент 1с закрыт, сессия на терминальном сервере все еще висит, в таком случае на терминальном сервере настраиваются промежутки ограничения простоя и неактивности терминального соединения:

Если сессия не активно в течении одного дня – она завершается, если в статусе Disconnected то через 15 минут она закрывается.

Если же экспортировать приложение RemoteAPP не в rdp файл, а в msi пакет, то

• либо такжепередаем через проводник данный файл
• либо через подготавливаем групповую политику:

GPO_RemoteAPP — Configuration — Policies — Software Settings — Software Installation — и путь в расшаренной папке до msi пакета RemoteAPP

После перезагрузки рабочей станции на рабочем столе пользователя будет ярлык 1С

Если ранее уже через rdp файл было настроено подключеник к базе, то когда через GPO произвели установку msi пакета найстройки подключения в клиенте 1С уже присутствуют:

У меня было что политика применилась к компьютеру, но msi все равно не устанавливалась, в логах на компьютере Windows 7 были следующие ошибки:

• Event ID: 303 → Удаление назначения приложения 1C Предприятие из политики GPO_RemoteAPP выполнено успешно.
• Event ID: 108 → Не удалось применить изменения для параметров установки приложения. Невозможно выполнить изменения для этого программного обеспечения. Должны существовать предшествующие записи в журнале, содержащие необходимые сведения. Ошибка: %%1612
• Event ID: 1085 → Windows не удалось применить параметры «Software Installation«. Параметры «Software Installation» могут иметь свой собственный файл журнала. Щелкните ссылку «Дополнительные сведения«.

Проблема была в месте откуда в момент создать групповой политики я указывал месторасположением msi файла, у компьютера не было прав доступа в данный каталог. Права на каталог месторасположения msi файла должны быть, чтобы у группы “Прошедшие проверку” были права на чтение (Чтение и выполение,Список содержимого папки,Чтение) и только тогда msi успешно отработает.

В итоге данная заметка шпаргалка готова и подлежит публикации на моем блоге практических заметок. Всего того, что пригодится в течении рабочего дня и самостоятельного изучения, повышения свой квалификации. Итого подведу итог практических действий:

• Развернут терминальный сервер
• Профиля будующих пользователей вынесены на отдельный логический диск.
• Посредством компоненты RemoteAPP и установленного ПО на сервере собраные пакеты задействующие технологию RemoteAPP для использования ПО, как будто оно установлена на рабочих местах пользователей, а все на самом деле не так, они работают в терминале. Таким образом достигается меньшая нагрузка на сеть.
• Чтобы запускать на рабочих станциях опубликованное приложение RemoteAPP, можно раз ввести аутентификационные данные на подключение к терминальному сервере или задействовать SSO.
• Также посредством GPO можно msi файл опубликованного приложения установить всем тем сотрудникам которые работают в программе 1С.
• На терминальном сервере можно централизованно по каждому профилю раскидать файл конфигурации на подключение к кластеру 1С и соответствующей базе. Об этом будет одна из следующих заметок.

Ну а пока я прощаюсь, я и так довольно много всего рассмотрел и не зачем еще более увеличивать данную заметку. Лучше много мелких и по теме, чем все сразу. До новых встреч, с уважением автор блога – ekzorchik.

www.ekzorchik.ru

Публикация приложения в Android маркеты / Хабр

Хорошо это или плохо, но для Android-приложений существует большое количество различных рынков продаж. С одной стороны приходится публиковать в нескольких, с другой — охват обеспечивается более широкий. Когда я задумался о том, что пора бы задействовать альтернативные маркеты для своего приложения, то толковой информации не нашёл. Сразу хочу предупредить, что программа предназначена для узкой русскоязычной аудитории, абсолютно ничем не примечательна, является по сути обычным rss-ридером для моего сайта халявы. Т.е. для многих этот опыт не будет показателен. Также я не использовал никаких средств для раскрутки своего приложения(реклама, обзоры, накрутка).

Ещё раз хочу предупредить, что пост не для воротил рынка, а исключительно для тех, кто подобно мне, робко открывает мир Android приложений с обратной от обычного пользователя стороны.
Приложение опубликовано на:
Форум 4pda.ru
Google Play
Amazon App Store
Samsung Apps Store
Blackberry App World
Есть ещё маркеты Vodafone и Verizon, но для русскоязычного софта они никак не подходят.

Изначально я «зажал» 25$ на регистрацию в Google Play, т.к. считал, что для моего приложения эти траты никогда не окупятся. Поэтому начинаю обзор со странного на первый взгляд, но, возможно, важного способа распространения вашей программы.

Форум 4pda.ru, посвящённый Андроид софту и устройствам является самым популярным в СНГ ресурсом об Андроид. Публикация темы безумно проста. Заходите в общий(не в тематический, модераторы сами перенесут) раздел либо об играх, либо о программах и нажимаете «Новая тема». Там доступный шаблон, заполнить который сможет и домохозяйка.
С одной стороны вы можете сказать, что это просто форум, но на самом деле, если вы распространяете бесплатное приложение, то разместив его на 4pda, практически автоматически вы получите публикации ещё на десятках сайтов, посвящённых Андроид. Конечно, в большинстве своём это малопосещаемые ресурсы, но это действительно халявное размещение, для которого вам практически ничего не надо делать. Недавно у меня спросили как попасть в топ в Google Play(моё приложение в топе бесплатных социальных). Я ответил, что высокие оценки плюс тысячи скачиваний сами поднимают. Но перед публикацией этой статьи задумался, что, возможно, частые упоминания в сети также дали свой эффект.
Тема была создана в начале февраля 2012. За 4 месяца количество скачиваний с форума не добралось даже до сотни. При этом посещаемость ресурса после публикации поднялась в два раза(со 100 уников до 200).
Плюсы:

• Простота публикации
• Пост публикуется сразу, не надо ждать одобрения
• Вы получаете бесплатный фидбек-тест вашего приложения
• Кросспостинг на тематические ресурсы

Минусы:

• Количество скачиваний очень небольшое
• Вы теряете пользователей, которые могли бы скачать приложение на Google Play и накрутить вам счётчик
• Подходит только для бесплатного софта

Google Play, безусловно является самых важным рынком для распространения, но как о нём самом, так и о публикации в бывшем Android Market сказано очень много. Честно говоря, ожидал, что скачиваний будет не больше, чем с форума 4pda, поэтому сам не рвался в Google Play. Но т.к. занялся разработкой полноценного приложения и понимал, что всё равно через месяц-другой придётся расстаться с 25$, то почему не попробовать на этом приложении.
В связи с наличием подробных обзоров о публикации в этом маркете просто напишу несколько моих мыслей:
Иконка приложения действительно имеет значение. Изначально была выбрана никак неподходящая по тематике. После изменения на нормальную был достигнут пик скачиваний, несмотря на то, что приложение уже пару недель было в маркете и пользовалось относительно стабильным спросом.
Комментарии бывают абсолютно разные. По началу я реагировал на них, немного переживал из-за единиц, но после 50 оценок понял, что люди просто слишком разные. Конструктива в комментариях очень мало. И ещё. Люди, которые ставят пятёрки пишут комментарии очень редко. Те, что ставят единицы, пишут практически всегда. При этом пятёрки это развёрнутые комменты, а единицы: «Туфта», «Фигня» и т.п.
Статистика оценок:
Поиск в Google Play оставляет желать лучшего. Я слышал, что в App Store тоже с этим проблемы, но опыта не имею. Тут же я просто в не представляю как пользователи находят программу. Никакой поисковой аналитики, к сожалению, нет. Приложение, которое называется «Халява, бесплатные вещи», найти по запросу «халява» невозможно. Вместо него там всё что угодно, от бесплатных живых обоев до приложения Ebay. По запросу «бесплатные вещи» сейчас первое место, но это спустя месяц. По началу у меня получалось найти только используя в запросе адрес сайта.
Оплата в 25$ не означает, что вы сразу получите возможность публиковать свои программы. Сначала будет не очень приветливая надпись, смысл которой заключается в том, что вас ещё не проверили. У меня она провисела день, надоела, и я написал письмо в саппорт. На следующий день всё уже было нормально, но никакого ответа от поддержки я не получил.
Тем не менее статистика загрузок оказалась невероятной для такого типа приложения. Пришлось даже хостинг сменить.

Плюсы:

• Быстрая регистрация
• Огромный рынок
• Относительная лёгкость попадания в тематический топ и топ «набирающие популярность»

Минусы:

• Регистрация платная
• Получить толковый фидбек практически нереально

Amazon App Store магазин приложений амазона. Мне казалось, что в России уже есть приличное количество Kindle Fire да и многие устанавливали себе этот маркет из-за раздачи платных приложений бесплатно(типа Plants vs Zombies). Ещё думал, что т.к. альтернативные маркеты не избалованы большим количеством пользователей, то они о своих разработчиках будут заботиться больше, чем google или apple. На деле оказалось совсем не так:) Регистрация в Амазоне занимает немногим меньше недели. Ещё почти столько же будут проверять ваше загруженное приложение. А ещё Амазон предупреждает, что это только первый год регистрации бесплатный. Потом каждый год надо будет платить.
Первый раз мою программу не приняли, т.к. описание было на русском. В амазоне можно ТОЛЬКО на английском. Единственное, что можно ввести кирилицей — keywords. Соответственно, если у вас приложение русскоязычное, смысла идти в Amazon App store нет никакого. После изменения описания и названия на английские повторная проверка занимает ещё несколько дней и приложение в маркете публикуют. Ещё через несколько дней оно попадает в маркет для Kindle Fire. Но скачивания обескураживают:
Плюсы:

• Говорят, что платные приложения покупают лучше, чем в Google Play
• Конкуренция ниже

Минусы:

• Только англоязычный софт
• Регистрация и аппрув приложения занимают много времени
• Рынок меньше, чем в Google Play
• В дальнейшем ежегодные взносы

Samsung Apps Store рынок от самого крупного на сегодняшний момент производителя телефонов в мире. Т.к. все Android-смартфоны идут с предустановленным фирменным App Store, рынок выглядит очень большим. На деле же разочарование от попытки(по другому это сложно назвать) использования этого маркета превысило даже amazon app store.
8 мая я попытался зарегистрироваться и загрузить своё приложение. Всё шло как обычно вплоть до последнего шага, на котором я получал сообщение «Failed update service status(complete)». Изрядно поломав голову, опробовав разные варианты написания названия и прочего, решил написать тикет в поддержку. Ответили довольно быстро, через несколько часов. Но вот ответ. Я сначала даже не понял его. Суть заключалась в том, что они знают о проблеме и ожидают её решения 17(!) мая. Т.е. такой компании как Самсунг, чтобы решить проблему невозможности публикации приложений на своём маркете надо не меньше 10 дней. Честно, я даже не думал, что такое возможно:) После того как они свои проблемы решили, мне пришлось снова заходить в seller office и нажимать эту последнюю кнопку.
Дальше больше. Вы не можете сделать своё приложение доступным для всех устройств сразу. Имеется около десятка категорий, которые различаются разрешением. Хотите сделать программу доступной для всех устройств — создавайте десяток публикаций.
Когда же я увидел количество проверок, которым самсунг подвергает приложение, улыбку сдержать не мог. Надеюсь, к Рождеству его всё-таки опубликуют)))

Соответственно никаких скачиваний — ничего.
Плюсы:

• Потенциально рынок существует
• Регистрация бесплатная 🙂

Минусы:

• Путь в Samsung App Store невероятно долог
• Фрагментированность устройств заставляет создавать несколько публикаций.
• Рынок меньше, чем в Google Play

Blackberry App World маркет для Blackberry. Немного странно видеть его в обзоре маркетов для Android, да? Тем не менее RIM сделали возможность конвертации apk в bar. Причём это можно сделать онлайн. Пять минут и у нас кроссплатформенное приложение:) На самом деле смысла распространения приложения в Blackberry App World я не видел. Мне просто было интересно проверить работает ли конвертация и как вообще устроен маркет для Blackberry. Распространённость этой платформы в России невероятно низкая. Я сам держал смартфон RIM всего пару раз в жизни, когда работал эникейщиком на одном крупном заводе(стандарт для топ-менеджеров). Сейчас ещё появились планшеты Playbook, которые в России, как мне кажется в основном распространены только из-за того, что RIM их бесплатно отправляла разработчикам.
Регистрация бесплатная, но требуют предъявить скан вашего паспорта. Цель этого для меня туманна, я кинул скан просроченного загранника — прокатило(на проверку ушло 4 дня). Дальше публикуем приложение. Здесь, конечно, задержки обусловлены моим не знанием специфики, но расскажу как есть. Тут в отличие от Самсунга вы можете выбрать все устройства скопом. И телефоны, и планшеты. Ещё дают выбрать минимальную OS. Я выбрал всё и поставил OS с 1.0.
Первый ответ от саппорта пришёл с отказом, т.к. подобные приложения не поддерживаются на OS 1.0. Поменял на OS 2.0 и отправил снова. Следующий отказы был связан с тем, что формат bar поддерживается только для планшетов Playbook. Зашёл снова, убрал телефоны, отправил на проверку. Проверили, приняли. Весь процесс занял пять дней. Учитывая 2 отказа срок по мне нормальный. Зааппрувили и забыл.
Недавно зашёл посмотреть, а скачивания есть. Пусть мало, но есть. И даже положительный отзыв оставлен. Пользователи не избалованны большим количеством приложений и готовы пользоваться тем, что есть.
Скачивания:
Плюсы:

• Конкуренция очень низкая
• Регистрация бесплатная
• Периодически появляются конкурсы для разработчиков
• Онлайн конвертация приложения под новую платформу

Минусы:

• В России не распространён
• RIM постепенно умирает

Из этого сделал вывод, что приложение ориентированное на русскоязычное население, большого смысла публиковать в альтернативных маркетах нет. При этом Google play и 4pda являются неплохими площадками для размещения. Если приложение на английском, то результаты могут быть другими.
Надеюсь, что мой опыт будет кому-нибудь полезен.

habr.com

Особенности публикации приложений в Windows | Windows IT Pro/RE

Службы терминалов Windows позволяют осуществить полноценную публикацию приложений

Когда речь идет о публикации приложений на основе служб терминалов, обычно подразумевается, что приложение, запущенное в терминальной сессии, выглядит так же, как если бы оно выполнялось локально на клиентском компьютере. При этом в роли оболочки терминальной сессии выступает не стандартный рабочий стол, а само опубликованное приложение. Аутентификация при подключении к терминальному серверу отсутствует, поскольку выполняется автоматически с данными предопределенной учетной записи. Когда пользователь закрывает приложение, завершается и соответствующая терминальная сессия.

Имеется ряд обстоятельств, при которых публикация приложений предпочтительна. Так, неподготовленным пользователям работать с опубликованным приложением проще, чем с удаленным рабочим столом. Отсутствие в пользовательских терминальных сессиях рабочего стола с его многочисленными элементами управления повышает безопасность решений на базе служб терминалов. Более экономно расходуются серверные ресурсы, главным образом оперативная память. И наконец, опубликованные приложения удобно размещать на Web-страницах с доступом к ним из браузера Internet Explorer посредством клиентских компонентов ActiveX службы терминалов.

Службы терминалов Windows и Citrix Metaframe

Службы терминалов Windows, работающие по протоколу RDP (Remote Desktop Protocol), пока уступают по своим возможностям продукту Citrix Metaframe, в основе которого лежит протокол ICA (Independent Computing Architecture). Например, Metaframe поддерживает режим эмуляции локальных окон (seamless windows), а службы терминалов Windows — нет. В случае RDP-соединения приложение всегда запускается в окне терминальной сессии. Размер окна приложения можно изменить, можно развернуть окно приложения на все окно терминальной сессии, но размер окна терминальной сессии остается постоянным. Если в процессе работы будут открыты новые окна приложений, то они также будут находиться в пределах окна терминальной сессии (см. экран 1).

Экран 1. Несколько окон приложений в одном окне терминальной сессии

Режим эмуляции локальных окон в Citrix Metaframe позволяет запускать опубликованное приложение в отдельном окне, без видимых отличий от приложения, открытого на клиентском компьютере локально. Преимущество довольно существенное, более того, иногда приходится встречать утверждение, что публикация приложений средствами служб терминалов Windows невозможна.

Единственным фактором, свидетельствующим не в пользу Metaframe, является высокая стоимость продукта и клиентских лицензий. Службы терминалов Windows находятся здесь в лучшем положении, поскольку входят в состав Windows 2000 Server и Windows Server 2003, причем лицензии терминального доступа к Windows 2000 Server предоставляются бесплатно, если в качестве клиентов используются рабочие станции с операционной системой Windows 2000 и выше.

Настройки служб терминалов Windows

Для того чтобы опубликовать приложение с помощью служб терминалов Windows (в дальнейшем — «службы терминалов»), обычно достаточно выполнить следующие настройки: указать полный путь к исполняемому файлу приложения, которое будет запущено вместо удаленного рабочего стола, а также данные учетной записи для автоматической аутентификации. Необходимые настройки могут быть выполнены как на стороне клиента службы терминалов, так и на сервере в консоли Terminal Services Configuration. Также можно изменить параметры учетной записи пользователя, относящиеся к терминальным подключениям.

Экран 2. Дополнительные объекты Connection в окне Terminal Services Configuration

Хотя клиентские настройки и позволяют решить задачу публикации приложений, данное решение не отвечает требованиям удобства администрирования и безопасности. Например, если на терминальном сервере опубликованное приложение будет переустановлено в другую папку либо будут изменены реквизиты учетной записи для автоматической аутентификации, соответствующие изменения потребуется внести на всех клиентских рабочих станциях. Определение параметров терминальных сессий на сервере свободно от этих недостатков, поскольку настройки сервера имеют приоритет перед клиентскими настройками. Централизованное управление публикацией приложений повышает защиту служб терминалов, и, кроме того, если опубликованное приложение должно появляться в окне браузера Internet Explorer, то это единственное решение.

К сожалению, здесь возникает новая проблема. Дело в том, что параметры терминальных сессий определяются на сервере в свойствах объекта Connection, доступного в консоли Terminal Services Configuration. Поскольку каждому сетевому интерфейсу можно сопоставить не более одного объекта Connection, это означает, что на терминальном сервере можно опубликовать столько приложений, сколько сетевых адаптеров установлено физически. Помимо этого, для каждого сетевого адаптера потребуется выделить IP-адрес, выполнить его подключение к сетевому оборудованию и т. д. Даже если на терминальном сервере с одним сетевым адаптером опубликовано единственное приложение, становится невозможным использование терминальных служб для других задач, например для удаленного администрирования. Можно ли добавлять объекты Connection как-нибудь иначе, не устанавливая в терминальный сервер новых устройств?

Несуществующие сетевые интерфейсы и служба RRAS

Оказывается, можно, но потребуется применить довольно нестандартную настройку сетевой конфигурации и службы RRAS (Routing and Remote Access Service). Сначала добавим в систему фиктивные «сетевые адаптеры» типа Microsoft Loopback Adapter. Это позволит создать в конфигурации службы терминалов новые объекты Connection и привязать каждый из них к своему «сетевому адаптеру». Затем мы воспользуемся возможностями службы RRAS для маршрутизации обращений из локальной сети к фиктивным «сетевым адаптерам». Рассмотрим данный способ более подробно.

Экран 3. Правила перенаправления IP-пакетов в протоколе NAT

Используя мастер установки оборудования, следует добавить в систему одно или несколько «устройств» типа Microsoft Loopback Adapter (по числу приложений, планируемых для публикации). В процессе установки необходимо указать, что устройство будет выбрано вручную, далее в списке классов устройств нужно выбрать Network Adapters, а в списке производителей — Microsoft. Для установки следующего «устройства» процедуру требуется повторить. По окончании установки обязательна перезагрузка сервера, хотя прямого указания на это нет.

Теперь, если открыть папку Network and Dial-up Connections, то кроме основного подключения можно увидеть одно или несколько дополнительных, созданных на основе фиктивных сетевых адаптеров. Их следует настроить: в свойствах каждого подключения на закладке General нужно сбросить все флажки, относящиеся к сетевым клиентам, протоколам и службам, за исключением Internet Protocol (TCP/IP). В свойствах протокола TCP/IP необходимо указать IP-адрес и маску подсети из диапазона не используемых в организации локальных IP-подсетей. При этом IP-адреса и маски подсети, назначаемые для каждого подключения, должны образовывать неперекрывающиеся подсети. В приведенном ниже примере фиктивным сетевым адаптерам были назначены адреса 192.168.2.1 и 192.168.2.5 с масками подсетей 255.255.255.252.

Основное подключение по локальной сети также требует настройки. Следует выделить из числа адресов локальной IP-подсети, к которой подключен терминальный сервер, дополнительные IP-адреса по числу добавленных фиктивных сетевых адаптеров. Затем нужно открыть окно свойств протокола TCP/IP, нажать кнопку Advanced и добавить IP-адреса на закладке IP Settings.

Теперь в конфигурацию служб терминалов можно добавить новые объекты Connection. Необходимо запустить консоль Terminal Services Configuration, открыть свойства существующего подключения RDP-Tcp, перейти на закладку Network Adapter и вместо режима по умолчанию — All network adapters configured with this protocol — выбрать из списка физически установленный на сервере сетевой адаптер. Далее, используя мастер Terminal Services Connection Wizard, нужно добавить один или несколько новых объектов Connection, выбирая для каждого из них свой «сетевой адаптер» Microsoft Loopback Adapter. В результате должна получиться конфигурация, подобная показанной на экране 2. Настройку параметров терминальных сессий можно выполнить сразу или позднее.

Осталось настроить службу RRAS для перенаправления пакетов, приходящих на дополнительные IP-адреса сетевого интерфейса, во внутреннюю сеть терминального сервера. Для этого требуется открыть консоль Routing and Remote Access, и, если служба RRAS не была сконфигурирована ранее, выбрать локальный сервер, в меню Action запустить Configure and Enable Routing and Remote Access и при выборе конфигурации указать Network Router. Нам предстоит добавить и сконфигурировать службу NAT, так как именно она обеспечит видимость внутренних «сетевых адаптеров» из «внешней» локальной сети. Для этого в разделе IP Routing нужно выделить General и в меню Action выбрать New Routing Protocol… — Network Addtess Translation (NAT). При настройке следует указать, какие подключения являются внешними, а какие — внутренними. Необходимо добавить все подключения на основе Microsoft Loopback Adapter как внутренние (Private interface connected to private network), а подключение сетевого адаптера к локальной сети — как внешнее (Public interface connected to the Internet). Следует открыть свойства внешнего подключения, перейти на закладку Address Pool и в списке адресов указать основной и все дополнительные IP-адреса локальной сети, назначенные сетевому адаптеру терминального сервера. При добавлении в список единичных адресов (не подсетей) требуется в полях Start Address и End Address указать один и тот же адрес, а поле Mask не заполнять. Далее на закладке Special Ports нужно настроить правила перенаправления пакетов, по аналогии с примером на экране 3.

Экран 4. Seamless Client Publisher — средство публикации приложений

Здесь 192.168.2.1 и 192.168.2.5 — это IP-адреса «устройств» типа Microsoft Loopback Adapter, 10.0.2.11 и 10.0.2.12 — дополнительные адреса локальной сети, привязанные к сетевому адаптеру, а порт 3389 — стандартный порт служб терминалов Windows. Иными словами, все подключения от клиентов служб терминалов по дополнительным IP-адресам перенаправляются на соответствующие фиктивные сетевые адаптеры. Правила перенаправления допустимо настраивать только для дополнительных IP-адресов, иначе перестанет функционировать объект Connection, связанный с основным физическим сетевым адаптером.

Таким образом, клиентские запросы на подключения, приходящие на разные IP-адреса, будут обрабатываться разными объектами Connection, каждый из которых обладает собственным набором параметров терминальных сессий. Приведенный пример показывает, что некоторые ограничения служб терминалов могут успешно преодолеваться за счет средств конфигурации, предоставляемых прочими службами Windows.

Другие параметры терминальных сессий

Из других параметров терминальных сессий важными для публикации приложений являются те, что определяют поведение сессии при простое и разрыве соединения. Так как пользователь получает опубликованное приложение в окне терминальной сессии, по окончании работы с приложением можно сделать следующее: закрыть приложение (как следствие, будет завершена терминальная сессия) либо закрыть окно терминальной сессии (или окно Internet Explorer, если приложение опубликовано на Web-странице). Практика показывает, что пользователи обычно выбирают второе. В этом случае терминальная сессия переходит в отключенное состояние, но не завершается, а приложение в отключенной сессии продолжает выполняться. Параметры тайм-аута, определяемые на сервере, должны устанавливать минимально возможное время завершения сессии при разрыве соединения. Кроме того, имеет смысл задать достаточно большое, но конечное значение, ограничивающее время бездействия в сессии.

Терминальные службы и эмуляция локальных окон

И все же, оставаясь в рамках протокола RDP, можно ли получить опубликованное приложение как оно есть, без фона в виде окна терминальной сессии? Стандартные средства служб терминалов не позволяют этого сделать. Но в действительности эмуляция локальных окон является в большей степени функцией клиента, а не сервера и протокола. Вот один из возможных методов.

Из общего потока данных RDP клиент служб терминалов выделяет лишь содержимое открытых окон в терминальной сессии, все остальные данные игнорируются (см. рис. 1).

Рисунок 1. Публикация приложений средствами клиента служб терминалов

Клиент формирует на локальном рабочем столе окно или окна, размеры и расположение которых в точности совпадают с открытыми окнами в терминальной сессии. Это геометрическое соответствие непрерывно поддерживается в процессе перемещения окон, изменения их размеров и т. п. Информация, находящаяся в области открытых окон в терминальной сессии, один к одному отображается в подготовленные окна на рабочем столе клиентского компьютера. В результате у пользователя создается ощущение локальной работы с опубликованным приложением.

Очевидно, что представленное решение требует перестройки исключительно клиента служб терминалов. Ни сервер, ни протокол в каких-либо модификациях не нуждаются. В чистом виде такой подход реализован в программе AppliDis Seamless Client французской компании InfoStance. Программа замечательна еще и тем, что при ограничении не более пяти одновременных подключений официально разрешено пользоваться ею бесплатно. Рассмотрим возможности программы более подробно.

Программа AppliDis Seamless Client устанавливается на терминальном сервере Windows 2000 Server или Windows Server 2003. В процессе установки появляется компоновщик Seamless Client Publisher (см. экран 4), который позволяет настраивать предназначенные для публикации приложения. Для каждого приложения можно определить путь к исполняемому файлу, параметры командной строки, домен или локальный сервер, производящий аутентификацию, а также параметры цветовой палитры и перенаправления внешних устройств. После добавления записи в список опубликованных приложений создается компактный (не более 300 Кбайт) исполняемый файл, помещаемый в общий каталог ClientsSeamless. Программный код, содержащийся в файле, осуществляет подключение и запуск заданного приложения в терминальной сессии, но не содержит никаких средств настройки, поэтому в случае изменения параметров опубликованного приложения компоновщик пересоздает файл. Такие файлы можно запускать из общей папки, переносить на рабочие станции, помещать на Web-сервер и т. п.

Опубликованное приложение запускается на клиентском компьютере в отдельном окне без видимых атрибутов терминальной сессии. Если приложение порождает новую задачу, она запускается в своем собственном окне, но в той же самой терминальной сессии. Для подключения к опубликованному приложению необходимо ввести имя пользователя и пароль для аутентификации на терминальном сервере. Имеется режим, позволяющий сохранить введенные реквизиты на рабочей станции в профиле пользователя. В качестве клиентов поддерживаются версии Windows 9x/Me/NT/2K/XP.

Для своей работы программа требует наличия ActiveX-компонента msrdp.ocx версии не ниже 5.2 на всех клиентах и по возможности на сервере. Распространять данный компонент можно различными способами. Например, установить на Web-сервер IIS в локальной сети программное дополнение Remote Desktop Web Connection, последнюю версию которого можно найти на сайте Microsoft. Тогда для установки ActiveX-компонента на клиентских компьютерах достаточно запустить Internet Explorer, обратиться по адресу: http:///tsweb (где вместо следует подставить имя или адрес сервера IIS) и подтвердить загрузку компонента.

Загрузить программу AppliDis Seamless Client можно по адресу. Описанное решение наглядно отражает ситуацию на конкурентном рынке программных продуктов, где качественный сервис предлагается за большую цену, а менее дорогие решения, хотя и справляются с поставленной задачей, но с теми или иными ограничениями. В то же время, как видно из рассмотренного примера, протокол RDP и службы терминалов Windows не имеют принципиальных ограничений по осуществлению полноценной публикации приложений.

Олег Ржевский ([email protected]) — руководитель проекта в Инвестиционном банке ТРАСТ, к.ф-м.н. Имеет сертификат MCSE.

www.osp.ru

Как удалить опубликованное приложение с моего аккаунта Android? Oh! Android

Я опубликовал файлы apk на сайте Android с ошибкой. Но я хочу удалить это приложение с рынка Android.

Как удалить опубликованное приложение с моей учетной записи Android?

В приложении «Сценарий» для приложения «Удалить»: * На странице приложения нажмите «Обновить» >> нажмите кнопку «Удалить» внизу страницы. * При нажатии кнопки delete отображается сообщение об ошибке ниже

На вашем устройстве нет удаления вашего приложения. Что вы можете сделать, так это отменить публикацию приложения (что я только что сделал).

Описанная OP – это просто функция удаления только что загруженного обновления. Он не удаляет или не публикует ваше заявление. Он просто удаляет загруженный файл вашего обновления.

Чтобы сделать это короткое: опубликованное приложение не может быть удалено, только не опубликовано.

Ваш опубликованный apk не может быть удален, он будет деактивирован.

Для этого вы должны:

1) Неопубликованное приложение с рынка

2) после этого в вас Последний манифест добавить

 <manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" . . . </manifest> 

Вам понадобится следующее:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="2" android:versionName="1.1" . . . </manifest> 

3) И снова подпишите свой apk из eclipse-> Android-инструменты-> Экспорт подписанного пакета приложений-> подпишите его->

4) Загрузите Apk на рынок.

Надеюсь, что это поможет.

По моему опыту многие ошибки могут быть решены путем изменения номера версии на более высокий. Если вы не измените его, иногда он возвращается с этой ошибкой. Посмотрите на свой манифест для: android:versionCode="xxxx"

Это довольно раздражает, что вы не можете вернуться в предыдущую версию после катастрофического сбоя в выпуске. Будучи компанией одного человека, иногда вы не можете получить хороший q & a для выпуска.

Я не думаю, что намерение состоит в том, чтобы удалить все приложение, я думаю, что это удалить изменения, которые вы только что сделали … больше как «отменить», чем удаление. Если бы цель состояла в том, чтобы удалить все приложение, то я сомневаюсь, что они поместили опцию под «upgrade».

Если вы публикуете свое приложение, его нельзя удалить , только не опубликовано. Мне пришлось загружать новые приложения с новым кодом версии и деактивировать приложение, которое я пытался удалить …

Вы не можете удалить свое приложение, вы можете только его опубликовать или опубликовать приложение с номером версии, большим, чем предыдущий. Это немедленно отключит приложение от Android Market.

И если вы ранее опубликовали приложение бесплатно, вы не можете изменить его, чтобы иметь цену. Вам нужно будет загрузить новый APK и добавить цену.

Когда ваше приложение не опубликовано, вы можете повторно опубликовать его с тем же именем, изображениями и т. Д., Но оно создаст другую запись в вашей учетной записи.

Можно предположить, что полное удаление приложения подразумевает потерю статистики и исторических данных приложения, и все мы знаем, что Google этого не допустит. Досадно иметь старые и неопубликованные приложения в вашей учетной записи, но … это то, что есть. Возможно, в будущем они поставят «Скрыть» вариант, чтобы снять это с нашего зрения.

Обычно, когда приложение не опубликовано. Рядом с названием вашего приложения на учетной записи Play Store есть небольшая ссылка для приложения для удаления. Вам просто нужно щелкнуть по нему. Убедитесь, что приложение не опубликовано, хотя кнопка удаления приложения отсутствует.

www.ohandroid.com

Публикация приложения RemoteApp на в ферме серверов RDS (Windows Server 2012) на примере КонсультантПлюс

В Windows Server 2012 консоль Server Manager работает таким образом, что при попытке публикации приложения RemoteApp, для которого выбран исполняемый файл расположенный на общем сетевом ресурсе, возникает грозное уведомление о том, что мы можем выбирать исполняемые файлы расположенные только на каком-то конкретном сервере RD Session Host (RDSH)…

На самом деле это не так, и мы вполне можем выполнить публикацию исполняемого файла расположенного в сети с помощью командлетов PowerShell из модуля RemoteDesktop…

Рассмотрим публикацию приложения RemoteApp с помощью PowerShell на примере КонсультантПлюс. Но сначала сделаем небольшое отступление в сторону описания особенностей использования КонсультантПлюс в распределённой многопользовательской среде. В нашем примере исполняемый файл этого приложения (cons.exe) расположен вместе с файлами правовых баз данных в общем сетевом каталоге. Нам нужно опубликовать это приложение для пользователей фермы RDS состоящей из нескольких серверов. В ферме RDS используется механизм перемещаемых профилей Roaming User Profiles. Наше приложение для сохранения пользовательских настроек использует специальные служебные каталоги \ConsUserData. Поэтому, учитывая нашу специфику перемещаемых профилей, создадим специальный ярлык (*.lnk) для запуска КонсультантПлюс в ферме RDS в режиме RemoteApp.

Дадим ярлыку имя, например CONS_RemoteApp.lnk и разместим его в той-же сетевой папке, где расположен сам исполняемый файл приложения. В качестве рабочей папки обязательно укажем значение ссылающееся на переменную %AppData% которая указывает на часть пользовательского профиля, которая обрабатывается механизмом Roaming User Profiles (это позволит нам добиться того, что при входе на любой сервер фермы RDS, пользователь будет иметь одни и те же настройки в КонсультантПлюс)

Так как с свойствах ярлыка мы указали каталог (%AppData%\ConsUserData), которого не существует для вновь создаваемых профилей пользователей, нам придётся позаботиться о его создании, например с помощью Group Policy Preferences (GPP). Создадим в групповой политике применяемой к пользователям на серверах RDS соответствующую настройку GPP в разделе
User Configuration\Preferences\Windows Settings\Folders

Теперь всё что нам остаётся сделать, это опубликовать созданный ярлык с помощью PowerShell:

Import-Module RemoteDesktop
New-RDRemoteApp -Alias ConsultantPlus `
-DisplayName "Консультант Плюс" `
-FilePath "\\FileServer\ConsultantPlus\CONS_RemoteApp.lnk" `
-IconPath "\\FileServer\ConsultantPlus\cons.exe" -IconIndex 0`
-ShowInWebAccess 1`
-collectionname "KOM-AD01-RDCOLL"`
-ConnectionBroker "KOM-AD01-RDS21.holding.com"

Если мы включаем признак публикации приложения на веб-странице RD Web Access и при этом там используются папки, то указать папку в которую нужно разместить ярлык можно добавив к команде ключ: 

-FolderName "Бизнес приложения"

Если необходимо ограничить доступ к публикуемому приложению, то к команде можно добавить ключ определяющий перечень доменных групп безопасности:

-UserGroups @("KOM\Accountants","KOM\Lawyers")

Практика показывает, что на текущий момент, опубликованное таким образом приложения отображаются в консоли Server Manager , но при попытке сохранить изменение их свойств возникает ошибка…

Поэтому, если потребуется изменить свойства такого RemoteApp приложения, путь один – PowerShell.

Поделиться ссылкой на эту запись:

Похожее

blog.it-kb.ru

Создание подписи приложения с помощью Google Play App Signing

Post Views: 5 817

Поскольку ключ подписи используется для проверки того, что именно вы являетесь разработчиком приложения, и для обеспечения безопасных обновлений для ваших пользователей, обеспечение безопасности ключа очень важно как для вас, так и для пользователей. Существуют различные способы подписания своих приложений, один из таких мы рассмотрели в предыдущей статье.

Недавно Google добавил новую возможность хранить ключи: в своей собственной инфраструктуре благодаря Google Play App Signing. Основное отличие здесь заключается в том, что вы подписываете приложение специальным ключом загрузки, который Google проверяет и удаляет, заменяя его оригинальным ключом подписи приложения, который вы предоставили.

С его помощью можно управлять ключами подписи приложений как для новых, так и для опубликованных приложений, которые в свою очередь будут храниться у Google в их собственном хранилище ключей. Чтобы присоединиться к этой программе, необходимо подписаться на неё в своей Google Play Console. Стоит отметить, что в последствии отписаться от неё уже будет невозможно.

Таким образом, при подключении к Google Play App Signing происходит следующее:

• Бессрочная регистрация вашего приложения в программе Google Play App Signing.
• Передача вашего ключа подписи приложения в Google.
• Регистрация нового ключа загрузки для всех последующих APK-файлов.

Такой способ очень полезен, поскольку в случае, если вы потеряли хранилище ключей, Google Play App Signing позволит сбросить ключ для установки нового. Согласитесь, это намного проще, чем каждый раз публиковать приложение заново с новым именем пакета и ключом.

Попробуем, используя этот способ, опубликовать новое приложение : Менеджер системных приложений.

Для начала необходимо создать ключ загрузки, по которому Google будет проверять APK. Для этого средствами Android Studio через меню Build — Generate Signed APK создадим новое хранилище ключей, в котором будет содержаться наш ключ загрузки. Создание подписи приложения будет происходить с помощью Gradle, а файл, содержащий путь до хранилища и пароли, вынесем из проекта и будем хранить отдельно.

signingConfigs {
    release {
        if (project.hasProperty("Keys.repo")) {
            def projectPropsFile = file(project.property("Keys.repo") + "/system-app-manager.properties")
            if (projectPropsFile.exists()) {
                Properties props = new Properties()
                props.load(new FileInputStream(projectPropsFile))

                storeFile file(file(project.property("Keys.repo") + props['RELEASE_STORE_FILE']))
                storePassword props['RELEASE_STORE_PASS']
                keyAlias props['RELEASE_ALIAS']
                keyPassword props['RELEASE_KEY_PASS']
            }
        } else {
            println "======================================================="
            println "[ERROR] - Please configure release-compilation environment - e.g. in ~/.signing  directory"
            println "======================================================="
        }
    }
}

О том, как это можно сделать для своего приложения, можно почитать в данной статье.

Теперь перейдём в консоль разработчика. Создадим новое приложение и дадим ему название. После этого нужно перейти в «Версии приложения» — «Управление рабочей версией» — «Создать выпуск«. Здесь вам будет предложено подключиться к програме Google Play App Signing, нажимаем «Продолжить«.

Если перейти в «Подписи приложения«, то можно обнаружить, что был создан сертификат для подписи, однако сертификат загрузки остался пустым. Это потому, что мы ещё не загрузили первый подписанный APK файл.

Вернёмся в создание выпуска. После получения подтверждения о том, что мы подключились к программе, можно перейти к загрузке APK.

Здесь нужно загрузить APK файл своего приложения, подписанный ключом, который был создан выше. Этот ключ и станет ключом загрузки для приложения, которым вы должны будете подписывать все APK в будущем.

После того, как вы загрузите APK, подписанный ключом загрузки, его сертификат появится в «Подписи приложения«.

После заполнения всех необходимых полей в консоли и публикации приложения в Google Play, в приложении уже будет использоваться другой ключ подписи, который будет находиться у Google и отправляться пользователям при загрузке приложения из маркета.

Узнать, что приложение подписано Google, а не самим разработчиком, можно по следующему элементу метаданных, содержащемуся в тэге <application> в файле манифеста:

<meta-data android:name="com.android.vending.derived.apk.id" android:value="[ID]" />

Как сбросить ключ загрузки?

В случае, если вы потеряли свой ключ загрузки или он был похищен кем-либо, вы можете сбросить его в консоли разработчика. Чтобы сделать это, нужно:

1. Создать новый ключ загрузки аналогично тому, как это делалось в начале статьи. Затем его нужно будет экспортировать в сертификат PEM с помощью следующей команды.

   keytool -export -rfc -alias upload -file <upload_certificate.pem> -keystore <keystore.jks>

2. После создания сертификата нужно обратиться в службу поддержки по следующей ссылке, заполнив все поля и прикрепив файл сертификата. Как только запрос будет обработан, вам на электронную почту придут инструкции по смене ключа.

Скачаем опубликованное приложение и посмотрим, что у него внутри. Для этого воспользуемся любым декомпилятором APK файлов.

Если открыть манифест приложения, то внутри можно обнаружить ту самую строку с метаданными, о которой мы говорили выше.

Данный идентификатор будет использоваться в инструментах отчётности об ошибках и по нему можно определить нужный APK-файл.

К сожалению, оптимизации APK не происходит, как было заявлено разработчиками. Google Play должен предоставлять оптимизированный APK с нужными локалями и плотностью экрана. Однако если посмотреть, что находится в ресурсах декомпилированного APK, то можно обнаружить там все локализации, которые были созданы для приложения, и разметки экранов с плотностью.

Кроме декомпилятора это также можно проверить утилитой aapt.exe (Android Asset Packaging Tool), которая входит в состав Android SDK. Для этого нужно ввести следующую команду:

aapt dump badging apk_name.apk

Как подписаться, если приложение уже опубликовано?

В случае, если вы хотите подписать своё опубликованное приложение на Google Play App Signing, то вам нужно будет в консоли разработчика открыть проект приложения и затем выбрать «Управление релизом» — «Версии приложения«.

В открывшемся окне помимо различный вариантов сборок и версий вашего приложения должно появиться приглашение подключиться к Google Play App Signing.

Вам перекинет на страницу «Подписи приложений» с описанием программы. Вам нужно будет оттуда скачать утилиту PEPK и с помощью неё выполнить следующую команду, заменив выделенные участки на свои:

java -jar pepk.jar --keystore=ваше_хранилище_ключей.keystore --alias=имя_ключа --output=новый_путь_для_созданного_сертификата --encryptionkey=eb10fe8f7c7c9df715022017b00c6471f8ba8170b13049a11e6c09ffe3056a104a3bbe4ac5a955f4ba4fe93fc8cef27558a3eb9d2a529a2092761fb833b656cd48b9de6a

Эта утилита позволяет вам извлечь определённый ключ из хранилища ключей и экспортировать его в PEM сертификат. Для примера попробуем экспортировать ключ для другого приложения. После ввода команды нас попросят ввести пароли от хранилища и от ключа, и если всё завершится без ошибок, значит операция выполнена успешно.

Если PEPK выдаёт ошибку на неправильный alias, хотя вы полностью уверены, что он верен — попробуйте написать его только маленькими буквами, если в нём имеются заглавные.

Затем на той же странице в консоли разработчика нужно нажать на «Закрытый ключ для подписи приложения» и выбрать наш созданный сертификат. Таким образом Google поймёт, что именно мы являемся разработчиком приложения. После этого можно приступать к созданию ключа загрузки, по которому в будущем будет происходить публикация всех APK-файлов.

Для этого нужно создать ключ тем же способом, каким мы создавали его в начале статьи. Затем с помощью стандартной утилиты Java под названием Keytool нужно будет экспортировать ключ в PEM сертификат с помощью следующей команды:

keytool -export -rfc -keystore ваше_хранилище_ключей -alias имя_ключа -file путь_для_сертификата

На странице консоли разработчика нажимаем «Сертификат открытого ключа загрузки» и выбираем созданный сертификат с ключом загрузки.

После проделанных операций у нас станет активна кнопка «Зарегистрировать», нажимаем её и, если нет никаких ошибок, Google Play App Signing будет подключён к вашему приложению и вы увидите отпечатки сертификата.

Теперь вы можете загружать новые APK, подписывая их своим ключом загрузки, после чего Google будет заменять его на ключ из собственного хранилища.

Новая технология от Google немного облегчила жизнь разработчикам, будем жать, когда она действительно облегчит выходной APK-файл.

Читайте также

android-tools.ru