Google is moving away from APKs on the Play Store
https://www.theverge.com/2021/6/30/22557390/google-apk-app-bundles-package-format-play-store

"Right now, the standard format for app publishing is the APK, but starting
in August, Google will require that _new_ Play apps are published instead
using the "Android App Bundle". The requirement to use Android App Bundles
only applies to new apps, according to Google. Existing apps are currently
exempt"

Google sunsets the APK format for new Android apps
https://www.androidauthority.com/android-apks-sunset-1636829/
"Google touted that this new format would result in smaller app file sizes"

But who cares about the puny APK/AAB app sizes anyway?

The most AABs save, according to the article, is 15% (but APKs are small to
start with). So who cares about saving "up to" 15% on APK app sizes?

"However, there are two significant issues with AABs. The first is that
developers who want their apps to appear in other distribution channels −
such as the Amazon App Store or Huawei's App Gallery − will need to manually
export APK versions of their apps. This won't require much effort on the
dev's part, but it would mean that any developer who wanted their app to
only appear on the Play Store would have that power. In those cases, end
users would need to export AABs as Android APKs on their own, as *.aab files
would not work on alternative stores.

Related: An introduction to the Google Play Console for Android Developers

The other issue is that developers will need to give Google their app
signing key to export an AAB app as an APK. This gives Google quite a bit of
power. The app signing key is basically proof that a specific developer
created a specific app. While it's unlikely Google would ever do so, it is
possible that it could sign apps on behalf of a developer. It's also
possible that someone could gain access to this key and then sign apps for
themselves. As such, some developers aren't too keen on the App Bundle
format."

paul <nospam@nospam.invalid> wrote:

> Google is moving away from APKs on the Play Store
> https://www.theverge.com/2021/6/30/22557390/google-apk-app-bundles-package-format-play-store
>
> Google sunsets the APK format for new Android apps
> https://www.androidauthority.com/android-apks-sunset-1636829/

https://developer.android.com/guide/app-bundle

AAB is only required when the app author uploads their package to the
Google Play Store. The downloads to the end devices (smartphones,
tablets, etc) will still be APKs.

"An Android App Bundle is a publishing format that includes all your
app’s compiled code and resources, and defers APK generation and signing
to Google Play."
and
"Google Play uses your app bundle to generate and serve optimized APKs
for each device configuration ..."

Whew! I thought for a moment that Google was going to fuck over their
customers with a new end-device package format that would render all old
smartphones (which don't get Android updates after a phone gets
discontinued, which about a year) unusable with a new package format at
the end device.

AAB, introduced back in May 2018, is a publishing format (app author to
Play Store), so this has been coming for 3 years, and the hammer comes
down in August. APK remains the delivery format to the end devices.

VanguardLH wrote on 01.07.2021 03:19
> AAB is only required when the app author uploads their package to the
> Google Play Store. The downloads to the end devices (smartphones,
> tablets, etc) will still be APKs.

Oh. Thanks for that bit of detail Vanguard.

I was wondering _why_ anyone would "want" an AAB if the only advantage was
it's a tiny bit smaller (which doesn't matter for most of us in terms of how
small apps are compared to how much space we have for app storage nowadays).

If the actual "download" to the device is _still_ an APK, then I'm not sure
_what_ changes for the end user. But I don't like the "optimized" part.

The question is how much of current functionality will be impacted by AABs?

> "An Android App Bundle is a publishing format that includes all your
> app�s compiled code and resources, and defers APK generation and signing
> to Google Play."
> and
> "Google Play uses your app bundle to generate and serve optimized APKs
> for each device configuration ..."

Oh. Oh. "optimized". That's potentially a bad word in terms of usefulness.
Notice there is that "optimized" marketing crap Apple pulls on its users.

What that means, for Apple users, is they can't re-use their IPAs on another
device. I hope it's not the same for Android users. That would suck.

I kind of like bringing over all my old APKs to any phone I want to.

> Whew! I thought for a moment that Google was going to fuck over their
> customers with a new end-device package format that would render all old
> smartphones (which don't get Android updates after a phone gets
> discontinued, which is about a year) unusable with a new package format at
> the end device.

What almost nobody seems to understand is _how_ Android is updated.

Nowadays, more than half of Android is updated over Google Play
independently of the carrier and the OEM, Vanguard. You can understand that
even as the apologists can't.

Even the Qualcomm drivers are updated over Google Play, much like how Nvidia
drivers are updated over the Internet, independent of Dell & HP for Windows.

And security updates are more and more frequent & for longer times nowadays.

For example, I've had cheap (but good) $100 Motorola and free Samsung phones
for the past couple of years which get so many updates it's obnoxious.

Basically they get updated monthly where the Samsung will get those updates
for at least four years and even your oldest phones _still_ get updated over
Google Play.

Bear in mind that the only common OS that does NOT get updates frequently
over the Internet is iOS, which is only updated when it has bugs (luckily,
that's a _lot_ of bugs as Safari alone has had emergency updates nine (yes,
nine!) times in the past three months alone! (We can dig up the cites.)

Notice iOS is updated a _lot_ because it _has_ to be updated whereas Android
and Windows and Linux use a completely different (modern) update mechanism.

> AAB, introduced back in May 2018, is a publishing format (app author to
> Play Store), so this has been coming for 3 years, and the hammer comes
> down in August. APK remains the delivery format to the end devices.

What I'm worried about mostly is the flexibility I have to automatically
save all my APKs _before_ they're installed, which is what I do every day.
<https://i.postimg.cc/zf8ybgYB/apk01.jpg>

Also I like _extracting_ the current set of APKs, which I do automatically.
I also like using non-Google GooglePlay clients, which I use every day.

In addition, I like being able to use any APK on any device in the world.
The question is how much of that functionality will be impacted by AABs?

In article <sbjbpc$1t24$1@gioia.aioe.org>, paul <nospam@nospam.invalid>
wrote:

> > "Google Play uses your app bundle to generate and serve optimized APKs
> > for each device configuration ..."
>
> Oh. Oh. "optimized". That's potentially a bad word in terms of usefulness.
> Notice there is that "optimized" marketing crap Apple pulls on its users.

the only thing to notice is your ignorance.

> What that means, for Apple users, is they can't re-use their IPAs on another
> device.

of course they can. quite easily, in fact.

> I hope it's not the same for Android users. That would suck.
>
> I kind of like bringing over all my old APKs to any phone I want to.

further demonstrating your ignorance.

>
> What almost nobody seems to understand is _how_ Android is updated.

mostly just you.

> Bear in mind that the only common OS that does NOT get updates frequently
> over the Internet is iOS, which is only updated when it has bugs (luckily,
> that's a _lot_ of bugs as Safari alone has had emergency updates nine (yes,
> nine!) times in the past three months alone! (We can dig up the cites.)

your lack of understanding is not limited to just android. you don't
understand how or when ios is updated either, as well as various other
operating systems.

if you're going to troll, at least find something valid.

nospam wrote on 01.07.2021 05:21
>>> "Google Play uses your app bundle to generate and serve optimized APKs
>>> for each device configuration ..."
>>
>> Oh. Oh. "optimized". That's potentially a bad word in terms of usefulness.
>> Notice there is that "optimized" marketing crap Apple pulls on its users.
>
> the only thing to notice is your ignorance.

How old are you?
When are you going to grow up?

>
>> What that means, for Apple users, is they can't re-use their IPAs on another
>> device.
>
> of course they can. quite easily, in fact.

The fact you're forced to fabricate imaginary iOS functionality tells us all
that you actually _hate_ that iOS IPA backup is a royal clusterfuck, nospam.

>> I kind of like bringing over all my old APKs to any phone I want to.
>
> further demonstrating your ignorance.

Your kindergarten cesspool comments don't change the fact that the (free)
APKs on Android work on almost any Android phone on the planet, nospam.
>>
>> What almost nobody seems to understand is _how_ Android is updated.
>
> mostly just you.

And yet, I understand project treble & project mainstream, and better yet, I
know why Apple has been forced to update iOS over nine times alone in the
past 3 months due to the bugs Apple designed into Safari alone.

*On Android, if Chrome had those 9 bugs, we'd update it over Google Play.*

Notice it's you apologists who don't understand how iOS is actually updated.

>> Bear in mind that the only common OS that does NOT get updates frequently
>> over the Internet is iOS, which is only updated when it has bugs (luckily,
>> that's a _lot_ of bugs as Safari alone has had emergency updates nine (yes,
>> nine!) times in the past three months alone! (We can dig up the cites.)
>
> your lack of understanding is not limited to just android. you don't
> understand how or when ios is updated either, as well as various other
> operating systems.

Notice your posts are always content free, nospam?
All your posts are nothing but a kindergarten cesspool.

Why?
I suspect you _hate_ the lack of functionality on iOS compared to Android.

> if you're going to troll, at least find something valid.

And yet, I provided facts and you provided nothing but kindergarten games.

How old are you?
When are you going to grow up?
--
It's highly doubtful _any_ of these dozen apologists have a college degree.
Alan Baker, Chris, Haemactylus, Joerg Lorenz, Jolly Roger,
Lewis, nospam, Rod Speed, Wade Garrett, Your Name, et al.

paul <nospam@nospam.invalid> wrote:

> VanguardLH wrote:
>
>> "Google Play uses your app bundle to generate and serve optimized APKs
>> for each device configuration ..."
>
> Oh. Oh. "optimized". That's potentially a bad word in terms of usefulness.
> Notice there is that "optimized" marketing crap Apple pulls on its users.

Don't know about Apple's behavior. Never bothered with anything Apple.

https://developer.android.com/studio/build/shrink-code
(and the link to the code optimization article)

I'm surprised the dev tools for Android projects don't already have
their own optimization settings.

paul <nospam@nospam.invalid> wrote:

> nospam wrote:
>
>> VanguardLH wrote:
>>
>>>> "Google Play uses your app bundle to generate and serve optimized
>>>> APKs for each device configuration ..."
>>>
>>> Oh. Oh. "optimized". That's potentially a bad word in terms of usefulness.
>>> Notice there is that "optimized" marketing crap Apple pulls on its users.
>>
>> the only thing to notice is your ignorance.
>
> How old are you?
> When are you going to grow up?

Don't argue with children. Tune them out.

paul wrote:

> APKs are small to start with

Are they though? I remember when app sizes where measured in kB, not
tens of MB ...

paul <nospam@nospam.invalid> wrote:
[snip]
>
> For example, I've had cheap (but good) $100 Motorola and free Samsung phones
> for the past couple of years which get so many updates it's obnoxious.
>
That's one of the reasons I gave up with my Moto, there were so many updates
it was ridiculous.

--
Chris Green
·

VanguardLH <V@nguard.lh> wrote:
> paul <nospam@nospam.invalid> wrote:
>
> > Google is moving away from APKs on the Play Store
> > https://www.theverge.com/2021/6/30/22557390/google-apk-app-bundles-package-format-play-store
> >
> > Google sunsets the APK format for new Android apps
> > https://www.androidauthority.com/android-apks-sunset-1636829/
>
> https://developer.android.com/guide/app-bundle
>
> AAB is only required when the app author uploads their package to the
> Google Play Store. The downloads to the end devices (smartphones,
> tablets, etc) will still be APKs.
>
> "An Android App Bundle is a publishing format that includes all your
> app?s compiled code and resources, and defers APK generation and signing
> to Google Play."
> and
> "Google Play uses your app bundle to generate and serve optimized APKs
> for each device configuration ..."

Full paragraph:

"Google Play uses your app bundle to generate and serve optimized APKs
for each device configuration, so only the code and resources that are
needed for a specific device are downloaded to run your app. You no
longer have to build, sign, and manage multiple APKs to optimize
support for different devices, and users get smaller, more-optimized
downloads."

This paragraph seems to imply that an APK from one device
("configuration") can not neccessarily be installed on an other device
("configuration"), even if the Android versions are the same/compatible.
If so, this is a change from the past and makes APKs, especially those
on APK 'archive' (web)sites, less useful/flexible.

For example, I've moved (save, copy, install) APKs from a Huawei phone
with Android 5 to a Samsung phone with Android 10. The old-style APK
might have included code for multiple "device configuration"s - i.e.
Huawei and Samsung in the example -, but the new-style APK might include
only code for one configuration (Huawei) and fail to install/work on the
other (Samsung). (Yes Huawei and Samsung are brands, not
"configurations", but you (hopefully) get my point.)

I hope that I'm reading this wrong, but I'm afraid I'm not.

Summary: I think "optimized APKs" come at a price. What *is* that
price?

> Whew! I thought for a moment that Google was going to fuck over their
> customers with a new end-device package format that would render all old
> smartphones (which don't get Android updates after a phone gets
> discontinued, which about a year) unusable with a new package format at
> the end device.
>
> AAB, introduced back in May 2018, is a publishing format (app author to
> Play Store), so this has been coming for 3 years, and the hammer comes
> down in August. APK remains the delivery format to the end devices.

On 1 Jul 2021 at 3:09:17 AM, Chris Green <cl@isbd.net> wrote:
>> For example, I've had cheap (but good) $100 Motorola and free Samsung phones
>> for the past couple of years which get so many updates it's obnoxious.
>>
> That's one of the reasons I gave up with my Moto, there were so many updates
> it was ridiculous.

Monthly updates are happening on my Android phone even years after I got it.
--
Cheers, Rob

Andy Burns wrote on 01.07.2021 07:13
>> APKs are small to start with
>
> Are they though? I remember when app sizes where measured in kB, not
> tens of MB ...

But Andy - the _best_ optimization can accomplish is a puny 15%.
Most likely it will be far less than that - let's argue it's only 5%.

Is it really worth losing all portability of APKs for a puny 5% decrease?

Given I know how awful the Apple "optimization" is in terms of portability,
*What is google trying to solve by moving developers from APK to AAB?*

Nobody I know of who is a _user_ was complaining about wanting this AAB
format, and worse, I am well apprised of the huge artificial limitations
that the Apple "optimization" imposes on app portability across devices.

With the Apple "optimization", portability is essentially destroyed.

That's really my worry with this new Android "optimization".
Is the fantastic APK portability suddenly destroyed by this AAB format?

I don't know.
Do you?

VanguardLH wrote on 30.06.2021 23:49

> I'm surprised the dev tools for Android projects don't already have
> their own optimization settings.

At this point in my knowledge of "optimization", all I know is it severely
limits the portability of apps in the Apple walled-garden world.

The problem with the Apple "optimization" is that it's impossible to get
back the portability that Apple removes from each & every app download.

If the Android "optimization" is a similar concept to the Apple
"optimization", there's nothing of value gained for the user.

And a lot of value lost.

What value I'm hoping is NOT lost in the Android world is the ability to use
that same downloaded app bundle on _all_ my Android systems whenever I want.

If you find out anything about this "optimization" which impacts that
fantastic portability, please let us know as that's the value I love.

It would be horrid if Android "optimization" means "lack of portability"
(which is what Apple's "optimization" means for the Apple iOS platform).

VanguardLH wrote on 01.07.2021 01:02
>> How old are you?
>> When are you going to grow up?
>
> Don't argue with children. Tune them out.

I should.
I really should.

The problem is that I'm a purposefully helpful person, as are you.
And as are many others on the Android newsgroups (far fewer on Apple ngs).

The shockingly unprepossessing Apple apologists are the anathema of adults.

This set of about a dozen apologists are deceitful unprepossessing souls.
Alan Baker, Chris, Haemactylus, Joerg Lorenz, Jolly Roger,
Lewis, nospam, Rod Speed, Wade Garrett, Your Name, et al.

What bothers me now is how much they _still_ fabricate their brazen lies
whenever any innocent person asks a question about any functionality.

Why must they lie?
--
Alan Baker, Chris, Haemactylus, Joerg Lorenz, Jolly Roger,
Lewis, nospam, Rod Speed, Wade Garrett, Your Name, et al.

paul wrote:

> That's really my worry with this new Android "optimization".
> Is the fantastic APK portability suddenly destroyed by this AAB format?

No idea, I remember when rooting phones was "necessary" to do some of
the things I wanted to do, and odexing/deodexing APKs was a thing to
trade between speed and size ... now I don't worry about either.

Frank Slootweg wrote on 01.07.2021 16:06
> "Google Play uses your app bundle to generate and serve optimized APKs
> for each device configuration, so only the code and resources that are
> needed for a specific device are downloaded to run your app. You no
> longer have to build, sign, and manage multiple APKs to optimize
> support for different devices, and users get smaller, more-optimized
> downloads."

Hi Frank,
Thanks for digging that information up about how this new AAB format
sucks for portability (much like how IPAs suck for iOS app portability).

> This paragraph seems to imply that an APK from one device
> ("configuration") can not neccessarily be installed on an other device
> ("configuration"), even if the Android versions are the same/compatible.
> If so, this is a change from the past and makes APKs, especially those
> on APK 'archive' (web)sites, less useful/flexible.

If this destroys app portability - it's a very bad direction for Android.

Given AABs save almost nothing in terms of size ("up to" 15%, which means
it's perhaps going to be from 0% to 5% perhaps - but time will tell).

*For almost no size gain, we may entirely lose our beloved portability!*

> For example, I've moved (save, copy, install) APKs from a Huawei phone
> with Android 5 to a Samsung phone with Android 10.

Yup. I've moved APKs from a Samsung S3 to a series of Nexus and Motorola
phones to LG and then back to Motorola and now to a handful of Samsungs.

The _same_ APK has been installed on something like ten or so devices!
This allows me to maintain common functionality across many devices.

Better yet, for the half dozen apps which went rogue, I _still_ have their
original fantastic functionality even as those apps no longer even exist.

> The old-style APK
> might have included code for multiple "device configuration"s - i.e.
> Huawei and Samsung in the example -, but the new-style APK might include
> only code for one configuration (Huawei) and fail to install/work on the
> other (Samsung). (Yes Huawei and Samsung are brands, not
> "configurations", but you (hopefully) get my point.)

I agree with you.

I don't see _any_ value in the "up to" puny size differences to the user.
I wonder _why_ Google is promulgating such a move to lessen app portability?

>
> I hope that I'm reading this wrong, but I'm afraid I'm not.

I don't think any of us are reading it incorrectly, as this move to reduce
the portability of the APK will _lessen_ our abilities to port apps.

However... let's hope the MARKET will spring up to our defense by providing
what Google seems to be deprecating, which is app portability across brands.

>
> Summary: I think "optimized APKs" come at a price. What *is* that
> price?

Notice the "up to" figure of size saving is an utterly puny 15% (at most).
Of course we will need to learn more about these (potentially horrid) AAB's.

But what I see, initially (until we have more data anyway) is...
1. Apple's IPA "optimization" _destroys_ any hope of app portability.
2. Let's hope Google's AAB "optimization" doesn't have the same effect.

For what?
For a puny 0% to 5% (on average?) saving in initial package size?
If that?

There must be _some_ better reasons why Google is forcing AABs upon us.

Andy Burns wrote on 01.07.2021 17:07
>> That's really my worry with this new Android "optimization".
>> Is the fantastic APK portability suddenly destroyed by this AAB format?
>
> No idea, I remember when rooting phones was "necessary" to do some of
> the things I wanted to do, and odexing/deodexing APKs was a thing to
> trade between speed and size ... now I don't worry about either.

Let's all keep our eyes and ears open to facts about _why_ Google is so keen
on forcing this AAB format into the Google Play app store.

I, for one, never use the Google Play client (as it requires a google
account), so I use, instead, the FOSS Aurora Google Play client instead.

The beauty of the Android ecosystem is that it's hard for Google to prevent
the MARKET from delivering the functionality that the people want & need.

I, for one, like Frank, have ported scores of some of the best APKs from
Android 4.4 phones (Galaxy S3) to Nexus & Moto G phones, then to a handful
of LG Stylo 3 Plus phones on Android 7 & then to Moto G7 phones on Android 9
and 10 and those very same APKs were installed on my Android 11 Samsungs.

Bearing in mind I have plenty of iOS devices where that portability is
literally _impossible on iOS_ due to Apple's highly marketed "optimization",
let's hope Google isn't (yet again) copying a horrid page from Apple
MARKETING's playbook.

If anyone figures out what benefit (if any) this new AAB format provides to
the _user_, please let us know because the losses appear to be disastrous.
--
On the Android newsgroup adults discuss topics of technical interest.

In article <sbkmhi$d42$1@gioia.aioe.org>, paul <nospam@nospam.invalid>
wrote:

> Bearing in mind I have plenty of iOS devices where that portability is
> literally _impossible on iOS_ due to Apple's highly marketed "optimization",
> let's hope Google isn't (yet again) copying a horrid page from Apple
> MARKETING's playbook.

it's only impossible for *you*.

what you claim is impossible is very easy for others to do.

> If anyone figures out what benefit (if any) this new AAB format provides to
> the _user_, please let us know because the losses appear to be disastrous.

no, and they aren't.

also, if it means you can't pirate as much, then it's a good thing.

nospam wrote on 01.07.2021 17:42
> it's only impossible for *you*.

You apologists incessantly fabricate imaginary iOS functionality
and yet you've _never_ provided the method to do what you fabricate.

> what you claim is impossible is very easy for others to do.

And yet, never have you _ever_ come up with your fabricated functionality.
What irks me about you apologists is you're deceitful liars.

Apologists literally _hate_ that iOS can't do what Android easily does.
So you brazenly fabricate functionality which even you know doesn't exist.

>> If anyone figures out what benefit (if any) this new AAB format provides to
>> the _user_, please let us know because the losses appear to be disastrous.
>
> no, and they aren't.

A potential gain of almost nothing for a potential loss of portability is,
to you, normal (since you love the Apple walled garden concept).

But for Android users, we _love_ the portability of APKs over Android
versions, Android devices, and even Android OEM platforms.

The hope is that Google does _not_ follow Apple's horrid "optimization"
model because there is the disastrous loss of IPA portability as a result.

> also, if it means you can't pirate as much, then it's a good thing.

It's interesting that apologists consider APK portability "pirating".
Like Senator McCarthy, apologists own no shame in excusing Apple's flaws.
--
Apologists own no shame in creating excuses for iOS lack of functionality.
Alan Baker, Chris, Haemactylus, Joerg Lorenz, Jolly Roger,
Lewis, nospam, Rod Speed, Wade Garrett, Your Name, et al.

In article <sbkoi0$1d72$1@gioia.aioe.org>, paul <nospam@nospam.invalid>
wrote:

>
> > what you claim is impossible is very easy for others to do.
>
> And yet, never have you _ever_ come up with your fabricated functionality.

wrong. many people have explained it and quite a bit more to you many
times, which you fail to understand and ignore.

i remember when you were told to get a specific app, which you failed
to do. what you found was a *different* app with a similar (but not the
same) name and went off on one of your ignorant rants.

> What irks others about me is I'm a deceitful liar.

ftfy

In comp.mobile.android, paul <nospam@nospam.invalid> wrote:

You posted with headers:

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

And then included non-7bit characters. First was the U+2212 "minus sign"
at the end of this line:

> developers who want their apps to appear in other distribution channels −

That's not even the _right_ Unicode character for that context, which
would be U+2014 "em dash".

Fix your set-up.

> But who cares about the puny APK/AAB app sizes anyway?
>
> The most AABs save, according to the article, is 15% (but APKs are small to
> start with). So who cares about saving "up to" 15% on APK app sizes?

Someone, eg Google, using their bandwidth to send millions of them to
other people?

Seems to match Google's recent push for new video formats for youtube.

Elijah
------
not too thrilled with the direction of Google's "guiding hand" on Android

Eli the Bearded wrote on 01.07.2021 18:31
>> The most AABs save, according to the article, is 15% (but APKs are small to
>> start with). So who cares about saving "up to" 15% on APK app sizes?
>
> Someone, eg Google, using their bandwidth to send millions of them to
> other people?

This is logical, and probably correct.

I don't disagree that Google saving even a puny percent might care, but for
the users, saving on what is already a puny size from nothing to barely
anything isn't worth the price (IMHO) of the potentially almost complete and
total loss of portability (if that's indeed what the AAB tradeoff becomes).

I'm hopeful the MARKET will overcome any loss of portability though.
But I don't know enough about the limitations of this AAB format yet.

That's what this thread is for.

> Seems to match Google's recent push for new video formats for youtube.

I am not aware of a new youtube video format, but, like Google Play, I use a
non-Google client for full functionality WITHOUT using any Google apps.

The best non-Google Google Play client, for example, is, IMHO, Aurora:
https://forum.xda-developers.com/t/app-4-4-aurora-store-open-source-play-store-client-april-8-2021.3739733/

And the best non-Google YouTUbe client, bar none, is, IMHO, NewPipe:
https://newpipe.net/

Do you have a link that describes this new youtube video format?
Googling, this is the list of supported video formats, I think.
https://support.google.com/youtube/troubleshooter/2888402?hl=en
https://support.google.com/youtube/answer/4603579?hl=en

Which of those is "new" that you're speaking about?

nospam wrote on 01.07.2021 12:25
> ftfy

Apologists turn into instant kindergarten cesspool when dealing with facts.

In comp.mobile.android, paul <nospam@nospam.invalid> wrote:
> I'm hopeful the MARKET will overcome any loss of portability though.
> But I don't know enough about the limitations of this AAB format yet.
>
> That's what this thread is for.

The "MARKET" doesn't understand the difference. Developers and a small
percent of power users do, and likely a smaller percent of both care.

> Do you have a link that describes this new youtube video format?
> Googling, this is the list of supported video formats, I think.
> https://support.google.com/youtube/troubleshooter/2888402?hl=en
> https://support.google.com/youtube/answer/4603579?hl=en
>
> Which of those is "new" that you're speaking about?

AV1. See the news about the Youtube / Roku standoff. Google is (was? I
haven't kept up[*]) trying to force Roku to support the AV1 codec on all
devices in order to have Youtube apps. Roku is balking on including this
in current low-end devices because the chips are still a bit pricy.

This is an issue for sub $100 video players, not likely an issue for
higher power devices like desktops and reasonably powered cellphones /
tablets.

Article from a few months ago:

https://arstechnica.com/gadgets/2021/04/roku-vs-google-part-2-the-youtube-tv-app-gets-pulled-from-the-roku-store/

Elijah
------
[*] would look at articles if encountered, but isn't seeking them

Eli the Bearded wrote on 01.07.2021 19:16
> The "MARKET" doesn't understand the difference. Developers and a small
> percent of power users do, and likely a smaller percent of both care.

The "MARKET" is whomever it is that provides the functionality.

For example, Google YouTube is, to me, an obnoxious assault by ads.
Luckily, "the MARKET" provided NewPipe, which eliminates those ads.

Likewise, Google Play is, to me, a brain dead search engine (IMHO).
Luckily, "the MARKET" provided the Aurora Store, which has great filters.

Setting to _not_ delete the downloaded APK (automatic saving of all APKs!):
<https://i.postimg.cc/zf8ybgYB/apk01.jpg>

Intelligent filters to eliminate undesired features in apps found by search:
<https://i.postimg.cc/vTdMwgnW/apk02.jpg>

Persistent filters (with power to filter out entire unwanted categories):
<https://i.postimg.cc/VvF024NZ/apk03.jpg>

Almost every app by Google has a _better_ (IMHO) non-Google replacement.

My point is that Google didn't provide that better replacement app.
The market did.

My hope is that, if this new AAB format sucks for portability, then my hope
is the market will re-instate that portability, as it did in examples above.

>> Do you have a link that describes this new youtube video format?
>> Googling, this is the list of supported video formats, I think.
>> https://support.google.com/youtube/troubleshooter/2888402?hl=en
>> https://support.google.com/youtube/answer/4603579?hl=en
>>
>> Which of those is "new" that you're speaking about?
>
> AV1. See the news about the Youtube / Roku standoff. Google is (was? I
> haven't kept up[*]) trying to force Roku to support the AV1 codec on all
> devices in order to have Youtube apps. Roku is balking on including this
> in current low-end devices because the chips are still a bit pricy.
>
> This is an issue for sub $100 video players, not likely an issue for
> higher power devices like desktops and reasonably powered cellphones /
> tablets.
>
> Article from a few months ago:
> https://arstechnica.com/gadgets/2021/04/roku-vs-google-part-2-the-youtube-tv-app-gets-pulled-from-the-roku-store/

Thanks for helping us zoom in on the one format in question, AV1.
More specifically the "AV1 video codec" according to that article.

Given I had never heard of the AV1 format until today, I'll follow your lead
and _read_ the article you so kindly provided to save me the effort of
finding it.

Apparently Roku asked Google to not manipulate search results, to not
require priority data access, to not require unusual hardware costs, and to
not to discriminate against Roku and its customers.

As can be expected, Google denied those claims, so let's stay out of that
legal dispute to concentrate on whatever it is that this AV1 codec is.
"AV1 is the successor to Google's VP8 and VP9 video codecs"
"AVI's bandwidth-saving potential and royalty-free license have earned
it backing from nearly every big video and hardware company"
"AV1 requires hardware decode support for playback on slower devices
like streaming sticks, set-top boxes, and phones"

The article then goes on to say that (understandably) Google cares greatly
about bandwidth requirements, saying "anything that results in Google
sending less data to play a video can save the company tons of cash."

Other articles confirm the three things we know about AV1.
https://www.androidauthority.com/av1-codec-1113318/
1. It's a royalty free & open source lossy compression codec
2. It's 30% better compression than H.265 (for 4K UHD video)
3. The (encoding) hardware isn't yet ready for the masses

But as a user, I care more about _decoding_ and not encoding, don't I?

So this begs the question which phones support AV1 codec decoding.
https://www.smartprix.com/bytes/phones-that-support-av1-codec/

As of March 15th of this year, that article claims these support AV1.
"Mediatek confirms that AV1 Youtube streaming will be enabled for
MediaTek Dimensity 1000 and Dimensity 1000+ phones.
Samsung�s Exynos 2100 is the second chipset to support AV1 codec.
1. Samsung Galaxy S21 series (Exynos 2100 variants)
2. iQOO Z1 5G
3. Reno5 Pro
4. Realme X7 Pro
Eventually, all of our phones will most probably have hardware support
for AV1 codec."

Of course, googling also found inconsistent results, such as this:
Samsung, Qualcomm and Huawei Back EVC as an alternative to AV1
https://www.smartprix.com/bytes/phones-with-evc-hardware-support/

So maybe we need a separate thread on what's the status of AV1 anyway.
--
Adults discuss topics of interest by sharing ideas and data together.