Поделитесь системным сервисом из плагина, чтобы избежать слишком большого количества запросов на разрешение - PullRequest
0 голосов
/ 15 июня 2011

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

Моя идея заключалась в том, чтобы иметь отдельный apk (своего рода плагин), который предоставляет только основное приложение.с информацией о местоположении, так что только плагин должен запрашивать разрешение на местоположение.

Можно ли разрешить плагину совместно использовать системный сервис (LocationManager) напрямую, не создавая пользовательский сервис с несовместимым интерфейсом, так что основнойПриложение может использовать LocationManager плагина.Это позволило бы использовать существующие классы, такие как MyLocationOverlay или другие.Основное приложение может передавать ContextWrapper следующим классам:

public static class LocationContext extends ContextWrapper {

    public LocationContext(Context base) {
        super(base);
    }

    @Override
    public Object getSystemService(String name) {
        if (name.equals(LOCATION_SERVICE)) {
            // Return the LocationManager service of the plugin here...
        }
        return super.getSystemService(name);
    }

}

Ответы [ 3 ]

2 голосов
/ 15 июня 2011

Не уверен, что я полностью понимаю ваш вопрос, но одно приложение может загружать классы из другого приложения и, таким образом, избегать пересечения границ процесса.Ключ имеет одинаковые атрибуты android: process и android: sharedUserId в ваших манифестах для обоих aps.Затем приложения будут запускаться в том же процессе Linux на устройстве.Затем вы можете использовать API отражения для программной загрузки классов приложения A из приложения B и наоборот.Если приложение A уже есть в Маркете, вам, вероятно, потребуется выпустить новую версию, которая добавляет атрибуты process и sharedUserId, а затем выпустить приложение B с такими же атрибутами.

1 голос
/ 08 ноября 2012

Да, это возможно, однако я настоятельно рекомендую инженерам ОС Android отключить эту возможность, а также любой другой способ использования 2 дружественных приложений (с одинаковыми uuid, с одинаковыми сигнатурами), использующих друг друга, поскольку это приводит к серьезным "дырам" в безопасности"в системе разрешений и серьезных проблемах с безопасностью Android ...

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

0 голосов
/ 15 июня 2011

Можно ли разрешить плагину совместно использовать системную службу (LocationManager) напрямую, не создавая пользовательскую службу с несовместимым интерфейсом, чтобы основное приложение могло использовать LocationManager плагина.

Это не будет возможно.LocationManager не является Parcelable, поэтому вы не можете передавать его между процессами.

Это позволило бы использовать существующие классы, такие как MyLocationOverlay или другие.

UmнетВы не написали MyLocationOverlay.Вы не можете заставить его использовать какой-то искусственный LocationManager вашего собственного дизайна.

Основное приложение может передать ContextWrapper этим классам, как это

ContextWrapper isне Parcelable, поэтому вы не можете передать его между процессами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...