O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Gerenciamento de energia do app

No Android 9 e versões mais recentes, a plataforma pode monitorar aplicativos em busca de comportamentos que afeta negativamente a duração da bateria dos dispositivos. A plataforma usa e avalia as regras de configuração para fornecer um fluxo de UX que ofereça aos usuários a opção de restringir os apps que violam as regras.

No Android 8.0 e versões anteriores, havia restrições relacionadas a recursos. como Soneca, App em espera, limites e localização em segundo plano limites. No entanto, alguns aplicativos continuaram a apresentar maus comportamentos, que estão descritos em Android vitals. O Android 9 introduziu uma infraestrutura de SO que pode detectar e restringir apps com base em regras de configuração que podem ser atualizadas ao longo do tempo.

Restrições de segundo plano

Os usuários podem restringir apps, ou o sistema pode sugerir apps detectar estão afetando negativamente a integridade do dispositivo.

Apps restritos:

Ainda pode ser iniciado pelo usuário.
Não é possível executar jobs/alarmes nem usar a rede em segundo plano.
Não é possível executar serviços em primeiro plano.
Pode ser alterado para um app irrestrito pelo usuário.

Os implementadores de dispositivos podem adicionar outras restrições aos apps para:

Impedir que o app seja reiniciado automaticamente.
Restringir os serviços de serem vinculados (alto arriscado).

Os apps restritos em segundo plano não consomem recursos do dispositivo, como memória, CPU e bateria. Apps restritos ao segundo plano não devem afetar a integridade do dispositivo quando o usuário não estiver usando esses apps ativamente. No entanto, espera-se que os mesmos aplicativos sejam totalmente funcional quando o usuário iniciar os aplicativos.

Usar implementações personalizadas

Os implementadores de dispositivos podem continuar usando os métodos personalizados para aplicar restrições aos apps.

Integrar restrições de apps

As seções a seguir descrevem como definir e integrar aplicativos restrições no seu dispositivo. Se você usa métodos de restrição de apps do Android 8.x ou versões anteriores, leia atentamente as seções a seguir mudanças no Android 9 e versões mais recentes.

Definir a flag do AppOpsManager

Quando um app for restrito, defina a flag adequada AppOpsManager: Um exemplo de snippet de código packages/apps/Settings/src/com/android/settings/fuelgauge/BatteryUtils.java:

   public void setForceAppStandby(int uid, String packageName,
            int mode) {
        final boolean isPreOApp = isPreOApp(packageName);
        if (isPreOApp) {
       // Control whether app could run in the background if it is pre O app
            mAppOpsManager.setMode(AppOpsManager.OP_RUN_IN_BACKGROUND, uid, packageName, mode);
        }
       // Control whether app could run jobs in the background
        mAppOpsManager.setMode(AppOpsManager.OP_RUN_ANY_IN_BACKGROUND, uid, packageName, mode);
    }

Verifique se isBackgroundRestricted retorna verdadeiro

Quando um app for restrito, confira se ActivityManager.isBackgroundRestricted() retorna true.

Registre o motivo da restrição

Quando um app for restrito, registre os motivos. Um um exemplo de snippet de código do registro packages/apps/Settings/src/com/android/settings/fuelgauge/batterytip/actions/RestrictAppAction.java:

mBatteryUtils.setForceAppStandby(mBatteryUtils.getPackageUid(packageName), packageName,AppOpsManager.MODE_IGNORED);
if (CollectionUtils.isEmpty(appInfo.anomalyTypes)) {
  // Only log context if there is no anomaly type
  mMetricsFeatureProvider.action(mContext,
    MetricsProto.MetricsEvent.ACTION_TIP_RESTRICT_APP, packageName,
    Pair.create(MetricsProto.MetricsEvent.FIELD_CONTEXT,metricsKey));
            } else {
  // Log ALL the anomaly types
  for (int type : appInfo.anomalyTypes) {
    mMetricsFeatureProvider.action(mContext,
      MetricsProto.MetricsEvent.ACTION_TIP_RESTRICT_APP, packageName,
      Pair.create(MetricsProto.MetricsEvent.FIELD_CONTEXT, metricsKey),
      Pair.create(MetricsProto.MetricsEvent.FIELD_ANOMALY_TYPE, type));
  }

Substitua type pelo valor de AnomalyType.

Os implementadores de dispositivos podem usar as constantes definidas em src/com/android/settings/fuelgauge/batterytip/StatsManagerConfig.java:

public @interface AnomalyType {
// This represents an error condition in the anomaly detection.
int NULL = -1;
// The anomaly type does not match any other defined type.
int UNKNOWN_REASON = 0;
// The application held a partial (screen off) wake lock for a period of time that
// exceeded the threshold with the screen off when not charging.
int EXCESSIVE_WAKELOCK_ALL_SCREEN_OFF = 1;
// The application exceeded the maximum number of wakeups while in the background
// when not charging.
int EXCESSIVE_WAKEUPS_IN_BACKGROUND = 2;
// The application did unoptimized Bluetooth scans too frequently when not charging.
int EXCESSIVE_UNOPTIMIZED_BLE_SCAN = 3;
// The application ran in the background for a period of time that exceeded the
// threshold.
int EXCESSIVE_BACKGROUND_SERVICE = 4;
// The application exceeded the maximum number of wifi scans when not charging.
int EXCESSIVE_WIFI_SCAN = 5;
// The application exceed the maximum number of flash writes
int EXCESSIVE_FLASH_WRITES = 6;
// The application used more than the maximum memory, while not spending any time
// in the foreground.
int EXCESSIVE_MEMORY_IN_BACKGROUND = 7;
// The application exceeded the maximum percentage of frames with a render rate of
// greater than 700ms.
int EXCESSIVE_DAVEY_RATE = 8;
// The application exceeded the maximum percentage of frames with a render rate
// greater than 16ms.
int EXCESSIVE_JANKY_FRAMES = 9;
// The application exceeded the maximum cold start time - the app has not been
// launched since last system start, died or was killed.
int SLOW_COLD_START_TIME = 10;
// The application exceeded the maximum hot start time - the app and activity are
// already in memory.
int SLOW_HOT_START_TIME = 11;
// The application exceeded the maximum warm start time - the app was already in
// memory but the activity wasn't created yet or was removed from memory.
int SLOW_WARM_START_TIME = 12;
// The application exceeded the maximum number of syncs while in the background.
int EXCESSIVE_BACKGROUND_SYNCS = 13;
// The application exceeded the maximum number of gps scans while in the background.
int EXCESSIVE_GPS_SCANS_IN_BACKGROUND = 14;
// The application scheduled more than the maximum number of jobs while not charging.
int EXCESSIVE_JOB_SCHEDULING = 15;
// The application exceeded the maximum amount of mobile network traffic while in
// the background.
int EXCESSIVE_MOBILE_NETWORK_IN_BACKGROUND = 16;
// The application held the WiFi lock for more than the maximum amount of time while
// not charging.
int EXCESSIVE_WIFI_LOCK_TIME = 17;
// The application scheduled a job that ran longer than the maximum amount of time.
int JOB_TIMED_OUT = 18;
// The application did an unoptimized Bluetooth scan that exceeded the maximum
// time while in the background.
int LONG_UNOPTIMIZED_BLE_SCAN = 19;
// The application exceeded the maximum ANR rate while in the background.
int BACKGROUND_ANR = 20;
// The application exceeded the maximum crash rate while in the background.
int BACKGROUND_CRASH_RATE = 21;
// The application exceeded the maximum ANR-looping rate.
int EXCESSIVE_ANR_LOOPING = 22;
// The application exceeded the maximum ANR rate.
int EXCESSIVE_ANRS = 23;
// The application exceeded the maximum crash rate.
int EXCESSIVE_CRASH_RATE = 24;
// The application exceeded the maximum crash-looping rate.
int EXCESSIVE_CRASH_LOOPING = 25;
// The application crashed because no more file descriptors were available.
int NUMBER_OF_OPEN_FILES = 26;
}

Quando o usuário ou o sistema remove as restrições de um app, você precisa registrar os motivos para remover as restrições. Um exemplo de snippet de código do registro packages/apps/Settings/src/com/android/settings/fuelgauge/batterytip/actions/UnrestrictAppAction.java:

public void handlePositiveAction(int metricsKey) {
        final AppInfo appInfo = mUnRestrictAppTip.getUnrestrictAppInfo();
        // Clear force app standby, then app can run in the background
        mBatteryUtils.setForceAppStandby(appInfo.uid, appInfo.packageName,
                AppOpsManager.MODE_ALLOWED);
        mMetricsFeatureProvider.action(mContext,
                MetricsProto.MetricsEvent.ACTION_TIP_UNRESTRICT_APP, appInfo.packageName,
                Pair.create(MetricsProto.MetricsEvent.FIELD_CONTEXT, metricsKey));
    }

Testar restrições de apps

Para testar o comportamento de restrições de apps no Android 9 e versões mais recentes, use um dos seguintes comandos:

Colocar um app em restrição:

appops set package-name RUN_ANY_IN_BACKGROUND ignore

Remova um app da restrição e restaure o comportamento padrão:
```
appops set package-name RUN_ANY_IN_BACKGROUND allow
```

Para fazer um app em segundo plano ficar inativo imediatamente:

am make-uid-idle [--user user-id | all | current] package-name

Adicione um pacote a tempwhitelist por um curto período:

cmd deviceidle tempwhitelist [-u user] [-d duration] [package package-name]

Adicione/remova um pacote da lista de permissões do usuário:
```
cmd deviceidle whitelist [+/-]package-name
```
Verifique o estado interno da jobscheduler e do gerenciador de alarmes:
```
dumpsys jobscheduler
dumpsys alarm
```

Aplicativo em espera

O App em espera aumenta a duração da bateria adiando a rede em segundo plano atividades e jobs para apps que o usuário não está usando ativamente.

Ciclo de vida do App em espera

A plataforma detecta apps inativos e os coloca no app em espera até que o usuário comece a interagir ativamente com o aplicativo.

Durante a fase de detecção, a plataforma detecta que um app está inativo quando o dispositivo não estiver carregando e o usuário não tiver iniciado o app diretamente ou indiretamente por um período específico de tempo do relógio e por um período específico de tempo de tela. As inicializações indiretas ocorrem quando um app em primeiro plano acessa um serviço em um segundo app.

No app em espera, a plataforma impede que apps acessem a rede por mais tempo de uma vez por dia, adiando sincronizações de apps e outras tarefas.

A plataforma saia do app do modo de espera quando:

O app vai ficar ativo.
O dispositivo está conectado e carregando.

Os apps ativos não são afetados pelo recurso App em espera. Um app fica ativo quando tem:

Um processo atualmente em primeiro plano (como uma atividade ou um serviço em primeiro plano ou em uso por outra atividade ou serviço em primeiro plano), como ouvinte de notificações, serviços de acessibilidade, plano de fundo interativo etc.
Uma notificação visualizada pelo usuário, como na tela de bloqueio ou bandeja de notificação
Iniciado explicitamente pelo usuário

Um app ficará inativo se nenhuma das atividades acima tiver ocorrido por um período. período.

Testar o App em espera

É possível testar manualmente o App em espera usando a seguinte adb: comandos:

adb shell dumpsys battery unplug
adb shell am set-idle package-name true
adb shell am set-idle package-name false
adb shell am get-idle package-name