[DonHB]

I don't think OM should spend a dime on maintaining / developing the BB suite of apps.

An alternative I suggested was to only create an app store (or use a pre-made one) and alternative UX. Let customers buy the apps they want on their phone. Obviously, this would be part of the device setup. This means that developers can compete in apps that Google includes with Android, but no longer updates or provides with AOSP. They can even compete something as fundimental as dialer or the option of a VKB. BlackBerry could provide Cylance technology to evaluate apps submitted to the store.

This means that, with success, OM (and any partners) can go in a separate direction than AOSP. The interesting problem is how to maintain a minimum level of software compatibility with mainline Android to keep developers on board and have differentiation from the usual Android devices. The idea is to make the app store also loadable onto Android (TM'd) devices and ultimately provide a more appealing license to developers that sell on the store. The inclusion of the Hub (or some alternative UX) and accompanying UI can be the only change to the AOSP to start.

Isn't AOSP still at Pie?

[conite]

An alternative I suggested was to only create an app store (or use a pre-made one) and alternative UX. Let customers buy the apps they want on their phone. Obviously, this would be part of the device setup. This means that developers can compete in apps that Google includes with Android, but no longer updates or provides with AOSP. They can even compete something as fundimental as dialer or the option of a VKB. BlackBerry could provide Cylance technology to evaluate apps submitted to the store.

This means that, with success, OM (and any partners) can go in a separate direction than AOSP. The interesting problem is how to maintain a minimum level of software compatibility with mainline Android to keep developers on board and have differentiation from the usual Android devices. The idea is to make the app store also loadable onto Android (TM'd) devices and ultimately provide a more appealing license to developers that sell on the store. The inclusion of the Hub (or some alternative UX) and accompanying UI can be the only change to the AOSP to start.

Isn't AOSP still at Pie?

You need to at least slightly consider actual economics, logistics, or common business practices.

Now you want BlackBerry to fire back up and get back in the game to produce an app store and a new UX for Android - all for a small startup with little cash?

And what about Google? Give up a relationship BlackBerry depends on for UEM to satisfy OM and the handful of its potential customers?

Incidentally AOSP is always a step ahead of Google (since it's the base). It is at Android 11. Well, it's actually at 12, but that's behind closed doors until next month or so.

[manny2]

Nor have we seen any indication that Onward Mobility has the capability (resources) of either outsourcing or developing their own apps or UX.

Not to mention that there don't seem to be any principals in the company with any development experience at all.

Have no idea how feasible it is but could it be possible that the few keyboard phones active combine their software devs and come out with one version of android to lower costs and give us more features. Im thinking of the fx tec phone mainly, the titan team looks too small. (But results are results). We would have alot of form factors catered, passport, landscape and candy or silder.
Another possibility is for these groups to go open source on the pkb software. This android version of course will use google services.
I know there seems to many i.t people who use their phones to run scripts and pc maintenance and such. This community could number in the thousands, many would have coding skills, if support is given then we could have a force that could achieve something.

[conite]

Have no idea how feasible it is but could it be possible that the few keyboard phones active combine their software devs and come out with one version of android to lower costs and give us more features. Im thinking of the fx tec phone mainly, the titan team looks too small. (But results are results). We would have alot of form factors catered, passport, landscape and candy or silder.
Another possibility is for these groups to go open source on the pkb software. This android version of course will use google services.
I know there seems to many i.t people who use their phones to run scripts and pc maintenance and such. This community could number in the thousands, many would have coding skills, if support is given then we could have a force that could achieve something.

No and no.

[Dunt Dunt Dunt]

Have no idea how feasible it is but could it be possible that the few keyboard phones active combine their software devs and come out with one version of android to lower costs and give us more features. Im thinking of the fx tec phone mainly, the titan team looks too small. (But results are results). We would have alot of form factors catered, passport, landscape and candy or silder.
Another possibility is for these groups to go open source on the pkb software. This android version of course will use google services.
I know there seems to many i.t people who use their phones to run scripts and pc maintenance and such. This community could number in the thousands, many would have coding skills, if support is given then we could have a force that could achieve something.

CrackBerry had problems getting enough people to help with the CrackBerry BB10 App.... sorry but I don't think the community can provide the amount of work that would be needed for this.

But then I'm not sure you really need much in the way of software development anyway... Android supports PKB phones. Now more advance features like shortcuts and swiping would need so custom software support.

But in the end... high cost are the result of low volume devices using very custom components. PKB is well past the point were any level of volume discounts can be applied to their manufacturing. Any OEM wanting to offer a product, is going to stick to one form factor at a time. Maybe every 12- 24 months they could offer something different.

But I'm much more impressed with Unihertz than with Planet Computer or F(x)tec... time will tell how OM ranks.

[DonHB]

You need to at least slightly consider actual economics, logistics, or common business practices.

Now you want BlackBerry to fire back up and get back in the game to produce an app store and a new UX for Android - all for a small startup with little cash?

And what about Google? Give up a relationship BlackBerry depends on for UEM to satisfy OM and the handful of its potential customers?

Incidentally AOSP is always a step ahead of Google (since it's the base). It is at Android 11. Well, it's actually at 12, but that's behind closed doors until next month or so.

Most of this is already built, which is the point.

License it all to OM in a manner similar to how Google licensee GSF with an API. Let OM decide whether to subcontract continued development and be responsible for the Suite on Play. Presumably, what BlackBerry has developed does not rely on GSF. So, it should operate well for a platform based on AOSP. Without the need to pass Android CTS, the Hub can more easily match the features and functionality of the Hub on BB10.

AOSP is generally behind what is available on Android (TM'd) devices. So, there is an opportunity to pursue alternative UXes and features on Android (i.e collaborative embrace and extend, but maintain sufficient source code compatibility with differentiated platforms*). OM could approach some of the other AOSP players and offer them an app store for use on their platforms.


*This should be easier with a runtime rather than native code and the opportunity to modify the Android CTS.

[conite]

It is generally behind what is available on Android (TM'd) devices. Most of this is already built, which is the point. License it all to OM in a manner similar to how Google licensee GSF with an API. Let OM decide whether to subcontract continued development and be responsible for the Suite on Play.

Presumably, what BlackBerry has developed does not rely on GSF. So, it should operate well for a platform based on AOSP. Without the need to pass Android CTS, the Hub can more easily match the features and functionality of the Hub on BB10.

I doubt OM would want it for free, let alone have to pay for it.

And what is the HUB on Android anyway? It's just (an outdated) email client, that also copies notifications from the tray.

[Dunt Dunt Dunt]

Most of this is already built, which is the point.

License it all to OM in a manner similar to how Google licensee GSF with an API. Let OM decide whether to subcontract continued development and be responsible for the Suite on Play. Presumably, what BlackBerry has developed does not rely on GSF. So, it should operate well for a platform based on AOSP. Without the need to pass Android CTS, the Hub can more easily match the features and functionality of the Hub on BB10.

AOSP is generally behind what is available on Android (TM'd) devices. So, there is an opportunity to pursue alternative UXes and features on Android (i.e collaborative embrace and extend, but maintain sufficient source code compatibility with differentiated platforms*). OM could approach some of the other AOSP players and offer them an app store for use on their platforms.


*This should be easier with a runtime rather than native code and the opportunity to modify the Android CTS.

You go from "most is already built" to an "alternative UXes and features on Android".

Sorry but your talking about a huge investment in time and money...

And still haven't given developers any more reason to support this than they would any of the other attempts at this. Be much smarter to support LineageOS, PureOS, GrapheneOS, or even Sailfish.

[RLeeSimon]

been that way...

[DonHB]

You go from "most is already built" to an "alternative UXes and features on Android".

Sorry but your talking about a huge investment in time and money...

And still haven't given developers any more reason to support this than they would any of the other attempts at this. Be much smarter to support LineageOS, PureOS, GrapheneOS, or even Sailfish.

Do any of these have an app store or is there even an alternative app store where developers can SELL there wares?

The idea is to FORK Android with AOSP as the starting point. The focus, to begin with, should be on the runtime and a free use API that replaces GSF. The goal is to provide a more open solution that allows for more differentiation and better licensing than what Google offers. It could ultimately allow third parties to develop tools to produce native code apps.

OM is likely not the entity to do this nor is BlackBerry, but could, among others, establish such an entity. However, with issues of antitrust it is possible that any company would have a case, if Google attempts to interfere with such an entity's progress. BlackBerry could provide the technology to evaluate app submissions to app stores using Cylance tech that is similar to tools already provided to enterprises for software assurance and risk assessment.

Idea is to consider the software separately from the device. Going this route would make delivery of a device in 2021 highly unlikely. As the companies you have mentioned have shown, without a unified software front success is likely impossible.

Think what AMD did with x64.

[conite]

Do any of these have an app store or is there even an alternative app store where developers can SELL there wares?

The idea is to FORK Android with AOSP as the starting point. The focus, to begin with, should be on the runtime and a free use API that replaces GSF. The goal is to provide a more open solution that allows for more differentiation and better licensing than what Google offers. It could ultimately allow third parties to develop tools to produce native code apps.

OM is likely not the entity to do this nor is BlackBerry, but could, among others, establish such an entity. However, with issues of antitrust it is possible that any company would have a case, if Google attempts to interfere with such an entity's progress. BlackBerry could provide the technology to evaluate app submissions to app stores using Cylance tech that is similar to tools already provided to enterprises for software assurance and risk assessment.

Idea is to consider the software separately from the device. Going this route would make delivery of a device in 2021 highly unlikely. As the companies you have mentioned have shown, without a unified software front success is likely impossible.

Think what AMD did with x64.

You haven't said why even a single developer would want to have anything to do with this.

Said developer can ALREADY reach 99.99% of the world's market.

[DonHB]

You haven't said why even a single developer would want to have anything to do with this.

Said developer can ALREADY reach 99.99% of the world's market.

Better licensing terms. More open platform. Input into direction of platform. Possibility of support beyond runtime (e.g. native code apps).

[conite]

Better licensing terms. More open platform. Input into direction of platform. Possibility of support beyond runtime (e.g. native code apps).

Input into the direction of AOSP?!

[Dunt Dunt Dunt]

Better licensing terms. More open platform. Input into direction of platform. Possibility of support beyond runtime (e.g. native code apps).

Will say that one of the rumored features coming to Android 13 is better support for other Android Stores.....

I suspect that's because the vast majority of malware hits Android from those stores, so making Android better able to scan Apps from these sources will be helpful.

[DonHB]

Input into the direction of AOSP?!

Idea is to FORK AOSP and create an alternative. It should be possible to install store and libraries on existing Android (TM'd) devices. Create an alternative to Play and Amazon App Store with apps based on the new APIes.

It will also easier to build a runtime and app store than to fully fork the AOSP. This route will allow time to bring developers on board before a forked AOSP and unencumbered devices become available. Similar to what BlueStacks have done for Windows and macOS, but with the intention of ultimately bringing the devices to market.

It shouldn't be compromised to support the above mentioned OSes (i.e. Sailfish). It should fork the most appropriate version of AOSP

[conite]

Idea is to FORK AOSP and create an alternative. It should be possible to install store and libraries on existing Android (TM'd) devices. Create an alternative to Play and Amazon and hopefully unencumbered devices will follow.

Fork AOSP how? To what end?

You want to head down a proprietary route and lose all of the benefits of an open-source project?

[Chuck Finley69]

Fork AOSP how? To what end?

You want to head down a proprietary route and lose all of the benefits of an open-source project?

To make it like BB10, duh ?!?

[DonHB]

Fork AOSP how? To what end?

You want to head down a proprietary route and lose all of the benefits of an open-source project?

An alternative open source project that fills in the pieces that exist on Android/GSF but not in AOSP. It should answer how much can be made proprietary and still have sufficient source code compatibility to provide developers additional RoI on their existing source.

[conite]

An alternative open source project that fills in the pieces that exist on Android/GSF but not in AOSP. It should answer how much can be made proprietary and still have sufficient source code compatibility to provide developers additional RoI on their existing source.

What pieces specifically?

If you're thinking added security features, then OM would be much wiser to simply contribute to the GrapheneOS project than start from scratch.

[bakkenstrong]

Hello software fans,
I have reread all that's available on the software front and to be sure, there is not a lot of threads to grasp at!
Currently I have flashed a pixel 2 with e foundation rom. It is a totally degoogled rom. You can get by using non google apps and I'm getting used to it.
However, not sure how fit it is for Enterprise situations. Only reason I bring it up is many here, and on other forums seem to think it will be some fork of android. I suppose time will tell but perhaps holding ones breath for a spectacular version of androids latest may cause drowsiness and or unconsciousness.
Hopefull were in for a breath of fresh air.......

[DonHB]

What pieces specifically?

If you're thinking added security features, then OM would be much wiser to simply contribute to the GrapheneOS project than start from scratch.

The project could manifest the Apache license using the runtime from AOSP as a starting point. The project doesn't need an OS to begin with. An app store running on existing Android devices could provide a proof of concept for the APIes. Ultimately, once this is in the wild only useful stuff should be adopted from AOSP going forward. But it should be collaborative enough so forks do not proliferate, but still allow device makers to differentiate.

[Dunt Dunt Dunt]

Hello software fans,
I have reread all that's available on the software front and to be sure, there is not a lot of threads to grasp at!
Currently I have flashed a pixel 2 with e foundation rom. It is a totally degoogled rom. You can get by using non google apps and I'm getting used to it.
However, not sure how fit it is for Enterprise situations. Only reason I bring it up is many here, and on other forums seem to think it will be some fork of android. I suppose time will tell but perhaps holding ones breath for a spectacular version of androids latest may cause drowsiness and or unconsciousness.
Hopefull were in for a breath of fresh air.......

Yeah what can be done, and what Enterprise or Developer are going to support.... are miles apart.

OM is a tiny little group that's asking for money to support their efforts, sorry but there is no software genus behind them. I just don't see them reinventing the wheel.... and then offering it on a PKB phone.

[conite]

The project could manifest the Apache license using the runtime from AOSP as a starting point. The project doesn't need an OS to begin with. An app store running on existing Android devices could provide a proof of concept for the APIes. Ultimately, once this is in the wild only useful stuff should be adopted from AOSP going forward.

I'm asking what you think is missing in AOSP, LineageOS, or GrapheneOS. Forget your appstore for a moment.

And why would it be worth giving up on NIAP and countless other security certifications that Google and Samsung devices (running Google Android) have in the first place?

How would you expect OM to win any government or enterprise orders without any such credentials?

[DonHB]

I'm asking what you think is missing in AOSP, LineageOS, or GrapheneOS. Forget your appstore for a moment.

With each version of AOSP more of the expected included apps become unsupported. I am suggesting instead of investing to replace them to allow device owners to select third party apps, but I don't know if the data files (i.e. contact database) are expected to already exist. This can be accommodated in the replacement API. The setup procedure should bring device owners to an app store to select what apps are needed. The procedure can advise the owner of what generally expected apps are missing from the owner's device. If the owner has no interest in using cellular voice, having a dialer on the device can be skipped, but it can always be added later.

How would you expect OM to win any government or enterprise orders without any such credentials?

As I wrote this is about producing an app store that forgoes GSF for alternative APIes.

And why would it be worth giving up on NIAP and countless other security certifications that Google and Samsung devices (running Google Android) have in the first place?

Once a market is established for GSF free apps AOSP can be used to produce a distribution with the appropriate certifications. This investment would be directed to integrating the runtime (ART and libraries based on the APIes) with the OS used in the chosen version of AOSP. Presumably, the expected apps that are usually included with a device would already exist for sale in the app store.

The point is to establish a market for this alternative API with less restrictive requirements (perhaps with a modified Android CTS) which rethinks the UX requirements. It is possible, as part of what ART does when it installs software, can evaluate the resources incorporated with the app and modify the appropriate aspects of the app. This should be part of the design not an afterthought.

OM could start with a Google device and see what kind of anticompetitive arguments they can have if Google objects to another store on its GSF licensed device. Maybe, by the time the suit it resolved, it can intentionally drop its GSF license and have certifications for the AOSP based replacement by then. Maybe, further, the suit would be effective publicity for the company.

[conite]

With each version of AOSP more of the expected included apps become unsupported. I am suggesting instead of investing to replace them to allow device owners to select third party apps, but I don't know if the data files (i.e. contact database) are expected to already exist. This can be accommodated in the replacement API. The setup procedure should bring device owners to an app store to select what apps are needed. The procedure can advise the owner of what generally expected apps are missing from the owner's device. If the owner has no interest in using cellular voice, having a dialer on the device can be skipped, but it can always be added later.

OK, what?

With each version of AOSP "more of the expected included apps become unsupported"? Like what? LineageOS and others have complete suites of "expected" apps.

Besides, anyone can load F-Droid or any number of other stores.

Once a market is established for GSF free apps AOSP can be used to produce a distribution with the appropriate certifications. This investment would be directed to integrating the runtime (ART and libraries based on the APIes) with the OS used in the chosen version of AOSP. Presumably, the expected apps that are usually included with a device would already exist for sale in the app store.

Non-GMS appstores exist already for the outliers who want to use them.

No small company could ever afford to go through the multiple, lengthy, and expensive certification processes. The existing list won't change - Google, Samsung, Apple.

The point is to establish a market for this alternative API with less restrictive requirements (perhaps with a modified Android CTS) which rethinks the UX requirements. It is possible, as part of what ART does when it installs software, can evaluate the resources incorporated with the app and modify the appropriate aspects of the app. This should be part of the design not an afterthought.

OM could start with a Google device and see what kind of anticompetitive arguments they can have if Google objects to another store on its GSF licensed device. Maybe, by the time the suit it resolved, it can intentionally drop its GSF license and have certifications for the AOSP based replacement by then. Maybe, further, the suit would be effective publicity for the company.

All pure fantasy. No one wants this, and the costs are astronomical.