Олег

Запрещенные действия. Лицензия для использования сервисов "Google Карты" и "Google Планета Земля" предоставляется Вам на условии соблюдения требований, изложенных в Разделе 2. При использовании сервисов "Google Карты" и "Google Планета Земля" Вам и действующим от Вашего имени лицам запрещается:

распространять или продавать любые компоненты сервисов "Google Карты" или "Google Планета Земля" либо создавать новые продукты или сервисы на базе сервисов "Google Карты" или "Google Планета Земля" (кроме случаев использования Google Maps API и Google Earth API в соответствии с их Условиями использования);

Смотрим апи шарика
https://developers.google.com/earth-engine/referen...
А там интересный момент с авторизацией.
Там все как бы намекает - у Вас должен быть свой бакенд.
Ну не кузяво приватную инфу в код апк помещать.

И еще момент. Стукнулся в гугл по живым обоям. А там как-то даты обновления не очень свежие. Подозрительно
https://developer.android.com/reference/android/ap...
не знаю каким способом вы хотели картинку показывать
переодической сменой или самостоятельно канву перерисовывать.
Но вот по ссылке кучу методов можно считать "мертвыми".
only apps with Manifest.permission.MANAGE_EXTERNAL_STORAGE
А вот модерация Вас не пропустить с таким разрещением ( ну или долго будете с ней бодаться)

Еще момент Вы собираетесь конкретный ракурс по координатам пользователя показывать ?
Обломинго. Опять секьюрность. Получение гео локации в фоне - красная тряпка для модерации

Увы, но андроид все больше скатывается в платформу для игрушек. Борьба за жизнь батарейки
делает использование служб все более сложным.
https://developer.android.com/develop/background-w...
Сейчас это пермишен и декларация целей использования.
Часть целей автоматом подтверждает робот (ИИ) смотрит, что у тебя еще например пермишины для работы с блютуз устройством и что программа действительно с ними работает (по описанию и наличию вызовов нужных методов).
А вот прочие цели придется дополнительно декларировать в кабинете разработчика.

В 13-м поменяли как служба может показать нотифи в шторке. Их теперь прячут от пользователей по умолчанию.

До сих пор остается актуальным способ "Please don't kill me". Отправлять пользователя в раздел настроек системы для включения приложения в исключения энергосбережения.

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

В общем, я плюнул и свою службу печати теперь стал просто биндить из активити (тема диалог с запретом гасить экран)

проверка на нул,
https://developer.mozilla.org/en-US/docs/Web/JavaS...
если объект то что у него нет пропертей
https://stackoverflow.com/questions/679915/how-do-...
и в случае массива что длина больше нуля

Такое впечатление, что драйвер рендерит изображение чуть не 75 дпи.
А тестовое вложение на 1200 .

Точки это работа алгоритма дизеринга и белые полоски на буквах по той же причине. Просто на высоком разрешение их не замечаете

Возможно.
HTML, JS, CSS, IMG все нормально будет подгружаться из андроид assets.
Только аккуратно придется с путями.

Можно даже взаимодействовать с приложением
https://developer.android.com/develop/ui/views/lay...

Начальный урл будет вида
file:///android_asset/app/index.html

бак и фронт - жаргонизмы.
ЯВУ и стеков очень много.
Поэтому в зависимости от стека говорящие вкладывают немного различный смысл.
Общее тут, что
фронт - часть для взаимодействия с пользователем.
бак - скрытая от пользователя реализация бизнес логики приложения (полезных действий).

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

Чуть усложним. Привычное для пользователей приложение. Разработчики пишут их разделяя код
на части. (рисующие экран пользователя, хранящие данные, делающие действия, реагирущие на тапы/клики/ввод)
Тут тоже получается можно поделить на фронт и бек.

Теперь возмем CMS для сайта. Во фронт можно отписать шаблоны страниц, а сам движок в бакенд.

Ок. Сферический сайт PHP+MYSQL+JS+HTML+CSS
тут вроде просто. То что пишем на PHP+MYSQL бакенд. HTML+JS+CSS - фронт
И уточнять словом сервер нет необходимости. Работу можно поделить между верстальщиком и программистом.

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

Вернемся к приложениям.
"бакенд - сервер" означает, что приложение имеет серверную часть.
тут пригодиться еще один термин API - Aplitation Protocol Interface.

Технологий как с телефона/компьютера обратиться к серверу в интернете придумали достаточно много.
Простейшая из них очень похожа на общение с сайтом (GET/POST), только вместо HTML программам удобнее разбирать структуированные данные (json или xml)

Самое прикольное, что на каждом уровне цепочки общения что-то можно назвать фронтом и беком.
https://stackoverflow.com/questions/73778563/nginx...
Пример со стековерфлоу.
Nginx - общается с пользователями. Но вот человек вполне понятно для других спросил про фронт-сервер и бакенд. Откуда будут браться статические данные и куда передавать запросы требующие обработки.

Так, что "сервер" в названии это уточнение, что часть бизнес логики выполняется на другой машине (не текущей) или за нее отвечает другая программа

<?php
$mysecret = 'supersecret';

Минимальный совет из "PHP Правильный путь" звучит как храните свои конфиги хотя бы в виде php файлов.
Предположим, что мы сохранили такой скрипт в корне www.
При правильной настройке сервера посетитель увидит пустой экран по урлу //your.site/script.php
так как в нашем файле нет команд вывода.
В первой строке полный синтаксис, в варианте "<?" может случиться ситуация показа исходного текста, если сшорт таги отключены. И остается риск того, что php отвалиться и будет показываться исходный код.

Обще принятой практикой сейчас считается подход, когда все исходные файлы лежат выше диретории www рут.
В самой директории только один скрипт точки входа (index.php)

Ваши пароли скорее утекут по другой причине, чем из-за того, что к скрипту обратяться на прямую.

Вы используете eval c данными от пользователя или на сайте можно загружать через форму файлы.
На шаред хостинге ошиблись с разделением прав для ftp.

У Вас используются системы контроля версий кода и конфиги не добавлены в игнорируемые.

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

Идеально для рекламодателя. За цену одного показа аудитория, сидящая за одним NAT сервером.

Откройте логи своего сервера. Посчитайте кол-во строк с запросом какой нибудь внутренней страницы.
сравните с числом уникальных айпи с которых к ней были обращения.

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