Профессионал! Легкое общение, предупреждает и подробно рассказывает о всех нюансах, всегда на связи.
Хорошая цена и работа на результат!
Спасибо большое и рекомендую на 100%
Есть мобильное приложение для Android. Webview для нашего Saas-сервиса, и еще ряд функций, в том числе отправку информации о совершении звонков для обработки из в CRM. Но Гугл не пропускает приложение к публикации именно из-за наличия этой функции.
Вопрос, как доработать приложение и/или показать модераторам Гугла, что функция отправки звонков (даже без их записи) - необходима для работы приложения, легальна и соответствует целям пользователей приложения?
Бюджет: 1000 UAH Срок: 60 дней
Добрый день!
Команда опытных разработчиков мобильных приложений.
Мобильные приложения пишем на java используя компоненты Android SDK, также можем сделать серверную часть для приложения на php, или использовать сервис Firebase.
Вот несколько примеров из нашего портфолио:https://play.google.com/store/apps/dev?id=7592042799978899087
Готовы обсудить детали Вашего задания для оценки и согласования работ. Расчет по работам можем проводить как от Юр. так и от Физ. лица.
Наши контакты: Александр
067 690 82 62(Viber, Telegram)
[email protected]
В вашем приложении есть READ_PHONE_STATE permission
Гугл хочет политику конфиденциальности?
Не совсем так.
Сообщение о причине отклонения такое:
- Based on our review, we found your app’s expressed user experience did not match your declared core functionality {Caller ID, spam detection, and /or spam blocking, Write and Show Call History in Dialer}. Please remove these permissions from your app.
У нас нет как такового диалера в приложении, равно как и нет распознавания и блокировки спама. Есть классические функции CRM-системы для работы с клиентами и их звонками - список звонков с телефона пользователя, с которыми он производит определенные действия - назначает планы по ним и так далее.
http://joxi.ru/VrwzE3wi7a51PA
Но вот как это объяснить гуглу?
Прочтите об этом, может будет полезно
https://stackoverflow.com/questions/54997171/google-play-permission-what-core-functionalities-in-your-app-require-sms-and-ca
И официальная статья
https://support.google.com/googleplay/android-developer/answer/9214102
Добрый день, Иван!
У нас нужны права не на SMS и не на Call log, нам нужен доступ к самим звонкам, т.е. информация о параметрах звонка в момент его начала и окончания. Но ситуация, вероятно, похожая.
Сможете ее решить на платных условиях?
интересно зачем распространять приложение для работы внутри компании через маркет?
Ну типо для работы с клиентами еще наверное) Это единственное что мне приходит в голову. У нас все держалось на сервере и если приходил новичок то сразу все скачивал себе с сервера) Все быстро и просто и все внутри самой компании.
Ну и в основном Saas-сервисы делаются для клиентов а не для компании)
А разве я писал где-то, что это "приложение для работы внутри компании"?
Разработка международного мобильного приложения под ключ (Дизайн + Код) Для удешевления, возможно не делать, а купить готовый дизайн 1. Общие требования к проекту Платформа: Кроссплатформенная разработка на фреймворке Flutter (один код под iOS и Android). Тип платформы: Социальный беттинг / Игровые споры на дисциплину (Peer-to-Peer 도전戰). Задача Исполнителя: Полный цикл разработки (UI/UX Дизайн в Figma, фронтенд, бекенд-сервер, база данных, интеграция IoT-датчика контроля и платежного шлюза). Мультиязычность: Полная поддержка локализации (i18n) и работа с несколькими валютами. 2. Требования к UI/UX Дизайну Необходима разработка современного, неоново-технологического интерфейса в темных тонах (Dark Mode). Акцентные цвета: Глубокий графитовый (фон), яркий зеленый (финансы, баланс), яркий красный (режим охраны включен, штрафные события). Функционал: Отображение 4 главных экранов нижней навигации (Дашборд, Игровые комнаты, Кошелек, Настройки устройства). Нужны динамические анимации изменения баланса и всплывающих алертов. 3. Финансовая архитектура (Escrow/Holding/Split) Приложение обязательств на удержание депозитов за соблюдение правил дисциплины. Критически важна интеграция платежного шлюза, поддерживающего Split Payments (Разделение платежей) и Холдинг средств (Stripe Connect для глобального рынка/аналоги для локального). Логика транзакций (API-команды бекенда): Пополнение: Средства пользователей привязываются к их аккаунту и замораживаются на транзитном (эскроу) счете платежной системы. Они не поступают непосредственно на счет компании. Режим SOLO: При наступлении триггерного события от IoT-датчика в запрещенные часы бекенд дает команду платежной системе перевести фиксированную сумму (штраф) с транзитного счета пользователя на расчетный счет компании. Режим GROUP (Комнате): Пользователи формируют общий пул (например, 10 человек по $10). Деньги замораживаются в пределах конкретной Игровой Комнаты. При наступлении триггерного события у одного из участников сумма его штрафа автоматически разделяется: 15% (комиссия платформы) идут на расчетный счет компании, а 85% остаются внутри призового фонда комнаты. После окончания срока челленджа бекенд автоматически распределяет накопленный призовой фонд между победителями, а платежная система делает автоматический перевод (Payout) им на карты. 4. Структура кабинетов Кабинет 1: "Персональный Трекер" (Режим SOLO) Индикатор статуса мониторинга (Активный/Доступный/Заблокированный). Конфигуратор временных интервалов охраны (Time Picker) и настройки стоимости штрафного триггера. Панель состояния внешнего устройства IoT (заряд батареи датчика в %, уровень сигнала, статус синхронизации). Кабинет 2: «Игровые Комнаты» (Режим GROUP) Инструментарий создания приватных комнат (генерация инвайт-ссылок/код для друзей) и список публичных глобальных лиг. Турнирная таблица (Лидерборд) участников с отображением их текущего статуса в реальном времени, таймер до конца челленджа и встроенный групповой чат. Общий раздел: Мультивалютный кошелек Отображение баланса с автоматическим конвертированием локальных валют в реальном времени. История транзакций с прозрачным логом списаний, комиссий и выигрышей. 5. Требования к Бекенду и Интеграции IoT Стек: Node.js/Python/Go (на выбор исполнителя, аргументированно). Связь с IoT: Прием пакетов данных от внешнего Wi-Fi модуля. Скорость отправки Push-уведомления (через FCM) на смартфон при наступлении события от датчика – менее 1 секунды. Антифрод-логика: Сервер должен анализировать переданные датчиком телеметрические данные встроенного акселерометра (accel_x/y/z). Если событие происходит при нулевой изменении осей ускорения, транзакция помечается системой как подозрительная (защита от статического удержания датчика), пользователю отправляется предупреждение.
звонки осуществляются через SIM-карту на iPhone, то нужно автоматически передавать информацию о входящих/исходящих звонках в CRM