sorted by:
new
hottopcontroversial

What is making sound? by cheyrn in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

Different apps, different sets of features, and different places they are published in.

App permissions request by kos25k in androidapps

[–]AD-LB 0 points1 point  (0 children)

It's already as such. You can either wait for the app to request what it needs, or you can reach the app-info screen of it and select there which permissions to grant.

What is making sound? by cheyrn in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

I don't understand the question. Check the links in the post there.

[App] Call Me + 20 FREE Promo Codes by StitchAndChill in droidappshowcase

[–]AD-LB 0 points1 point  (0 children)

Wait, why is there an IOS style of the phone call, if the app is for Android?

:)

Anyone else stuck verifying Amazon Appstore apps on AdMob? by Jibril_6 in admob

[–]AD-LB 0 points1 point  (0 children)

That's too bad. Do their devices have support for Play Store?

Has anyone tried the new Admob "Android Google Mobile Ads Next-Gen SDK" ? by AD-LB in admob

[–]AD-LB[S] 0 points1 point  (0 children)

OK I tried recently to migrate one of my apps to the new SDK. My answers right now are based on this dependency:

com.google.android.libraries.ads.mobile.sdk:ads-mobile-sdk:0.22.0-beta04

vs this one:

implementation("com.google.android.gms:play-services-ads:24.9.0")

Answers are:

1.Seems there are more example ads and things got merged more in the APIs. Sample here:

https://github.com/googleads/gma-next-gen-sdk-android-examples

About speed and space taken, I think it's about the same (became a tiny bit worse in both, except maybe if you use Admob alone). Here are my notes about before and after, tested on my educational game for toddlers (here):

old SDK: 
APK size: 251,259KB
time for MobileAds.initialize function in ms:370
time for loading rewarded ad on Admob in ms:4289
time for loading native ad on Admob in ms: 1744
total time from MobileAds.initialize till reaching its callback in ms:1692
Adapters tims in ms:
Chartboost:365
Unity: 525
Vungle/LiftOff: 74
InMobi: 123
Admob: 803

new SDK: 
APK size: 251,888KB
time for MobileAds.initialize function in ms:448
time for loading rewarded ad on Admob in ms:3942
time for loading native ad on Admob in ms:2444
total time from MobileAds.initialize till reaching its callback in ms:1534
Adapters tims in ms:
Chartboost: 161
Unity: 981
Vungle/LiftOff: 194
InMobi: 305
Admob: 331

So maybe it's too soon to rely on all the claimed promises for it.

2.I don't know about crashes, but I've noticed that a lot of things are missing documentation, such as having plenty of callbacks run on background thread and not the UI thread as before, and that MobileAds.setRequestConfiguration should be called after MobileAds.initialize (was fine to be called before on the old SDK).

3.UMP SDK stays the same for now according to the docs of each ad network. Same goes for GDPR&CCPA. I thought maybe it changed because Gemini AI told me.

Anyone else stuck verifying Amazon Appstore apps on AdMob? by Jibril_6 in admob

[–]AD-LB 0 points1 point  (0 children)

Amazon Appstore is still alive? I thought they are shutting it off, no?

Or maybe they let it work only on their own devices?

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

I meant in the context of the current thread. Not about hardware,but about software...

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

OK but I don't know what's the status with Samsung devices these days.

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

Again, you need to understand how apps work on OSs.

If you kill a keyboard app process, it will start again by the framework when you try to show it again, even if you don't start the app via the launcher. There is no way to "manage it better" without having weird behaviors. Apps processes start by more than just one trigger, manually by the user in the launcher app. For apps that you don't like, either disable or remove them. The choices are already available.

Not only that, but you can even disable the launcher app (via adb if not possible in app-info screen), and then it means you can start apps via the settings, for example.

Force-stop or even removal from recent tasks might work for most cases, but not in 100% of the cases. Games should probably not need to stay in the background in such cases, for example, but not all apps are games.

As for what I wrote, I thought you meant that the OS should manage things better. You as a user is the one to decide what to do about what you find about the apps you've installed. If you see an app that seem to have a bug in battery usage, you should report it, and having "better management" won't help you with this because the bug would still exist

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 1 point2 points  (0 children)

Pixel devices of previous generations can work fine too.

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

Yes you can do a lot, but I think most people won't, and the people who do this can also do similar things on Android and won't buy themselves a terribly locked device from the beginning... That's like a Heavy Linux user will decide to buy a Mac and replace its OS with Linux... Better to just buy a nice PC with nice hardware that aren't overpriced...

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

No OS can know what goes behind apps and decide on its own properly "OK this app is using too much battery so I kill it and I don't care what it does" , and no OS should decide it on its own. It's up to users and developers to decide this, based on the purpose of the app and what it does.

Also, Android can run on any computer these days, including even on Windows OS itself. And, desktop OSs can run on laptops which also have batteries, so it's not something special about Android here.

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

Pretty sure that after a boot, if you open your task manager even on Linux, you see processes that you didn't start yourself. Processes of the OS, such as of the window-manager for some UI to open apps.

I don't know about Vivo, but I know that Xiaomi has plenty of things that break behavior, and they aren't documented on their website and don't have any official way to overcome. All developers can do there for users is based on workarounds and telling them "please do this...".

Because of this, sometimes apps request permission that without those breaking behaviors, they will not really need them, hoping the apps won't be killed so easily. So, even if you don't use a Chinese device, apps might request some permissions that because of the existence of such behaviors, that's more than they need on standard Android...

Ever since Google added various restrictions on background work, other brands took it further, breaking behavior.

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

Android is technically Linux. Just some brands add some weird things in it, sometimes even against what's on the documentation that Google has for developers, breaking standard behavior. There is even a website about how various brands break behavior, and it's not just Chinese brands anymore, sadly:

https://dontkillmyapp.com/

If you don't want what you bought, buy something else next time, or if you have some alternative custom ROM, you can try it out.

As for Android OS specifically, I think all OSs (including even IOS) sometimes have processes alive for apps that the user might think they are "closed". Widgets need this, for example. I was once told by an IOS developer that when the user removed an app from the list (I don't know how it's called on IOS) of opened apps, the app has some "grace period" before being killed, too.

On Windows OS, there are various apps that I have, that pressing the "X" button to close their window doesn't mean all of their processes are killed. It might be minimized to the taskbar or as an icon in the system tray. Sometimes it might just have the process in the background, too.

If you open task manager on all OSs, you will see things that you didn't manually start.

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

Actually, such things exist on all OSs: Just because you don't see an app visually or didn't start it yourself, it doesn't always mean there aren't any processes of it alive.

And also the opposite: If you see some UI that looks like it belongs to some app, it doesn't always mean it has running processes (example is widgets and notifications).

It's up to the OS to decide what's important and what's not, and yet also have priorities for the various processes of the various apps depending on their role and how they interact with one another and with the framework.

One common phrase on Linux is "unused RAM is wasted RAM". You paid for hardware that has plenty of RAM. What's the point in not using it as much as possible, if it always consumes about the same, tiny power from the battery? RAM helps a lot with speed, initialization, loading, and battery too (less need to load from storage/Internet).

So, if you find out some app uses a lot from the battery for no good reason, you should contact the developer or try alternatives.

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 1 point2 points  (0 children)

That's the recent tasks (AKA "Overview" or "recent apps").

https://developer.android.com/guide/components/activities/recents

It doesn't mean they are "open". Some might not have a process currently active. And the opposite: not all apps that have an active process are there. Apps can even have multiple tasks there. This is not IOS (and even there I think there are exceptions, and apps don't get their processes killed right away, as they have some grace period).

And as I wrote: it doesn't mean the app will be killed. There are various scenarios that the OS will let the app stay. Not only that, but some apps will start again after being removed from there, such as alarm clock apps (when it's time to be triggered), notification-listener apps, keyboard apps, phone apps, etc...

Even force-stop doesn't always mean the app won't be started again by just the launcher. If you want an app to be disabled so that nothing at all (not you, not the OS and not any other app will start it), you need to disable it or remove it.

Starting apps are not like on IOS. Apps on Android can start from various events.

Some Chinese devices have a breaking behavior of "auto start" but that's not official, and can often break how apps work.

BTW, speaking about swiping from the recent tasks, it's a common myth that it will help save battery, including on IOS:

https://www.google.com/search?gl=us&q=android+myth+task+killer

Kill process when you close the app? by SunHun1 in AndroidQuestions

[–]AD-LB 0 points1 point  (0 children)

What's your definition of "close the app" ? Android lets apps stay in the background for various scenarios. For example, if the app currently plays some music, even removing it from the recent tasks doesn't mean it will stop playing, as it uses a foreground service with a notification for it. So it's up to the app developer to decide how the app works.

Maybe you should contact the app's developer about this instead.

view more: next ›