• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [ROM][5.1.1]Carbon ROM for Exhibit / Ace 2e[ T599N | T599 | T599V ] [METICULUS]

Your attitude makes me wonder why I should bother with this device. I don't mind bug reports but you could say thanks before you start complaining.

I'm not going to work on this for a while. Shame, I was planning to bring up MM.

P.S. Offline Charging works perfectly.
NFIAJ
 
Your attitude makes me wonder why I should bother with this device. I don't mind bug reports but you could say thanks before you start complaining.
Meticulus, to whom was your post directed?

If it was to me, please do not construe bug reports for lack of thankfulness. I am very thankful for your work (much more so than you might think). The purpose of the bug reports is to help you improve the ROM. It is my understanding that it is the custom on Internet forums to post on topic and with regards to the topic and to keep information relevant. A thank you, although the thread starter may like to have them, may often be seen as unnecessary and a timewaster for the general reader, and thread moderators or administrators may guard against them; this is why I believe that many Internet forums have adopted a "Thanks" or similar button.

If you wanted an explicit declaration of thank you prior to the bug reports, you, without any hesitation, have it:

Thank you Meticulus for you development of the ROM described in this thread.

P.S. Offline Charging works perfectly.
If this is referring my post at thread post #25, I was thinking that it was your determination that their was an issue with Offline Charging. I had gathered this idea from your post at thread post #2, stating, "Offline Charger options via "Extras" do not work.", in the list of Known Issues.

I do not know what this code, acronym, or symbol means.
 
Your attitude makes me wonder why I should bother with this device. I don't mind bug reports but you could say thanks before you start complaining.

I'm not going to work on this for a while. Shame, I was planning to bring up MM.

P.S. Offline Charging works perfectly.
NFIAJ

Please no meticulus, you dont know how happy I was when you announced that you return to work with this device, dont leave us now, you deserve the thanks and even more, if I could, I would donate for your daily coffee, but I'm from Venezuela and I have no dollars, Once I tried to build on my own without success, but I realized the effort and work involved and that is something that gives reason to tell you THANKS @Meticulus
 
Alright, let's take it one thing at a time. What is wrong with MTP? I was having an issue with copying files to the internal storage: download folder but I deleted the folder and recreated it and now it's fine. Strange I know, but that is the only issue I have had with it. Now it's fine... So what problems ( if any ) is anyone having with it?
 
Alright, let's take it one thing at a time. What is wrong with MTP? I was having an issue with copying files to the internal storage: download folder but I deleted the folder and recreated it and now it's fine. Strange I know, but that is the only issue I have had with it. Now it's fine... So what problems ( if any ) is anyone having with it?
i copy some music yesterday and no issues
 
Alright, let's take it one thing at a time. What is wrong with MTP? I was having an issue with copying files to the internal storage: download folder but I deleted the folder and recreated it and now it's fine. Strange I know, but that is the only issue I have had with it. Now it's fine... So what problems ( if any ) is anyone having with it?
As of the current 20160728 build plus Update 1, MTP seems to be working rather well. The only issue I have with it is when files are uploaded to the Samsung SGH-T599N device via MTP, file timestamps are not retained.

An issue I do have is that when "Mass sorage (UMS)" is selected in the "USB computer connection" options (Settings --> Storage -->[Vertical ... Menu] --> USB computer connection), the option fails, and the last USB connection type is instead reverted. I tested this on a computer running Windows XP Professional with Service Pack 3.

I would think that it would be more convenient to always have the "USB computer connection" options always available regardless as to whether a USB connection is detected. Currently, a USB device must be detected before the options become available.
 
Last edited:
I do notice that there is an issue with the display of content while device is in the locked state. Sometimes, while trying to unlock device, the contents which should only be available after the device is unlocked is displayed for a short duration before it is replaced by the unlock pattern (I use a 6 x 6 grid pattern unlock) screen. I have not yet figured out the steps to reproduce the problem.

EDIT: Another issue: When attempting to unmount SD card via "Unmount SD card" option using the UI in Settings --> Storage, the Carbon ROM boot animation is shown and the operating system seems to reload. I use a 64GB microSDXC card formatted to the exFAT filesystem.
 
Last edited:
As of the current 20160728 build plus Update 1, MTP seems to be working rather well. The only issue I have with it is when files are uploaded to the Samsung SGH-T599N device via MTP, file timestamps are not retained.

An issue I do have is that when "Mass sorage (UMS)" is selected in the "USB computer connection" options (Settings --> Storage -->[Vertical ... Menu] --> USB computer connection), the option fails, and the last USB connection type is instead reverted. I tested this on a computer running Windows XP Professional with Service Pack 3.

I would think that it would be more convenient to always have the "USB computer connection" options always available regardless as to whether a USB connection is detected. Currently, a USB device must be detected before the options become available.

Has MTP ever preserved the file time? Is it supposed to? I don't know... but I am not going to change that.

UMS is not expected to work with this device but I'll look into it.

USB connection options behave as they normally do although I do see your point. I might change this if it is not too envolved.
 
I do notice that there is an issue with the display of content while device is in the locked state. Sometimes, while trying to unlock device, the contents which should only be available after the device is unlocked is displayed for a short duration before it is replaced by the unlock pattern (I use a 6 x 6 grid pattern unlock) screen. I have not yet figured out the steps to reproduce the problem.

EDIT: Another issue: When attempting to unmount SD card via "Unmount SD card" option using the UI in Settings --> Storage, the Carbon ROM boot animation is shown and the operating system seems to reload. I use a 64GB microSDXC card formatted to the exFAT filesystem.

Minor display issues are to be expected. HW lib's are from JB. Most likely just processing lag.

I will need logs for the sdcard issue. I can not reproduce..[emoji106]
 
Has MTP ever preserved the file time? Is it supposed to? I don't know... but I am not going to change that.
After doing some research, it seems that the MTP specification does provide for preservation or sending of a time and date combination. The actual sending of the that time and date combination appears to be optional. My guess is that the intention was to leave the time and date optional for those times the time and date is not available.

Real world implementation of MTP seem to vary greatly with regards to preservation of the file time stamp via MTP. There are many complaints regarding file timestamp not preserved when MTP is used and an Android device is involved.

The current, version 1.1 of the MTP specification may be found as an attachment to this post or at:
http://www.usb.org/developers/docs/devclass_docs/
(See secions 1.3 , 3.2.5, 5.3.1, 5.3.1.14, 5.3.1.15, and 5.3.2.3.3)

An older version 0.96 of the specification may be found:
https://www.microsoft.com/en-us/download/details.aspx?id=19678
 

Attachments

Last edited:
I will need logs for the sdcard issue. I can not reproduce..[emoji106]
I am PMing you those logs.

I also notice that attempting to remount the microSD card, results in what appears to be an incomplete mount. Some Apps show an SD Car, others do not; the true SD card data remains unavailable. I have attached screenshots that I used to illustrate this using my 64GB exFAT-formatted microSDXC card. Do take note that after remounting the SD card, the size is reported as zero. The system may or may not bring-up the Carbon ROM animation afterwards.
 

Attachments

  • 64GB_Screenshot_2016-08-08-20-09-24.png
    64GB_Screenshot_2016-08-08-20-09-24.png
    47.5 KB · Views: 195
  • 64GB_Screenshot_2016-08-08-20-09-36.png
    64GB_Screenshot_2016-08-08-20-09-36.png
    61.6 KB · Views: 255
  • 64GB_Screenshot_2016-08-08-20-10-02.png
    64GB_Screenshot_2016-08-08-20-10-02.png
    46.7 KB · Views: 285
  • 64GB_Screenshot_2016-08-08-20-10-13.png
    64GB_Screenshot_2016-08-08-20-10-13.png
    45.4 KB · Views: 211
Thanks. I shall soon use/test it.

One thing that concerns me after reading the changelog for CARBON-5.1.1-METICULUS-20160728-0825-codinalte update-2 is:
The data partition is automatically resized. Very small resize only 16k.
Is the resized partiion ever restored to original size? If full device encryption is performed many times, would the data partition consequently be reduced more than 16k from the original size? For example, If the device encryption is performed 100 times, would the resized amount be 1600k?

Is the CARBON-5.1.1-METICULUS-20160728-0825-codinalte update-2 build the first build to perform the partition resizing when device encryption is attempted?

At what point does the data partition resize occur? (For example, during ROM first boot, after using the Encrypt phone option in the Storage category from Settings, etc.)

As an aside: Are the encryption strategies/algorithms used by Andorid AOSP and Samsung's implementation different with regards to partition size requirements?
 
Thanks. I shall soon use/test it.

One thing that concerns me after reading the changelog for CARBON-5.1.1-METICULUS-20160728-0825-codinalte update-2 is:
Is the resized partiion ever restored to original size? If full device encryption is performed many times, would the data partition consequently be reduced more than 16k from the original size? For example, If the device encryption is performed 100 times, would the resized amount be 1600k?

Is the CARBON-5.1.1-METICULUS-20160728-0825-codinalte update-2 build the first build to perform the partition resizing when device encryption is attempted?

At what point does the data partition resize occur? (For example, during ROM first boot, after using the Encrypt phone option in the Storage category from Settings, etc.)

As an aside: Are the encryption strategies/algorithms used by Andorid AOSP and Samsung's implementation different with regards to partition size requirements?

First, partition tables are not modified. The file system on the partition is resized. If it has already been resized it wont do it again. It will never use more than 16k. The resize occurs just after encryption process begins (as needed). There is nothing "Samsung" about the encryption process. Its all AOSP/CM. The cipher is whatever is default. There are some ux-500 platform ciphers but the are not enabled in the kernel.

The resize has never occurred until update 2. Simply formatting/wiping the /data partition in recovery will undo the resize.
 
I am PMing you those logs.

I also notice that attempting to remount the microSD card, results in what appears to be an incomplete mount. Some Apps show an SD Car, others do not; the true SD card data remains unavailable. I have attached screenshots that I used to illustrate this using my 64GB exFAT-formatted microSDXC card. Do take note that after remounting the SD card, the size is reported as zero. The system may or may not bring-up the Carbon ROM animation afterwards.

I reviewed your logs and I think that update 2 will resolve your issues with your sdcard. I reverted an old KitKat hack regarding fuse mounting of external disks. Let me know if this issue persists beyond update 2. ;)
 
I reviewed your logs and I think that update 2 will resolve your issues with your sdcard. I reverted an old KitKat hack regarding fuse mounting of external disks. Let me know if this issue persists beyond update 2. ;)
Thanks. I am now on Update 2.

I encrypted the file system successfully

I have been able to mount and unmount the SDcard using the Settings --> Storage options successfully.

I tested "Mass storage (UMS)" and have noticed that it does seem to be usable. On my computer using Windows XP Professional with Service Pack 3, the various media are enumerated as part of a multi-media device labeled "Linux File-CD Gadget USB Device".
EDIT: I do notice the the external SD Card is available to the USB connected host device, but becomes unavailable to the user on the mobile device; the internal storage partition was available on my mobile device, but not on my Windows XP Professional with Service Pack 3 computer (but an unrecognized media did mount). My mobile device's internal storage was uses the ext4 filesystem, but I do not yet have a Windows driver for it. The external SD card is once again available after disabling UMS. It has been a while since I have used UMS on from an Android device; I do not know whether the presented unavailability or availability of the storage areas is expected behavior.

EDIT2: It is important to Safely Remove the connected devices. The caveat I noticed with UMS Mass storage on the Android mobile device, is that disabling UMS mass storage prior to connecting via USB is not possible. So, to change to another USB mode if UMS ass storage is the current setting, UMS Mass storage mode must first be used, then safely removed on the host device, then select another mode. Optionally afterwards the USB cable may be disconnected.
 
Last edited:
Thanks. I am now on Update 2.

EDIT: I do notice the the external SD Card is available to the USB connected host device, but becomes unavailable to the user on the mobile device
This is typical of UMS. That is why i only configured the external sdcard to work with UMS. Our internal sdcard is emulated, so I did not think that detaching would be possible..
 
If there are no other significant issues, I'm going to end development of this ROM and prepare to try to bring up MM. As soon as I have (/If I ever get ) a booting build, I will most likely post it in a new thread. It will probably have LOTS of stuff wrong with it, so it won't be a daily driver....
 
If there are no other significant issues, I'm going to end development of this ROM and prepare to try to bring up MM. As soon as I have (/If I ever get ) a booting build, I will most likely post it in a new thread. It will probably have LOTS of stuff wrong with it, so it won't be a daily driver....
The only significant issues I am having at the moment are:

In Settings --> CarbonROM Fibers --> Notification drawer --> Notification drawer -->, the "Power menu in expanded status bar" option's "Screen off - Power menu" and "Power menu - Screen off" do not behave as expected. Irrespective as to how long a press occurs on the Notification drawer status bar power button, the tap action is performed; the secondary actions (pressing and holding) do not work.
(I really do very much like having a software power button available)
 
The only significant issues I am having at the moment are:

In Settings --> CarbonROM Fibers --> Notification drawer --> Notification drawer -->, the "Power menu in expanded status bar" option's "Screen off - Power menu" and "Power menu - Screen off" do not behave as expected. Irrespective as to how long a press occurs on the Notification drawer status bar power button, the tap action is performed; the secondary actions (pressing and holding) do not work.
(I really do very much like having a software power button available)
Power menu is available as a tile... [emoji6]
 
Back
Top Bottom