Database Users

Is Vulkan API coming to Zenfone 2?

I just heard that Vulkan API is coming to mobile and it is supporting PowerVR chips like the one we have on the phone.
(PowerVR G6430). Some people say on the ZENTALK forum that that's why it takes so much freaking time for Asus to implement Marshmallow as they are busy incorporating the API on the phone.
If this is true just image the gigantic boost it will give to our phones! (just watch on Youtube or search on Google for more information about Vulkan API)

If Vulkan API is implemented at our phone it would be fantastic. Hope Asus will work on the API and make the best for our phone, let's see in a couple of months of so

Too good to be true man, too good to be true.

hi, I'm very interested in everything about vulkan since i could see some videos about it. But my knowledge about api, android and rom's is not that good, so i would thank you if i could get some answers.
1 - Is this implementation of API a work for ASUS or Intel?
2 - Since i saw that PowerVR Rogue has now SDK(i dont know what it is) for Vulkan, Is ANYONE able to make a custom rom that could use Vulkan?
3 - I've heard that Android N will have native support for Vulkan. Does it mean that if i download a custom rom, like a cyanogenmod, for Android N to my Zenfone 2 i will have the benefits of using Vulkan?
4 - Does anyone know if that Galasy S7 that had 135k+ on antutu was using Vulkan? Because my Zenfone 2 is a great phone and only scores 65k, it's scary to thing that a S7 should have more than the double of hardware capacity that my Zenfone has. I thing that should be because of vulkan, but i need to hear it from someone who knows what's talking.
I hope to get answers for this questions. Thank you all.

SSJMatt said:
)Some people say on the ZENTALK forum that that's why it takes so much freaking time for Asus to implement Marshmallow as they are busy incorporating the API on the phone.
Click to expand...
Click to collapse
Sorry, that's not how ASUS usually manages fixes and updates. That would take time and money and we've already spent our money so they have nothing to gain, therefore nothing will happen. Only future customers are a priority for ASUS.
A happy ASUS customer is one with low expectations.

Well, at least It'd give Asus a good excuse for being so late...

Vulkan is something that would need to be implemented at the OS level on Android (mainly the kernel, no idea what other bits Google is including in the rest of the OS). And support for each hardware would need to be provided by the OEM or manufacturers. It MAY be possible for a custom ROM to implement Vulkan support in some fashion in a current version of Android (harder and more "impossible" things have been accomplished) but it's not likely due to too many technical challenges. Besides, it wouldn't happen until after Android N is released and the AOSP code is posted. Only then would someone attempt to backport Vulkan.
I'm not 100% sure, but I do believe that Vulkan support will be a requirement by Google for devices to run Android N. So if Asus does plan on upgrading the phones then they will need to include a kernel for the hardware that supports Vulkan and those drivers would come from Intel. So the chance of the Zenfone supporting Vulkan is 100%, provided Asus upgrades it to N.

SSJMatt said:
I just heard that Vulkan API is coming to mobile and it is supporting PowerVR chips like the one we have on the phone.
(PowerVR G6430). Some people say on the ZENTALK forum that that's why it takes so much freaking time for Asus to implement Marshmallow as they are busy incorporating the API on the phone.
If this is true just image the gigantic boost it will give to our phones! (just watch on Youtube or search on Google for more information about Vulkan API)
Click to expand...
Click to collapse
So is the VULCAN API present in the M update?

Is Vulkan something like the Mantle for Desktops?
EDIT:
Vulkan Drivers for Nexus Player
Google’s Android Image
As part of the Android N Developer Preview 2 release, Google released an Android N image for the Nexus Player that includes Vulkan drivers. You can find out more about the Android N Developer Preview here and can download the image here. As this image is officially supported by Google, we recommend using it for Vulkan Android development.
Click to expand...
Click to collapse
https://community.imgtec.com/developers/powervr/vulkan/
There is two possibilities:
1- Vulkan added in Android N's mainline code, and CM14 (maybe) will do this too.
2- Vulkan driver will be only in manufacters Android N's source. In this case, will be needed to be backported.
In both possibilites, isnt impossible to do it, even without Asus help. But would be awesome if some official MM give it to us (not in the first version, obviously).

Its GPU manufacturer job to implement vulkan, they provide the drivers to OEM manufacturer implement it on their otas. Nvidia already did that on latest MM update to shield TV and shield tablet.

[PETITION FOR NOUGAT]For Sony To Update Xperia Z2 & Z3 To Official Nougat 7.0

The Sony Xperia Z2 and Z3 devices are both amongs one of Sony's best smartphones ever that they has released. By signing this petition, we will all let Sony take action and update our precious Z2 and even Z3 devices to Android Nougat!
But what about Vulkan API support???
Anything is possible, and we will prove to Google and Sony that having the minimum requirements for software to work correctly, is plain garbage, and that Vulkan API can be left out for them, because it's not like the Vulkan API is a necessity for Nougat in order to run correctly.
ANYMORE QUESTIONS WILL BE BROUGHT UP FROM THE COMMENTS ONTO THE OP AND ANSWERED HERE.
SIGN THIS PETITION NOW!: http://bit.ly/2eEwqN5
Thanks!

I Just Want A Stable 7.0 Build For Z2

Man i think this is impossible. Qualcomm completely left the development of the SD800/801 and if Sony update our devices without permission of Google, they will be in a big trouble. To me, this is impossible.

You are totally right Little Snevil. I also think that official update it's impossible because Qualcomm processor.
Enviado do meu D6503 através de Tapatalk

Well, MAYBE it is possibile to get android 7.0 on snap 801. Just look http://www.techtimes.com/articles/1...coming-soon-geekbench-benchmark-hints-yes.htm

This is sad, but change.org never has been listed by Google or Sony, like happen with z1 and marshmallow, Xperia L and kit kat, Xperia sp and kit kat. The true is Google and Sony never listen to users, only look the sales, and for those is better for him sale the new and forget the old

what i can say in that?

@Brandon Nel
Having a petition is a good idea, and I am not against it.
But there are two questions I would like to raise before proceeding to sign the petition:
1. Our Z3 and Z2 has been released for 24 and 30 months already, this already exceed the normal aftermarket support for Android devices (usually it goes among 18 to 24 months). Although you might say there has been rule breakers recently (for instance the Xperia Z that has almost 36 months of follow up upgrade), but however there are also some far below standard devices (eg Xperia C, which has no android upgrade since release). After all, Qualcomm, Sony and any other companies still have to make money for R&D and make a living, right? So I am thinking that shouldnt we live with what we are having now (AOSP 7.0)?
2. Shouldnt Qualcomm the company you should challenge against? Vulkan and OpenGS are featured in the chipset which is manufactured by QC, not Sony!

We should petition Qualcomm & Google instead of Sony.. Sony tried their best to bring Nougat through their Beta program for Z3.
But due to the lack of chipset updates from Qualcomm and the Vulkan API requirement set by Google, so many devices have been abandoned from the update even though they are fully capable to run N. This includes Z2 & Z3.
So in this case, either Qualcomm has to release update to our chipset or we have to force Google to remove mandatory Vulkan API requirement.

i need to pls make stable nougat..........................

artsfreaky said:
i need to pls make stable nougat..........................
Click to expand...
Click to collapse
Then sign the petition and prey
Sent from my Sony D6503 using XDA Labs

Paste a link to the petition on Twitter Sony and Sony News

//This is purely an opinion, might be treated as sarcasm, but it is an opinion
1. Nougat is bad for me, it is uglier and security is even worse because of getting more strict.
2. It is nearly impossible to push this through, because now you need to actually HAVE that VulkanAPI support in order to get a cert from google to use gapps(Noone will use Vulkan straight away, because of fragmentation, but well, three billion devices run java, now three billion devices will have to run Vulkan as well and if not, they'll die)

Any effort is worthwhile haha. This should be shared in the Z3 forums!

Well, Sony published AOSP for Xperias. This might mean something, maybe they will be able to somehow get that cert.

Did you see this :
Sony is not to blame for leaving the Xperia Z3 off the Android Nougat list
http://www.xperiablog.net/2016/08/3...ng-the-xperia-z3-off-the-android-nougat-list/
All devices with SD 800/801 will not updated to Android N 7.0 , Because of Qulacomm .

Alaa | Google Android said:
Did you see this :
Sony is not to blame for leaving the Xperia Z3 off the Android Nougat list
http://www.xperiablog.net/2016/08/3...ng-the-xperia-z3-off-the-android-nougat-list/
All devices with SD 800/801 will not updated to Android N 7.0 , Because of Qulacomm .
Click to expand...
Click to collapse
Not because of Qualcomm, but because of Google. They made Vulkan obligatory for getting certs. No one is going to use it from day one of Nougat anyway, because fragmentation, they want to push APIs, but Nougat isn't like 99% of Android right now. Although it might be handy when it reaches higher shares due to Vulkan's performance.

Minimum API level for apps (dev discussion)

Hello
Asking all developers to start a discussion on what the minimum API level is that you support, and have you decided to drop support for older APIs and if so what the reasons are. The reason for starting this discussion comes from the frustrations caused by having to support older API levels. Yes it's important to support as many users as possible - not everybody has access to the latest and greatest devices / Android versions, my own day to day device is a Samsung Galaxy S6 with Android 6.0.1. Although I have access to a device with Android 7.1 and one with Lollipop. However there is only so far back you can go in terms of support before development starts to get frustrating and in the end the question has to be asked if it is really worth it.
Please first take a look at https://developer.android.com/about/dashboards/index.html for the latest device stats.
For some background, I'm the developer of this app http://forum.xda-developers.com/android/apps-games/quick-gallery-photo-editor-t3394976 and https://play.google.com/store/apps/details?id=com.mobato.gallery. Currently min API 16 is supported, but I am thinking of making this 19 (KitKat), or dropping JellyBean support all together and just supporting Lollipop onwards. I will aim to explain why.
Recently I have added SD Card support. Anybody who has implemented proper SD Card support in their apps knows how frustrating this can be, especially with the new permissions required from the user in Lollipop onwards as part of the storage access framework (this is so bad that I even made a tutorial with screenshots showing the user how to grant access the SD Card, I have seen real users get confused by the SAF permissions activity). On KitKat it is impossible to write to the SD Card unless the device is rooted. This resulted in lots of negative reviews for apps when this limitation was introduced. Prior to KitKat all that was required was the write access permission to be declared in the application manifest. As you can see there are three different scenarios to write code for and test (pre-KitKat, KitKat and Lollipop onwards) which adds to development time/costs and bug fixing can become extremely cumbersome having to do full regression tests. However KitKat is still very popular. Since I don't even own a KitKat device it's impossible to test this scenario, let alone a rooted version (emulators only go so far).
Here are some additional facts:
KitKat devices account for 24% of checkins to Google Play
The 24% of KitKat users combined with older API levels (down to API 2.2) account for a whopping 39.3% of users checking in to Google Play.
Memory management for bitmaps just isn't great prior to Lollipop (lots of OOM can occur even with careful memory management as I have seen from crash reports).
JellyBean 4.4.4 got released in October 31, 2013. That's just over 3 years ago. In the world of mobile, that's equivalent to an entire period of geology such as the Jurassic Period.
JellyBean is discontinued according to https://en.wikipedia.org/wiki/Android_version_history
Fact: most of the bad reviews for my app are coming from users with low-end devices running older versions of Android, Lollipop onwards users generally leave more favourable reviews.
So in conclusion I am thinking about dropping support for KitKat and older at some point unless anybody believes it is worth supporting still? The question is how likely are those users ever going to make in-app purchases, although from a perspective of just showing adverts it might be worth it.
Please share your experiences with your apps and contribute your ideas.

g313 said:
Hello
Asking all developers to start a discussion on what the minimum API level is that you support, and have you decided to drop support for older APIs and if so what the reasons are. The reason for starting this discussion comes from the frustrations caused by having to support older API levels. Yes it's important to support as many users as possible - not everybody has access to the latest and greatest devices / Android versions, my own day to day device is a Samsung Galaxy S6 with Android 6.0.1. Although I have access to a device with Android 7.1 and one with Lollipop. However there is only so far back you can go in terms of support before development starts to get frustrating and in the end the question has to be asked if it is really worth it.
Please first take a look at https://developer.android.com/about/dashboards/index.html for the latest device stats.
For some background, I'm the developer of this app http://forum.xda-developers.com/android/apps-games/quick-gallery-photo-editor-t3394976 and https://play.google.com/store/apps/details?id=com.mobato.gallery. Currently min API 16 is supported, but I am thinking of making this 19 (KitKat), or dropping JellyBean support all together and just supporting Lollipop onwards. I will aim to explain why.
Recently I have added SD Card support. Anybody who has implemented proper SD Card support in their apps knows how frustrating this can be, especially with the new permissions required from the user in Lollipop onwards as part of the storage access framework (this is so bad that I even made a tutorial with screenshots showing the user how to grant access the SD Card, I have seen real users get confused by the SAF permissions activity). On KitKat it is impossible to write to the SD Card unless the device is rooted. This resulted in lots of negative reviews for apps when this limitation was introduced. Prior to KitKat all that was required was the write access permission to be declared in the application manifest. As you can see there are three different scenarios to write code for and test (pre-KitKat, KitKat and Lollipop onwards) which adds to development time/costs and bug fixing can become extremely cumbersome having to do full regression tests. However KitKat is still very popular. Since I don't even own a KitKat device it's impossible to test this scenario, let alone a rooted version (emulators only go so far).
Here are some additional facts:
KitKat devices account for 24% of checkins to Google Play
The 24% of KitKat users combined with older API levels (down to API 2.2) account for a whopping 39.3% of users checking in to Google Play.
Memory management for bitmaps just isn't great prior to Lollipop (lots of OOM can occur even with careful memory management as I have seen from crash reports).
JellyBean 4.4.4 got released in October 31, 2013. That's just over 3 years ago. In the world of mobile, that's equivalent to an entire period of geology such as the Jurassic Period.
JellyBean is discontinued according to https://en.wikipedia.org/wiki/Android_version_history
Fact: most of the bad reviews for my app are coming from users with low-end devices running older versions of Android, Lollipop onwards users generally leave more favourable reviews.
So in conclusion I am thinking about dropping support for KitKat and older at some point unless anybody believes it is worth supporting still? The question is how likely are those users ever going to make in-app purchases, although from a perspective of just showing adverts it might be worth it.
Please share your experiences with your apps and contribute your ideas.
Click to expand...
Click to collapse
You're right about bitmap memory management (I had an infinite System UI FC on CM 11 when I got too many notifications (from YouTube, by the way)
Sent from my GT-S7580 using Tapatalk

i want to run marshmallow apps on jellybean 4.1.2
g313 said:
Hello
Asking all developers to start a discussion on what the minimum API level is that you support, and have you decided to drop support for older APIs and if so what the reasons are. The reason for starting this discussion comes from the frustrations caused by having to support older API levels. Yes it's important to support as many users as possible - not everybody has access to the latest and greatest devices / Android versions, my own day to day device is a Samsung Galaxy S6 with Android 6.0.1. Although I have access to a device with Android 7.1 and one with Lollipop. However there is only so far back you can go in terms of support before development starts to get frustrating and in the end the question has to be asked if it is really worth it.
Please first take a look at https://developer.android.com/about/dashboards/index.html for the latest device stats.
For some background, I'm the developer of this app http://forum.xda-developers.com/android/apps-games/quick-gallery-photo-editor-t3394976 and https://play.google.com/store/apps/details?id=com.mobato.gallery. Currently min API 16 is supported, but I am thinking of making this 19 (KitKat), or dropping JellyBean support all together and just supporting Lollipop onwards. I will aim to explain why.
Recently I have added SD Card support. Anybody who has implemented proper SD Card support in their apps knows how frustrating this can be, especially with the new permissions required from the user in Lollipop onwards as part of the storage access framework (this is so bad that I even made a tutorial with screenshots showing the user how to grant access the SD Card, I have seen real users get confused by the SAF permissions activity). On KitKat it is impossible to write to the SD Card unless the device is rooted. This resulted in lots of negative reviews for apps when this limitation was introduced. Prior to KitKat all that was required was the write access permission to be declared in the application manifest. As you can see there are three different scenarios to write code for and test (pre-KitKat, KitKat and Lollipop onwards) which adds to development time/costs and bug fixing can become extremely cumbersome having to do full regression tests. However KitKat is still very popular. Since I don't even own a KitKat device it's impossible to test this scenario, let alone a rooted version (emulators only go so far).
Here are some additional facts:
KitKat devices account for 24% of checkins to Google Play
The 24% of KitKat users combined with older API levels (down to API 2.2) account for a whopping 39.3% of users checking in to Google Play.
Memory management for bitmaps just isn't great prior to Lollipop (lots of OOM can occur even with careful memory management as I have seen from crash reports).
JellyBean 4.4.4 got released in October 31, 2013. That's just over 3 years ago. In the world of mobile, that's equivalent to an entire period of geology such as the Jurassic Period.
JellyBean is discontinued according to https://en.wikipedia.org/wiki/Android_version_history
Fact: most of the bad reviews for my app are coming from users with low-end devices running older versions of Android, Lollipop onwards users generally leave more favourable reviews.
So in conclusion I am thinking about dropping support for KitKat and older at some point unless anybody believes it is worth supporting still? The question is how likely are those users ever going to make in-app purchases, although from a perspective of just showing adverts it might be worth it.
Please share your experiences with your apps and contribute your ideas.
Click to expand...
Click to collapse
i want to run marshmallow apps on jellybean 4.1.2 by decompiling particular app and editing its manifest.xml then change the minsdkversion to 16. is it possible? i tried it by decompling the file but i havent found any minsdkversion in manifest file after decompiling the apk.i downloaded an app called solid explorer and there is an option in it to open the apk file but that apk is not decompiled.so i took compiled apk ,i opened compiled apk file and then to manifest file after opening it i can see the minsdk version and other platform versions remember that was compiled apk file.
please tell me how to do this.

will project treble successed

As seen here
https://www.reddit.com/r/LineageOS/...ect_trebel_devices/?utm_source=reddit-android
LineageOS team state that project treble is in its baby shoes and completely dependant on google to optimize it even more since as of now gsi rom requires certain adjustments for each device, so will project treble successed?
any1 has an insight please share.

I think it needs more adjustment. The kernel should be universal and updateable along with the OS, it's pretty universal as it is at the moment. Drivers should also be standard and updateable, at least for standard items. There should be a driver model where possible to support other devices, and any phone specific changes could be done through manufacturer supplied drivers. There's really no reason why it can't be done, it would be along the lines of how Windows works. Of course, it can be tailored to suit phones.
System updates should realistically come from Google, it would mean all phones and devices would be up to date with the latest security updates. The phone can also check with the manufacturer for specific updates. If Google keeps them apprised of any changes they can update their specific updates in time. This model would mean individual service testing for a new OS update etc wouldn't be a problem since it should at least be compliant with the base model.
Don't forget Google tracks down security leaks in other OS like Windows, which isn't even a direct competitor, and releases the security leak information if it isn't patched within 30? days. How many Android devices are updated with security patches within 30 days by the manufacturer? It's very much a double standard. Google really needs to think of an even more universal model like I just depicted for Android 10 Quinoa Slice (or whatever they call it).
Will Treble succeed? It's a step in the right direction, but needs more work. Not only should something like I just described be done, it should be made mandatory for all new devices. It doesn't mean custom versions are out, but custom versions would have to have OTA updates and be updated quickly along with the standard OS.

To say whether it succeeded or not, I think you'd first need to define what's its goal.
I still don't even know the answer as of today.
Some people say that the goal is to have a system image controlled and updated by Google.
But I don't see this happening any time soon. Google would need to test their GSIs on many devices, and they didn't even test P GSI over O-MR1 Pixels!
It seems to me that their goal was simply to make updates easier to OEMs. Considering Essential PH-1 getting Pie day-one, this might seem a success.
But we'll need to compare Oreo adoption rate to Pie's to confirm.

Oooh someone made a thread so i can moan cheers
The main problem with treble for me is that it's splintered between a plethora of devices, so one dev will release a treble rom and a multitude of device owners will flash it, each with their own subjective problems and issues, requests and wants.
And there lies the problem, it's difficult even when it's a dedicated rom thread for a particular device to get help at times.
So when you have a bunch of users talking about completely different devices you haven't got a hope in hell.
I think there should be branches to each thread for each specific device, that way help threads can be more linear rather than the chaos that it is at the moment.
Least that's my thoughts
My only rom i've flashed is RR and besides a few missing features, Fingerprint, Stereo and NFC i think it's brilliant.

Security updates over?

I guess we are done for security updates. It has been right at 2 years. Sad thing is, this is still a great little phone. I am not in the mood to root and tinker with issues. I wished there was a stable ROM out there to use. I wished that LineageOS would pick this little jewel up. Oh, well. It has been a good 2 years of a small, but very informative community of X Compact users.
I am still searching for a small phone replacement since Sony does not make small phones anymore. Post here if you have any recommendations.
Cheers!
del

I feel you. I think I've said it before on this forum, but I really don't get why there isn't a lineageos build for this phone. Lots of sony xperia phones have official lineageos builds and there even is an unofficial build for this device (so it's not exactly impossible to build).
That being said, I generally prefer omnirom and luckily they are supporting this device. I've been on omnirom 8.1 for ages and haven't encountered a bug yet, so imho it can definitely be considered stable. Right now I'm using a self-built omnirom 9.0 (security patch level 5 november 2018) as a daily driver and for a pre-official build it is already pretty stable. Sony's 'Pie' software binaries (which thankfully they still provide) are still in beta, so coupled with the omnirom team efforts the stability will only increase.
Bottom line for smartphone manufacturers: Just provide what is needed for the open source community to flourish, it'll cost you next to nothing and will pay you back in goodwill many times over.

Next upcoming problem is the lack of support for the Project Treble in Xperia X series devices which at least may cause significant delay in releasing ROMs based the newer Android versions or in the worst case might result in stopping their development as the successor - XZ1 series - supports it. I hope developers will follow the Z5 series path as there already is LineageOS for these. And hopefully some Xiaomi devices path as there are devices which now have unofficial support of the Project Treble.
BTW, we should also thank to the Google for an unwise cycle of releasing new Android version every year which accelerates fragmentation significantly as its main reason seems to be to persuade people to buy newer devices with latest version of Andoid OS on board.
harryharryharry said:
Lots of sony xperia phones have official lineageos builds and there even is an unofficial build for this device (so it's not exactly impossible to build).
Click to expand...
Click to collapse
I suppose more recent Sony smartphones have been sold in significantly lower quantities than older ones (I read many times about Sony's smartphones poor sales numbers) and it might be the reason of a smaller community gathered around those newer devices.

Software security updates stopped?
If Sony stops providing software updates after 2y, it means those of us with a Sony Xperia X Compact (F5321) are unable to add Work e-mail accounts as the Microsoft Intune app requires an Android software update dated May 2019.
This silly policy by Sony is preventing me from adding my work O365 account to the device and means I am very unlikely to buy another Sony mobile phone ever again as its usable life is 2 years max. I am actually quite raging because I like the phone -this is beyond stupid from Sony.

RTV_1974 said:
If Sony stops providing software updates after 2y, it means those of us with a Sony Xperia X Compact (F5321) are unable to add Work e-mail accounts as the Microsoft Intune app requires an Android software update dated May 2019.
This silly policy by Sony is preventing me from adding my work O365 account to the device and means I am very unlikely to buy another Sony mobile phone ever again as its usable life is 2 years max. I am actually quite raging because I like the phone -this is beyond stupid from Sony.
Click to expand...
Click to collapse
use browser.
intune sucks anyway.

RTV_1974 said:
If Sony stops providing software updates after 2y, it means those of us with a Sony Xperia X Compact (F5321) are unable to add Work e-mail accounts as the Microsoft Intune app requires an Android software update dated May 2019.
This silly policy by Sony is preventing me from adding my work O365 account to the device and means I am very unlikely to buy another Sony mobile phone ever again as its usable life is 2 years max. I am actually quite raging because I like the phone -this is beyond stupid from Sony.
Click to expand...
Click to collapse
This device has pretty lackluster support even in the dev community as well. All it's really got going for it atm but fortunately we have Lineage 17.1 and Project Treble. I recommend flashing a new rom if you don't want to switch phones.