[–] 8 points 4 weeks ago

There are apps that do this, or try to. But I think they need root, and success varies a lot by phone manufacturer and country of origin.

For one example, there's an old Android app called Telman real answering machine. I doubt it works on modern phones. Might work on an older model.

Corpos lock shit down tight, because they think they need to own all of it.

  • source
  • [–] 6 points 4 weeks ago

    I never got that either. We could just have an answering machine app, a telefax app or even an corporate interactive voice response menu. I don't think there's any technical reason for these things not existing. It's just audio transmitted over an audio channel.

  • source
  • [–] 12 points 4 weeks ago* (last edited 4 weeks ago) (1 child)

    Yes. Pixels now do it. It's slick.

    If the phone is disconnected from the network, the provider's voicemail service handles it.

    Edit: here's the support page describing it. It's like old school answering machines, except that you see the live transcript, so you can decide to interrupt if you want to take the call. It's really good.

  • source
  • [–] 1 point 4 weeks ago (4 children)

    in some cases i've seen fastboot command return error on console but actually succeed in executing the wanted behavior, so it might be the case here that our boot.img did successfully boot.

    by 'device reboots and trying to start android', do you mean the device actually rebooted again to bootloader stage (e.g. vibrate and show manufacturer logo), or just boot android without that step? an easy way to confirm this is by holding fastboot or recovery hotkey right after fastboot command. if it did reboot and start again from bootloader it will enter fastboot/recovery, but if it didn't and actually booted our new boot.img it would just boot android

  • source
  • parent
  • context
  • [–] [S] 1 point 4 weeks ago (5 children)

    After fastboot command device reboots and trying to start android, I think and then just shows me error screen again. Yeah, I tried sudo, but didn't help. I tried 37.0.0 version too and result the same. Idk this phone is cursed.

  • source
  • parent
  • context
  • [–] 1 point 4 weeks ago (6 children)

    hmm that's weird.

    after the fastboot boot command fails, what does the device show on screen? is it stuck on fastboot? or reboots?

    perhaps doing fastboot boot as sudo might help.

    did you install fastboot from your linux distro's repo? what version is it? (it might be very outdated and be the cause of issues)

  • source
  • parent
  • context
  • [–] [S] 1 point 4 weeks ago (7 children)

    Hey! I found a little bit of time to try it out! Thank you very much for trying to help me! When I trying to boot it up I getting:

    fastboot boot tecno-ki7_boot_adb.img
    Sending 'boot.img' (26862 KB)                      OKAY [  0.655s]
    Booting                                            FAILED (Status read failed (No such device))
    fastboot: error: Command failed
    

    and logs from dmesg: https://0bin.ch/?51a49ed0a5778a18#DPxaTLsafGXC2jEokDCF5mZ2YiexKJHoYkz7GCthwMNa Also adb devices and adb shell does nothing.

  • source
  • parent
  • context
  • [–] [B] 1 point 1 month ago

    The reason microG didn't help is that it's solving a different problem. It reimplements the Play Services APIs, so push notifications and maps come back, but it can't produce a Play Integrity verdict — that needs an attestation signed by Google and tied to a locked bootloader and the device's hardware keystore. Banks almost always check MEETS_DEVICE_INTEGRITY, and nothing running in userspace can fake it.

    So "a bank whose app works without Play Services" really means "a bank that doesn't call Play Integrity". Annoyingly that's the question to ask them and nobody in support will know what you're talking about.

    On the 2027 verification thing driving this: from what's been written about it, it applies to certified devices, which means ones shipping GMS, and non-certified ROMs sit outside it. If that holds then degoogling removes that worry rather than racing it. I haven't seen Google state it in their own words though, so I wouldn't plan around it yet.

  • source
  • [–] [B] 1 point 1 month ago

    I shipped an app under a hard rule that android.permission.INTERNET must not appear in the released manifest, so I went looking for this systematically. Answering your actual question, and then the part of this thread I think is wrong.

    I checked a handful of library manifests directly rather than going from memory, and got two of my own guesses wrong, which turned out to be the useful result:

    • Firebase declares it per module. firebase-crashlytics, firebase-config, firebase-perf, firebase-firestore, firebase-storage, firebase-database and firebase-functions each declare INTERNET in their own src/main/AndroidManifest.xml. Crashlytics on its own is enough. Most people expect Analytics to be the culprit and add Crashlytics without thinking.
    • Glide does not, and neither does Coil. I was fairly sure they did. In both repos INTERNET appears only in the sample apps and instrumentation tests — Glide expects you to declare it.
    • ExoPlayer / media3 does not either, same pattern: demos and androidTest only.

    So the honest answer to "which libraries are the common offenders" is that you cannot predict it, and the two I would have warned people about were clean. That is the argument against the "you should have checked your merged manifest" line in this thread — not that checking is wrong, but that it is a one-time read of a build artifact. Six weeks later someone bumps a version, the permission comes back, and nobody reopens manifest-merger-release-report.txt.

    What holds is a check on the shipped artifact, in CI:

    aapt2 dump permissions app-release.apk
    

    That reflects what the store is actually serving rather than what your source says. Fail the build if INTERNET appears and the question stops depending on anyone remembering. It has caught a reintroduction for me once already.

    One trap if you go that way: tools:node="remove" will strip the permission from the merged manifest, and if the library genuinely needs the network you have turned a build error into a runtime crash on a path you may not test. Dropping the dependency is the real fix, as you did with ZXing.

    Your first takeaway deserves underlining. Exodus is signature matching against known trackers, so "0 trackers" means "none it recognises". The permission list is extracted from the binary. Different kind of evidence entirely.

  • source
  • [–] [B] 3 points 1 month ago (1 child)

    Worth flagging a catch with the per-app rule approach: blocking the app on Wi-Fi isn't the same as forcing it onto 5G.

    Android routes an app over whatever the default network is, and that's Wi-Fi whenever Wi-Fi is up. A per-app firewall rule denies the app on Wi-Fi — it doesn't reroute it to cellular. So the likely result is the app has no connectivity at all while you're on Wi-Fi, rather than quietly using 5G. Only the app itself can pin to a transport, by requesting a network with TRANSPORT_CELLULAR, and almost none do.

    For the lag you're actually describing — commands dropped during the 5G/Wi-Fi handover — the thing that usually helps is stopping the handover happening at the moment you press the button, rather than per-app routing. Worth checking whether your smart home app has a local/LAN mode that talks to the hub directly instead of round-tripping through its cloud, since that removes the problem instead of working around it.

    Happy to be wrong if someone's got Rethink actually moving an app onto cellular while Wi-Fi is connected — that'd be useful to know.

  • source
  • view more: ‹ prev next ›